Templot Club Archive 2007-2020
|
||||
| author | remove search highlighting | |||
|---|---|---|---|---|
|
posted: 3 Nov 2019 14:43 from: Martin Wynne
click the date to link to this post click member name to view archived images |
I think we probably need a monthly topic for chewing over code clips and ideas, so I have started this one. It will get tangled, so we will need to start a new one each month.  See also the new TemplotMEC code archive sub-section as a record of code changes after we have adopted them. As yet it is empty. Graeme wrote: If you would like to give it a whirl I would be grateful.Hi Graeme, Many thanks for your work. We are getting there, but still quite a few issues need fixing: 2_030914_210000000.png  A. this should be OTBOX of course. B. this should be OTBOX-FILES. I seem to recall fixing that in the original release, but it may have got lost somewhere along the way. Also every reference in the code. Leave that with me. C. this should contain only the disk drive. If it contains the full path it is not readable. D. this should be a list of folders, not files. Refer to the working of these boxes in Templot2 to see what I mean. It was because I couldn't find the same in Lazarus that I omitted the file viewer from the first release of OT. There is no point in having a list of files there, because that is what is intended to appear in the main pane E. Also it is listing 11 files there but indicating 7 files in the top heading. Presumably because some of them are MECBOX files. Viewing MECBOX files (and importing them) needs to be a separate option on the viewer. F. When I clicked the show files button to generate the list, it crashed T3. Also the HTML on the main pane used to be centred. Have you changed it for some reason? I didn't expect that there would be any need to modify the HTML.  If you would like to leave all the above with me to fix while you sort out the Git stuff, I'm entirely happy to do that. cheers, Martin. |
|||
|
posted: 3 Nov 2019 15:57 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: 2_030914_210000000.pngHi Martin, Before you do let me explain A. this should be OTBOX of course. I did wonder about this. As it stands it refers to the file extension. It seems to me that we should here be referring to the TYPE of the file. It is a box file (where box is a concept in Templot). Whether the filename has .box or .otbox is a detail of implementation, and should not be the concern of users. To see what I mean, consider what we would put here if we solve the issue of reading old ,box files, so we can read both types. B. Same argument as for A. From the user's perspective, it is a box file. Details of the implementation should not be the users' concern. C. & D. this was one of the challenges with the changes. The Delphi components do not have direct equivalents in Lazarus (as you found). The best I could find was a Directory selector and a file list box. There is no such thing as a 'Drive' in most operating systems, it is a Windows-specific concept, so the directory selector is the nearest equivalent. For sure the screen design will have to change, but I wanted to move things around as little as possible until it was working OK. I agree, the file list box is somewhat redundant now. It does show ALL the files in the directory, not just box files, but I am not convinced of the value of that. It did occur to me that clicking (or double-clicking) on a file in the list may do something, but without knowing the application better I could not say what. Design issues like this I think you will have to deal with for some while. F. When I clicked the show files button to generate the list, it crashed T3.  This one is much more serious. It worked OK for me. Do you have only OTBOX files in your directory? I will test a bit more and see if I can get mine to crash too.>> Also the HTML on the main pane used to be centred. Not guilty. This may have been dropped accidentally in the merging. I certainly did not do it deliberately. I would like to try to get mine to crash, but certainly need your help with the user interface design. cheers, graeme |
|||
|
posted: 3 Nov 2019 22:35 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, Here's a mock-up of a possible top option selector: 2_031746_510000000.png  2_031726_440000000.png  It's now 890 high, which is too much for some laptops. So that means either reducing the visible part of the list, or a complete re-design. Extra width is possible -- it's currently 1020 and nowadays I allow for up to 1200. cheers, Martin. |
|||
|
posted: 4 Nov 2019 18:16 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Martin Wynne wrote:p.p.s. re the Lazarus controls. I'm going to have a go at recreating the old Delphi controls programmatically. That was my original intention when I couldn't find a match in Lazarus. I left it undone then because it's not a 5-minute task, and "have a go" is just as likely to mean failure as success.Hi Graeme, I should have looked a bit harder before giving up 18 months ago. I googled some ideas for recursively filling a TTreeView control with folders. I don't like using recursive code if I can help it, but sometimes it is the only way: 2_041301_070000000.png  2_041301_070000001.png  Which looks promising. It needs tidying up a bit and won't start from the drive root for some reason. That probably needs another listbox to show the top-level folders. And a combobox to select the drive. Do you want to look at this? Or shall I do a bit more with it? procedure get_folders(folder_str:string; tree_node:TTreeNode); var search_record:TSearchRec; new_node:TTreeNode; begin if folder_str[Length(folder_str)]<>'\' then folder_str:=folder_str+'\'; if FindFirst(folder_str+'*.*',faDirectory,search_record)=0 then begin repeat if ((search_record.Attr and faDirectory)=faDirectory) and (search_record.Name[1]<>'.') then begin if ((search_record.Attr and faDirectory)>0) then tree_node:=file_viewer_form.folder_tree.Items.AddChild(tree_node,search_record.Name); new_node:=tree_node.Parent; get_folders(folder_str+search_record.Name,tree_node); tree_node:=new_node; end; until FindNext(search_record)<>0; FindClose(search_record); end; end; cheers, Martin. |
|||
|
posted: 5 Nov 2019 06:29 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: That probably needs another listbox to show the top-level folders. And a combobox to select the drive.Yes - Lazarus has no drive box (and for the usual cross-platform reasons - only Windows has the concept of drives) so you are going to have to create one of those too. Alternatively, how about putting the top level folders AND the drives as levels in that one box - such as Windows does (or did). Like this: 3620_050122_190000000.png 
Do you want to look at this? Or shall I do a bit more with it?I confess I am still don't see the benefit of re-creating Delphi controls when we already have a perfectly workable solution with what Lazarus provides (unless I have missed something, of course  ). Sorry, but I could find any enthusiasm for doing this - it feels like a move in the wrong direction. I would prefer to put my efforts elsewhere. I will look at adding printer settings to saved preferences, as you asked me to a couple of days ago, topic 3538 - message 28217 if that's OK? Cheers, g |
|||
| Last edited on 5 Nov 2019 07:44 by Graeme |
||||
|
posted: 5 Nov 2019 07:27 from: Graeme
click the date to link to this post click member name to view archived images |
Hi Martin, Do we need another topic specifically for contributions to be posted? (or have I missed something?) Anyway, this was the first change I made. Not earth-shattering really, but just so we have a complete record. data_memo_unit.lfm object data_child_form: Tdata_child_form Width = 565 BorderIcons = [biSystemMenu] BorderStyle = bsSizeToolWin - Caption = ' data ...' + Caption = ' info ...' ClientHeight = 570 ClientWidth = 565 Cheers, graeme |
|||
| Last edited on 5 Nov 2019 08:15 by Graeme |
||||
|
posted: 5 Nov 2019 08:18 from: Graeme
click the date to link to this post click member name to view archived images |
Hi Martin, Another change that was 95% investigation / 5% coding. ------------------------------- keep_select.pas ------------------------------- Line - 8579 if hi_color=True then ref_panel.Color:=keepform_listbox.Color; //alert_colour[5]; // ice-blue or white. with keepform_listbox do ItemHeight:=Round(Canvas.TextHeight(' ')*8/7); // owner-draw listbox, 8/7 arbitrary. + if Assigned(data_child_form) and (data_child_form.Visible=True) then + keep_form.read_info_buttonClick(data_child_form); end; //____________________________________________________________________________________ Cheers, graeme PS Let me know if you would prefer for me to post the complete file. |
|||
|
posted: 5 Nov 2019 15:35 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Graeme wrote: Hi Martin,Hi Graeme, Many thanks for that. Unfortunately it is a bit more complicated, because the same form is used as a child elsewhere, like this: 2_050938_010000000.png  Which means it may have been set Visible there, and simply testing Visible doesn't prove that it is showing on the trackpad. On a small screen showing it when the user didn't request it could be annoying. (I can't remember why I did that, and it's causing problems in Lazarus. It might be better to duplicate the form and use a different one in each place where it is needed.) So the obvious condition becomes: if (data_child_form.Visible=True) and (data_child_form.Parent=pad_form) which would work fine in Delphi but not in Lazarus, and nor does: if (Windows.GetParent(data_child_form.Handle)=pad_form.Handle) which leads to the conclusion that the GetParent function hasn't been implemented in Lazarus. We therefore need to keep our own record of the current parent of the form. Shall I look at that or do you want to have a go? There is not much need for if Assigned because all the forms are created in the program unit ( templotmec.lpr ) before Application.Run; If that failed we would have far more problems than this form not being assigned. Instead of: keep_form.read_info_buttonClick(data_child_form); I would normally call the click method on the button directly: keep_form.read_info_button.Click; If you do the former you get a telling off in Delphi, I can't remember the exact wording of the message. But it works anyway. Because the above lines are in a Tkeep_form.xxx procedure, there is no actual need to specify the form, and a plain read_info_buttonClick(data_child_form); or read_info_button.Click; will work fine. cheers, Martin. |
|||
|
posted: 6 Nov 2019 01:33 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: Unfortunately it is a bit more complicated, ...Hi Martin, I had a feeling that if it was that easy you would have done it already.  I am still profoundly ignorant of Templot from a user perspective, so I think I will wind my neck in for a few days and just play with the program and see what I can do with it. I will obviously not become an expert in that time, but I will probably increase my knowledge tenfold. This particular change seems non-critical, so if you are happy to leave it a while longer I would like to come back to it when I code again and see if I can get closer to a real solution. Cheers, Graeme PS Thank you for the tips on coding style/conventions. I will bear those in mind in future. |
|||
| Last edited on 6 Nov 2019 01:35 by Graeme |
||||
|
posted: 15 Nov 2019 20:04 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Why is it that the sillier the mistake, the longer it takes to find it?  Who in their right mind references an object only 2 lines after they freed it? And then takes all afternoon to find it? Don't answer that. Martin. |
|||
|
posted: 16 Nov 2019 03:17 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: Why is it that the sillier the mistake, the longer it takes to find it? Oh, if only I knew the answer to that ... Who in their right mind references an object only 2 lines after they freed it? And then takes all afternoon to find it? Don't answer that.Err ..... I could hazard a guess, but since you explicitly asked me not to ... (all the while fighting to keep his right hand from rising, unbidden, into the air )But with serious face on for a moment, I notice there are two kinds of info box (the other accessed by clicking a background template and pressing the "i" key). Is there some deeply profound reason for this or is it just an historical hangover? Cheers, graeme |
|||
|
posted: 16 Nov 2019 08:55 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Graeme wrote:But with serious face on for a moment, I notice there are two kinds of info box (the other accessed by clicking a background template and pressing the "i" key). Is there some deeply profound reason for this or is it just an historical hangover?Hi Graeme, It's partly just historical. I mentioned it recently, para 1. at: topic 3469 - message 27380 The slightly profound reason is that this one shows modal. So that it can't be left showing wrong info if you then click a different template. The obvious way forward would be for it to update the info when a template is clicked, in which case it doesn't need to be modal and could be the same one for both. I mentioned this at 3. here: topic 3531 The whole thing needs a revamp. A first step would be to create a duplicate window which is used only for this template info and not for other purposes elsewhere. I've no idea why I didn't do that in the first place. In fact bearing in mind the problems I found earlier, it should no longer be a child window and needs to be some other control, such as a TPanel, directly on the trackpad. If the info updates automatically, it needs an additional button/menu item somewhere to show it without needing to click a specific template, or open the storage box, first. The place for that would probably be on the right-click menu on the trackpad -- for which I haven't looked at the code in years, and use only rarely in practice. It is mainly used for mouse-action modifiers, showing the right-click menu being one of the few things you can do while a mouse action is in force without cancelling the mouse action. The other being to drag the trackpad with the middle mouse button (wheel press). That has to be done very carefully, because accidentally rolling the wheel at the same time zooms the trackpad (which does cancel the mouse action). A further possible upgrade therefore would be to prevent mouse-wheel zooming while a mouse action is in force. Any zooming must always cancel a mouse action, because it modifies the mouse-action response resolution. cheers, Martin. |
|||
|
posted: 18 Nov 2019 18:55 from: Martin Wynne
click the date to link to this post click member name to view archived images |
It's been suggested that after starting Templot using saved program preferences, there should be an option to see what was actually changed from the defaults. Anyone fancy having a go at that? I can then pinch the code and use it in T2. Here's a suggested way of doing it (in prefs_unit), new in red: //_____________________________________ function get_pref_float(str:string; def_float:extended; explain_str:string):extended; var val_str:string; temp_float:extended; begin RESULT:=def_float; // default init. val_str:=user_prefs_list.Values[str]; if val_str='' then EXIT; // not in list try temp_float:=StrToFloat(val_str); except EXIT; // invalid value end;//try RESULT:=temp_float; // return result if RESULT<>def_float then what_changed_list.Add(explain_str+' = '+val_str+' mm'); end; //_____________________________________ ... printtimber_thick:=get_pref_float('08-33f',printtimber_thick,'line thickness: output/printed timber outlines'); ... cheers, Martin. |
|||
|
posted: 20 Nov 2019 07:22 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: (I can't remember why I did that, and it's causing problems in Lazarus. It might be better to duplicate the form and use a different one in each place where it is needed.) Hi Martin, Well, after a couple of weeks having great fun enjoying myself with Templot it is time to get back to work again. Having started to look at it already, I would like to get to the bottom of the info screen issue. EDIT : ... Then the rest of this is babble. Please ignore it. However, I AM back looking at this.
<EDIT : Read the next post along with this. >Cheers, graeme |
|||
| Last edited on 20 Nov 2019 08:40 by Graeme |
||||
|
posted: 20 Nov 2019 07:39 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: The obvious way forward would be for it to update the info when a template is clicked, in which case it doesn't need to be modal and could be the same one for both. EDIT : ... more babble, I think. Please ignore and accept my apologies. Sorry, I meant to reference this post in my previous. You seem to be leaning toward the idea of a single window for info, updated as neccessary (my first option). Is that correct? I am still not sure why we would not just make it a separate, "free" window. It would not affect me much as I tend to have the trackpad full screen anyway, but for those with more screen space it would avoid cluttering up the trackpad. Just a thought. Cheers, g |
|||
| Last edited on 20 Nov 2019 08:41 by Graeme |
||||
|
posted: 20 Nov 2019 12:31 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, That's a lot of crossing-out on your exam paper! Some things you suggest are already possible, see for example clicking on a background template and then S show in box. The info options, like a lot of Templot, have developed piecemeal over the years and are ripe for rationalisation and improvement. The problem is that there is always more to everything than appears at first sight. There is often a good reason why things are the way they are, even if I can't now remember the reason. At present we have two ways to see the info for a background template (in addition to the info for the current control template): 1. click on a background template and I information on its menu. This is displayed as HTML on a normal modal window. 2. click the info button on the storage box. This is displayed as plain text in a TMemo component on a child window. There are problems with both of these going forward. 1. modal windows don't work properly under Wine on Linux/Mac/CrossOver. I have put in a kludgy fix for that, but ideally we would use far fewer modal dialogs. They annoy users by requiring to be dismissed before the program can continue. 2. child forms aren't properly implemented by the Lazarus compiler. There might be a way round that if we dig deeper into Lazarus. The reason for using child forms is simply me being lazy. They provide a quick way of having a draggable resizable scrolling panel which doesn't take focus away from the parent form. That could be provided by coding a TPanel component instead, although making it resizable is a lot of work. 1. At present this shows modal and must be dismissed before the program can continue. That's because at present it doesn't update automatically. In which case, if it wasn't modal, it would be left showing incorrect data when a different template is clicked. If we arrange for it to update when a template is clicked, it doesn't need to be modal and can be left showing. The info on 1. is displayed as HTML. That means there is potential for it to be clickable. Some of the info settings could be changed by clicking on them. This would be a lot quicker than copying the template to the control template, or using the modify on rebuild functions. If we use an ordinary free-standing window for the info, it would need to be set to StayOnTop to avoid vanishing behind the trackpad. We can't assume that all users have a large enough screen not to be using the trackpad maximized. I don't know if you have tried StayOnTop windows? They are an utter headache because Windows is very fickle about when and where it will agree to display them, especially if there is more than one of them, or other software is also using them. The Windows docs explain it all, but as usual they don't necessarily correspond to what happens in practice. But even if we get them to show properly, using them to click a button or scroll the info immediately removes focus from the trackpad, needing an extra click on it before work can continue. I don't know if it's just me, but I find that very annoying. That's why I would much prefer a draggable TPanel instead. We do already have one of those, used to move the name labels (click a template then L , M). That's the dummy_label_panel and you can see how it is dragged in its MouseMove event: Tpad_form.dummy_label_panelMouseMove . If we got all this updating and working nicely for 1., then 2. could use it too. cheers, Martin. |
|||
|
posted: 20 Nov 2019 15:40 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: That's a lot of crossing-out on your exam paper!Hahaha - yes - much like my papers at school! In spite of the quality of my post, thanks for another classic responses which always seem to fill in a load of background, point out features/shortcuts I didn't know about and give great info on the deficiencies in Delphi and Lazarus and possibilities for our best way forward. As ever, thanks. The problem is that there is always more to everything than appears at first sight. There is often a good reason why things are the way they are, even if I can't now remember the reason. Ah yes. Well this problem is one of the thing I HAVE learned. I hope dredging your memory for the reasons for things is more like a happy wander down memory lane and less like a walk over red hot coals! ... child forms aren't properly implemented by the Lazarus compiler. There might be a way round that if we dig deeper into Lazarus. You may be right, but I'm not so sure. I guess I should put a post out on the Lazarus help groups (unless you have tried there already) but I have a suspicion that they have taken a "lowest common denominator" approach, in the interests of being cross-platform, and that some of the platforms they want to support do not provide what is a rather Windows-y way of working. (As I mentioned before, I have been a Linux user for many years, and I was a more than a little shocked when I used the mouse wheel in one window and Templot zoomed my Trackpad for me! NOT what I was expecting. Not better, not worse, just different.) I feel there are going to be a few things like that, but the key is that efficient working is still possible. It does not have to work identically, just so long as it works well. (In my humble opinion ) Clearly with 2,000+ users, change should not be undertaken lightly, but we have all survived umpteen Windows incarnations, some of them significant departures from their predecessors, and none of us expired as a result, as far as I am aware (though admittedly some of us DID defect to the Linux camp )If we arrange for it to update when a template is clicked, it doesn't need to be modal and can be left showing.Yes indeed, and this is what I am working on now. Hopefully it will give us a workable solution. I absolutely agree, too, about modal windows. Certainly a necessary evil sometimes, but the disruption they cause to workflow means they should be avoided when possible. But even if we get them to show properly, using them to click a button or scroll the info immediately removes focus from the trackpad, needing an extra click on it before work can continue. I don't know if it's just me, but I find that very annoying. Yes. This is part of what I mean by "working well". To the extent that we can achieve it, things should be no harder to do than they are now. Anyway, I am back to actively working on this. Let's see what I can come up with. (Gosh, my English teacher would kill me. I can hear him now telling us "Boys, always remember, it is very bad grammar to use a preposition to end a sentence up with.") Cheers, g |
|||
|
posted: 20 Nov 2019 18:51 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Martin Wynne wrote:But even if we get them to show properly, using them to click a button or scroll the info immediately removes focus from the trackpad, needing an extra click on it before work can continue. I don't know if it's just me, but I find that very annoying.Hi Graeme, I wish to rewind on that. I now have the child windows working fine in Lazarus. It's my memory again -- I can see that being an increasing problem. It just needs this adding at the end of every child window event: if pad_form.arrow_button_dummy_trackbar.Showing=True then pad_form.arrow_button_dummy_trackbar.SetFocus; arrow_button_dummy_trackbar is a component on the trackpad (top-left) which is not visible. Despite having Visible=True, it is not visible because it has Width=0. That way it can receive focus and specifically receive the arrow keys on the trackpad for panning. If Visible was False, it wouldn't be possible to SetFocus on it. I had completely forgotten about that, sorry. I'm also sorry if it is the sort of "Meccano" programming that professionals don't do. It means we can use the existing child windows which on balance I would now prefer, if only because they provide a close equivalence to T2. I think it is important for T3 to be accepted that the first release of T3 is as close to an exact match to T2 as we can manage, at least visually. Rationalisation and improvements can then come later -- an actual release of T3 might encourage a few more to get involved. I've just released an update to T2, and it is "doin' me head in" to keep swapping between Delphi and Lazarus! cheers, Martin. |
|||
|
posted: 21 Nov 2019 01:40 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: I now have the child windows working fine in Lazarus.Hi Martin, Hahaha - You beat me to it! I had an epiphany as I fell asleep, and I was planning to try using SetFocus to put the focus back on the Trackpad this morning. I am glad it worked. (... and professionals tend to do what needs to be done to get the job done. Personally I find nothing wrong with this approach. )I agree that limiting change will help the adoption of T3. Changes are OK where necessary, but best avoided where we can, unless they are clear improvements. I can sympathise with your headaches over multiple platforms. I have T2 on Windows, T3 in Lazarus on Windows and T2 under Wine on Linux! But this was just about the focus issue, yes? I will push on working on the Template Info windows? Cheers, g |
|||
| Last edited on 21 Nov 2019 01:43 by Graeme |
||||
|
posted: 21 Nov 2019 02:02 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Graeme wrote:I can sympathise with your headaches over multiple platforms. I have T2 on Windows, T3 in Lazarus on Windows and T2 under Wine on Linux!Good Morning Graeme. Yes, by all means. See what you can do with them. As you probably noticed I slipped up on the new T2 release yesterday: topic 3558 It worries me, because 10 or even 5 years ago I wouldn't have made a mistake like that. I also wouldn't have forgotten about the dummy trackbar in my earlier posts. It may be that the reason to get T3 released is not that wayward bus, but Martin losing the plot. cheers, Martin. |
|||
|
posted: 21 Nov 2019 04:31 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: As you probably noticed I slipped up on the new T2 release yesterday:Ooops! Fear not - it happens to the best of us. ... but Martin losing the plot.That's fine - as long as you don't lose the TEMplot  (Well, OK - in 40+ years you must have heard it before, but it tickled me. )Cheers, graeme |
|||
| Last edited on 21 Nov 2019 04:31 by Graeme |
||||
|
posted: 21 Nov 2019 23:22 from: Trevor Walling
click the date to link to this post click member name to view archived images |
Hello Martin, The memory thing catches up with us all at varying degrees. I spent ages looking for a tape measure the other week. I have quite a few as it happens. Not in the kitchen, not in the bedroom, not in the front room, not in the railway room, and not in the garage. The wife eventually said "What is that in your hand?" With a knowing smile. I found loads of others later as well when I did not need them. Regards Trevor |
|||
|
posted: 22 Nov 2019 00:24 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Thanks Trevor. Yes, I do silly things like that every day now. Yesterday I was in the garden and wondered how the time was going as I needed to go out later. So I walked to the kitchen to look at the clock. While wearing a watch, which I have done all my life. Martin. |
|||
|
posted: 22 Nov 2019 00:46 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: Yes, I do silly things like that every day now. ... such as yesterday, while working at the breakfast table I was thirsty. I went into the kitchen, poured a glass of water, walked back, past my computer and into the bedroom and placed the glass on the bedside table! (I could claim it was nothing to do with age, rather that I was so focused on my Templot changes, but in reality ...) Is it any wonder these discussions stray off-topic? Cheers, graeme |
|||
| Last edited on 22 Nov 2019 01:23 by Graeme |
||||
|
posted: 22 Nov 2019 01:16 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Graeme wrote:Is it any wonder these discussions stray off-topic?This one certainly has. But only 8 days to go and I can start a new one for December. If Templot was purely for my own use, as it was originally, if I mess it up with silly mistakes it wouldn't matter. But I am conscious that there are some folks relying on it for lifetime projects, or maybe just cutting up expensive sheets of plywood based on the Templot output. So I do worry about making mistakes in the code. I've realised that getting an active open-source project up and running is important not just to keep things going in the event that the bus does its worst, but here and now to prevent any attempts by me to wreck the whole thing. cheers, Martin. |
|||
|
posted: 22 Nov 2019 01:44 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: I've realised that getting an active open-source project up and running is important not just to keep things going in the event that the bus does its worst, but here and now to prevent any attempts by me to wreck the whole thing. Yes indeed! One of the big benefits of opening the project (the classic line being "All bugs are shallow, given enough pairs of eyes"). On a somewhat related topic, I meant to ask you how version numbering works. What are your criteria for going from 291c to 292, rather than to 291d? Cheers, graeme |
|||
|
posted: 22 Nov 2019 02:26 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Graeme wrote:On a somewhat related topic, I meant to ask you how version numbering works. What are your criteria for going from 291c to 292, rather than to 291d?Hi Graeme, The version number changes when there is a change in the contents of the BOX/BOX3 file, and templates loaded from earlier versions need to be updated as they are loaded. You can see that happening if you look at the version_mismatch function in keep_select.pas . (Which as a result has become a history record of all such changes.) Most of that could be A lot of numbers are missed in the sequence, usually because they were my experimental versions never released. Also there was no version 1 of Templot, we went straight from Zero to 2. So nothing in the range 100-199. (Version 1 was was intended to become a retail boxed version on CD. We never did get that far, and when I decided to make Templot free I jumped it to Templot2. It made sense for the second major version of Templot to be number 2.) Where there is no change in the BOX file content I normally just bump the build letter. Full releases start at .a and bump forwards. If I make a scruff release (program file without installer) in between full releases I start at .z and bump backwards. In the recent case there wasn't in fact any change in the BOX file, but I felt it needed a version change for the record to mark the introduction of the MECBOX files. Hence T2 is now at 224a, and MECBOX files can't be earlier than 224. If they are in the range 224-289 they must have been exported from T2. If they are in the range 290+ they must be from T3. I haven't the faintest idea how other software deals with version numbering, the above is just my way of doing it, which I have continued using from the beginning. cheers, Martin. |
|||
|
posted: 24 Nov 2019 16:19 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: The version number changes when there is a change in the contents of the BOX/BOX3 file, and templates loaded from earlier versions need to be updated as they are loaded.Hi Martin, Thanks for taking the time to explain this, which all makes good sense (as I expected it would ).Other software normally follows a similar route (as you might expect) very often using a string of the format 'xx.yy', where 'xx' is referred to as the Major number and 'yy' as the Minor. Major releases are usually backward-incompatible, which in the case of many programs refers to changes in the file format(s). (In the case of a library which has no files, it is usually some change in the interface used to call the library.) Minor releases are backward-compatible. Occasionally they may stick a '.zz' on the end to denote a bug-fix release, but overall not really all that dissimilar to your system.. Thanks again, graeme |
|||
| Last edited on 24 Nov 2019 16:20 by Graeme |
||||
|
posted: 29 Nov 2019 10:44 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: Yes, by all means. See what you can do with them. AT LAST! After disturbance by a visitor from the UK, I have finally got the changes around the template info and switch info boxes completed. That is, I seem to be replicating the old functionality, but there may be some corners I am not aware of and have inadvertently 'broken'. In fact, there are ALMOST CERTainly some corners ..... As you have said on many occasions, Templot has grown over the 40+ years since its first creation, and inevitably, decisions made early on in the development turn out not to be ideal to support later requirements. In performing the changes to the info boxes I did try to make sure changes were made with the 'lightest' touch possible, BUT at the same time, any code being changed was fair game for re-arrangement or simplifying or moving to try to improve overall code structure. Obviously, some of the changes will be a matter of taste, but hopefully not too many. In most cases I hope it will be clear that the code has actually been simplified or given a better structure by the changes. In general, reducing the interweaving of the logic of the units is taken to be a 'good thing', as is reducing dependencies between units, and 'narrowing' the interfaces between them. Obviously, if you feel I have done violence to your code or to important concepts in it then let me know and I would be happy to explain my reasoning further. General Observations pad_unit and math_unit seem to be our 'problem children' in that they are by far the biggest units (and 32,000+ and 28,000+ are not small by any definition). As I understand it, the job of pad_unit is to look after the trackpad. This covers a huge amount of functionality, and so it is always going to be a large module. However, we probably have many opportunities to pull out code which can be (hopefully better) placed elsewhere, and thus try to pare pad_unit back to its core functions. This will make it easier to read and so safer to modify. The job of math_unit is not so easily summarised. It appears that it originally was intended to contain the many calculations around the design of turnout templates, but has grown significantly. Again, paring this back to its core functions is a reasonable goal if we are to make the code more 'approachable' for new contributors. Work on the info boxes The work splits into two parts: Part I - Making the background template info display use the same form as the file viewer Part II - giving the switch selector form its own area for displaying switch info instead of using the form in Part I The changes, and some of the rationale for them, are discussed here under those headings. Part I General This code: + +'||--------------------------------------------------------------' + +'|| Information about this template :' + +'||( all dimensions in millimetres )' + +'||'+keeps_list.Strings[list_position] + +'||--------------------------------------------------------------' + +'|| Your memo notes for this template :' + +'||'+memo_text_str{) out 0.91.b}; ... was duplicated in two places. I have brought this together so it is in a common area of the code. I considered a couple of options, but decided hte best area the was common to the two paths of logic is inside the form where it would be shown. (Basically we pass the form the template and make the form responsible for how it looks.) Most of the other changes flow on from this change. data_memo_unit.pas This form gets three new procedures: set_content - which takes a list_position indicating the template, generates the neccessary strings and inserts them into the form. reset_position - which places the form into the bottom-right corner show_template_info - which calls the other two in turn Reset_position need only be called when the show_info button is pressed. This means that: - the content can be changed without the form moving, and - the 'Show Info' button can be used to bring the form back in view if it is lost for some reason. Note also that this form is now the only one who needs to know if it is showing already. pad_unit.pas Common code moved to data_memo_unit. Part II General The role of the data_child form is taken by a Tmemo component. The code to generate the lines which fill this component are moved from Math_unit into this form, to be consistent with the ideas in Part I and to help relieve 'math' of some of its burden. The rest of the changes are fairly straightforward. keep_select.pas Linkage with data_child_form reduced/simplified. math_unit.pas The entire code around formatting strings for a switch (show_switch_info) is moved to the data_child form switch_select.lfm New area 'switch_info' (Tmemo) added to take over from data_child_form in displaying switch data. Also a new button to copy the text of the switch_info field to the clipboard. switch_select.pas Three new procedures - resize_big - resize_small, and - show_switch_info Again, the changing of the data and the resizing of the form are split to help clarity and give better control over events Anyway, code attached below. I am still testing, so not ready for prime time just yet, but I wanted to get this out there, as it is looking OK so far. Cheers, Graeme |
|||
| Attachment: attach_2941_3544_info_boxen.zip 1 time) | ||||
|
posted: 29 Nov 2019 12:00 from: Martin Wynne
click the date to link to this post click member name to view archived images |
pad_unit and math_unit seem to be our 'problem children' in that they are by far the biggest units (and 32,000+ and 28,000+ are not small by any definition). Hi Graeme, You have been busy. Many thanks for all that. pad_unit and math_unit were originally a single unit. There were problems in an earlier version of Delphi with the editor not liking more than 32767 (signed 16-bit) lines. So I pulled out all the math stuff into a separate unit. That was some time around 2002, since when they have both continued to grow separately and are now ripe for some more housekeeping. As are most of the other files, as you found. However, once you start re-arranging the furniture one thing leads to another and it never ends. You also tend to discover some long-forgotten reason why you did things the way you did in the first place. So I tend to fall back on IIABDFI yet again, and things gradually get even worse. So good luck with all that -- you may be gone some time! As you probably noticed I released 225a of T2 today for the BGS3 file format, so I need to do some forum housekeeping for that and do the release notes before I look at anything else. Also the sun is shining today for the first time in days, so I'm putting my boots on as we speak. I will have a look at your good work when I get back. cheers, Martin. |
|||
|
posted: 29 Nov 2019 15:01 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: However, once you start re-arranging the furniture one thing leads to another and it never ends. Yes indeed! Unless it is a deliberate attempt to tidy things a bit, I will normally try not to touch things which are not related to what I am doing, ... but it can be difficult! Anyway, absolutely no rush to look at this. Partly, I wanted to get it into the November 'Clips', and as I mentioned, I want to give it more of a workout myself before claiming it is 'ready'. There are sure to be bits of functionality I don't even know about which will trip me up, but it's a start. Enjoy the sunshine! Graeme PS Thanks (AGAIN!) for a lovely piece of background info. I would never have picked 'math' as a breakaway from 'pad'. I just assumed it was an original piece. Just goes to show! |
|||
| Last edited on 29 Nov 2019 15:05 by Graeme |
||||
|
posted: 29 Nov 2019 22:21 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, Did you forget to include switch_select.lfm in your post? You are referencing a component switch_info:TMemo; which isn't on the existing form, so not surprisingly all I'm getting is an AV when clicking the button. I'm a bit surprised that the Lazarus compiler isn't complaining about it.I'm finding your indenting style: begin if check_valid_switch_selected=False then EXIT; // no switch or no data for it. if switch_info_showing=True then begin show_info_button.Caption := 'show switch info'; resize_small(); switch_info_showing := False; end else begin show_switch_info(full_size_mm_radiobutton.Checked, switch_info_showing); show_info_button.Caption := 'hide switch info'; resize_big(); switch_info_showing := True; end; // ??? Is this next line required? ??? if switch_selector_listbox.Visible then switch_selector_listbox.SetFocus; end; very difficult to follow. I realise I will need to be flexible and less set in my ways for a collaborative project, but I'm wondering if there is a reason for not following my style: begin if check_valid_switch_selected=False then EXIT; // no switch or no data for it. if switch_info_showing=True then begin data_child_form.Close; show_info_button.Caption:='show switch &info'; switch_info_showing:=False; end else begin show_switch_info(full_size_mm_radiobutton.Checked,switch_info_showing); show_info_button.Caption:='hide switch &info'; switch_info_showing:=True; end; if switch_selector_listbox.Visible then switch_selector_listbox.SetFocus; end; where I have then and any corresponding else in the same column, and likewise all begins and corresponding ends in the same column? With all conditional stuff significantly indented? I find it so much easier to read and follow that way. Also, why are you putting spaces around all the operators? Is there a reason for it? I have noticed other programmers do it too. For some reason it makes it extremely difficult for my brain to read and take in. For example: show_info_button.Caption := 'show switch info'; switch_info_showing := False; instead of my show_info_button.Caption:='show switch &info'; switch_info_showing:=False; By the way you have omitted the & character from the button caption, which puts the underline on the accelerator key character. The answer to your question about setting focus back on the listbox is that it enables the keyboard arrow keys to be used to run up and down the list after focus has shifted to the button. I notice that you have resize procedures, which you have made private methods of the form class. Is there a reason for doing that? It's not likely that we would ever want more than one instance of that form, or want to inherit another one from it. I would have simply added them as procedures in the implementation section, and provided they occur before they are referenced (Pascal is a single-pass compiler) there is no need to separately declare them at all. If for some reason they can't occur before being referenced, they can be pre-declared with the forward; statement. (Unless they need to be referenced from some other unit, in which case they do need to be declared in the interface section.) But in this case they are not referenced anywhere other than in the above procedure, so they might just as well be nested child procedures within it. That way everything is kept nicely contained in one place, and there is no risk of conflict with any similar-named procedures anywhere else: procedure Tswitch_select_form.show_info_buttonClick(Sender: TObject); var dummy:integer; // keep Delphi compiler happy for nested procedures /////////////////// procedure resize_big; // Allow for switch info to show begin Width:=datestamp_label.Width +switch_info.Width +4; Height:=switch_info.Top +switch_info.Height +4; end; /////////////////// procedure resize_small; // Hide switch info begin Width:=datestamp_label.Width; Height:=datestamp_label.Top +datestamp_label.Height +4; end; /////////////////// begin if check_valid_switch_selected=False then EXIT; // no switch or no data for it. if switch_info_showing=True then begin show_info_button.Caption:='show switch &info'; resize_small; switch_info_showing:=False; end else begin show_switch_info(full_size_mm_radiobutton.Checked, switch_info_showing); show_info_button.Caption:='hide switch &info'; resize_big; switch_info_showing:=True; end; if switch_selector_listbox.Visible then switch_selector_listbox.SetFocus; end; Also, why the need for () if there are no parameters to be supplied? That's enough carping from me. Many thanks for what you are doing. What I'm finding very difficult to fathom is how to merge the units together? While you have been making changes to these units, I have also been making changes to some of them. Which means we now have 3 versions of each file: 1. as currently on SourceForge 2. as modified by you 3. as modified by me Which of us does the merging and conflict resolution? What happens if while one or other of us is doing that, the other makes some further changes -- which may or may not be compatible with the results of the merging? WinMerge allows 3-way diffing, so I have just opened the above 3 versions of keep_select.pas, and there are so many differences that I hardly know where to begin. What seems obvious is that doing this every time any one of a group of programmers changes something in one file, with consequent changes needed in some other file, it is going to take 10 times longer than making the actual change in the first place. How do other groups manage this? cheers for now, Martin. |
|||
|
posted: 29 Nov 2019 22:46 from: Rob Manchester
click the date to link to this post click member name to view archived images |
Hi Martin/Graeme, Good to read of your exploits on this. I must sit on Martin's side regarding the program indentation - for me personally I struggle with other layouts. In my old programming days ( 1975-85 ish ) everybody seemed to just do it that way so it became normal to us - that is after we threw off the shackles of non-structured Basic and Fortran I am not sure I understand how a shared development environment works. Does each contributor get a nod of approval from the others ( or at least from the project leader ) before starting work on a feature ? If not then surely there is a risk of total chaos down the line or am I missing something ? I don't see the new Templot having many contributors so it will probably not be an issue anyway. Hope you had a good walk Martin Rob |
|||
|
posted: 29 Nov 2019 23:40 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Rob Manchester wrote:Hope you had a good walk MartinHi Rob, Yes thanks. A very squelchy walk after so much rain, but a bit of sunshine makes all the difference. A few pics: 2_291834_130000002.jpg  2_291834_130000001.jpg  2_291834_130000003.jpg  2_291834_130000000.jpg  Upper Arley, SO 766 802. So much for keeping this section on-topic. cheers, Martin. |
|||
|
posted: 30 Nov 2019 04:10 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: Did you forget to include switch_select.lfm in your post?Arrrgh! YEs, Apologies. I should have included that and NOT keep_select.lfm. That one does not need to be updated. (I remember this problem of .lfm file changing willy nilly from the olden days working in VB. I do not necessarily want every move of a form on the screen to be a change to the program. Sometimes I am just getting it out of the way. I guess you would get used to it in time, but I wish there was a button or setting that said "I am editing forms"/"I am not editing forms".) Anyway, I have added the new switch_select.lfm below. Again my apologies for my error. I will reply to the other points a little later. Cheers, Graeme |
|||
| Attachment: attach_2943_3544_keep_select.lfm 1 time) | ||||
|
posted: 30 Nov 2019 06:12 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, er, that's keep_select.lfm again. cheers, Martin. |
|||
|
posted: 30 Nov 2019 07:37 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Rob Manchester wrote:I am not sure I understand how a shared development environment works. Does each contributor get a nod of approval from the others ( or at least from the project leader ) before starting work on a feature ? If not then surely there is a risk of total chaos down the line or am I missing something ? I don't see the new Templot having many contributors so it will probably not be an issue anyway.Hi Rob, Given that the whole thing is entirely voluntary, it's difficult to see how anyone could be required or prevented from doing anything. I know there are systems where once a file has been "checked out" like a library book, by one person, it becomes unavailable, or read-only, to everyone else. But that clearly requires that the files are kept on a common network system somewhere, rather than locally. It occurs to me more often than is comfortable, that Templot is such a textbook example of how NOT to write a computer program, that no self-respecting IT professional is willing to have his or her name anywhere near it. So we are left with just me and the brave to soldier on. I'm happy to change user names on here to an anonymous nickname if anyone so wishes. (My email address can be found in my Profile by clicking my name on the left.) cheers, Martin. |
|||
|
posted: 30 Nov 2019 09:41 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: er, that's keep_select.lfm again. Oh crumbs! So much for my 'Focused Mind' courses. I will demand a refund right away! Please accept my apologies and try this one instead. graeme |
|||
| Attachment: attach_2944_3544_switch_select.lfm 2 | ||||
|
posted: 30 Nov 2019 12:43 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: I'm finding your indenting style ... very difficult to follow. I realise I will need to be flexible and less set in my ways for a collaborative project, but I'm wondering if there is a reason for not following my style. I am not surprised! You will certainly need some flexibility, but NOT to accept nonsense like this. No, fear not - I would never format code like this, and I have no idea how it got to be like this. (Obviously something I did, but I know not what. ) I promise not to do it again!Also, why are you putting spaces around all the operators? Is there a reason for it? I have noticed other programmers do it too. For some reason it makes it extremely difficult for my brain to read and take in. For example: Well, yes, you will find this is pretty standard practice. That is why most programmers you will encounter would do it. The reason being that it is so much easier to read - hahaha - but maybe I am just used to it. But seriously, looking at the examples above, the first is an order of magnitude easier for me than the second. Thesecondisabitlikereadingasentencewithoutspaces! This may be one you have to try to let go on, because we would end up trying to change the whole world on this point. For example, the standards propounded by Borland, now hosted on the Embercardo web site (http://edn.embarcadero.com/article/10280#8.1.1) By the way you have omitted the & character from the button caption, which puts the underline on the accelerator key character. Yes, thank you. I had forgotten that use of '&'. (Same as Visual Basic, if I remember correctly.) The answer to your question about setting focus back on the listbox is that it enables the keyboard arrow keys to be used to run up and down the list after focus has shifted to the button.Ah yes - understood. I notice that you have resize procedures, which you have made private methods of the form class. Is there a reason for doing that? It's not likely that we would ever want more than one instance of that form, or want to inherit another one from it. I would have simply added them as procedures in the implementation section ...Hmmmm - possibly ignorance on my part. I do remember agonising over this, and in particular, thinking "what's the point of putting a Private element in the interface at all? Surely that's what the Implementation section is for?" I understand the interface section is for things referenced from outside ... but then why have Private things there? I seem to recall I had it in the implementation section at first, but I can't remember why I put it in the Interface in the end. (Googling for a while did not answer my question on the Interface/Private combination). But in this case they are not referenced anywhere other than in the above procedure, so they might just as well be nested child procedures within it. That way everything is kept nicely contained in one place, and there is no risk of conflict with any similar-named procedures anywhere else: ... I understand the use of nested procedures in some cases. However, in this particular case, I feel that the action of the procedures (i.e. resizing the form) is something 'bigger' in some sense than the showing of the switch info. It seems to me happenstance that they are used in only one place. If a function does a calculation that is clearly only of use in one procedure, I would agree. Define it nested. But to me, in this case the 'single-place use' is just 'how things worked out' and not really something fundamental to the structure of the logic. (I don't feel hugely strongly though. You can usually tell - I have lots of 'quotes' in my response )Also, why the need for () if there are no parameters to be supplied?No need whatsoever. I have programmed in Ruby, where leaving off the () is the norm, and can lead to some very readable code. Many languages require the () of course. Even where they are not required, some projects I have worked on insist they be included as a sign to the reader that they are dealing with a function and not a variable, which is why I added them here. These procedures are large and have a LOT of local names. I did it because I thought it would help ME in the future. I don't feel strongly either way and will adopt your usage (or rather LACK of usage - hahaha)Many thanks for what you are doing.My pleasure. This was a really great change for me to do as it got me into what is really the heart of the matter, dealing with templates, switches and the trackpad. Still lots to learn, of course, but these were key units to cut my teeth on. I will make another post on formatting, as I have another thought on that, but will do it tomorrow so it can make the December 'clips'. I will make another post tomorrow on your questions about diffing and merging too. Martin, thanks for taking the time to review all this stuff. I appreciate all the comments and aplogise again for the formatting of my procedure. For what it's worth, I would normally have produced something like this...
Not quite as you have it, I realise, (I am used to fixed-width indents) but hopefully demonstrating that I do like things to look nice. Cheers, Graeme |
|||
| Last edited on 30 Nov 2019 13:12 by Graeme |
||||
|
posted: 30 Nov 2019 12:53 from: Graeme
click the date to link to this post click member name to view archived images |
Rob Manchester wrote: I must sit on Martin's side regarding the program indentationYes, Rob, so do I, of course. Please refer to my response to Martin for what I hope is suitably abject grovelling for forgiveness. In my old programming days ( 1975-85 ishYes, I was part of that same 'everybody' having started in '75 myself - except in my case it was unstructured COBOL. The company I worked for, though, had already realised the perils of unrestricted GOTO and so we had very strict standards of how to code in a 'structured' way using the facilities COBOL provided in those days (basically IF, GOTO and labels . Welllll ... there WAS a loop, but not easy to recognise as such these days.)I am not sure I understand how a shared development environment works.....I will do another post on this to explain how it has worked on the other open source projects to which I have made contributions. Cheers, g |
|||
|
posted: 30 Nov 2019 12:56 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: A few pics:Oh ... BEAUTIFUL!!! Pictures like these really make me want to come back to the UK. I am envious. |
|||
|
posted: 30 Nov 2019 13:16 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Graeme wrote:Oh ... BEAUTIFUL!!!Hi Graeme, Thanks. We do have an outdoor photography topic on here with several pages of such. In fact that is where I should have posted them. You are very welcome to add pictures from your part of the world if you wish: topic 3228 cheers, Martin. |
|||
|
posted: 30 Nov 2019 13:36 from: Graeme
click the date to link to this post click member name to view archived images |
Martin Wynne wrote: You are very welcome to add pictures from your part of the world if you wish Thank you. Lots of lovely time-wasting browsing through there, I can see! I will see what I can dig out to post from the pics I have from round here. As chance would have it we took our visitor to a nearby resort town and I took some pics of the railway there. Nothing outstanding, but if the details of the turnouts I took would be of interest I will post them to the 'Prototype' topic. Cheers, graeme |
|||
|
posted: 30 Nov 2019 17:03 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme,I will make another post on formatting, as I have another thought on that, but will do it tomorrow so it can make the December 'clips'.I don't think we need to be too strict about that -- if you want to start the December topic in November, please go ahead.
Hmm. That's worrying, because for me it is an order of magnitude the other way. I've been trying to work out why that might be. I think it's that if I see: abc:=123; I see only 2 things, an object and its value, like an adjective describing a noun: hot water. The := operator is read as punctuation. All my brain needs to do is associate the object with its current value. Whereas if I see: abc := 123; I see 3 things, the := operator becomes a word in its own right, not merely punctuation, and the line demands to be read as a full sentence: the water is hot. Which not only takes much longer, but seems to involve an entirely different brain function. Also nowadays with failing memory, by the time I've reached hot I've forgotten that it's water we are talking about and I need to read it all again. 2 things I can remember, 3 is asking a bit much. This memory thing may be why my preference for the shorter style seems to have hardened over the years, and I now sometimes edit the spaces out of code on web sites before reading it so that I can understand it clearly. I don't think the analogy with ordinary text holds good -- not much plain text has characters such as := or <> in the middle of a sentence. Also most printed text uses a variable-width font where spaces are much narrower than most other characters. For coding we need a fixed-width font which makes the spaces much wider and more prominent and interruptive when scanning a line. (Also, ordinary text doesn't normally put a space between a word and a following colon, so to read as normal text should it not be: abc: = 123; ?) However, I have lived long enough to know that if the entire world does something one way, and I do it a different way, guess which one is going to have to change. All that having been said, in practice code is viewed in a compiler editor such as Lazarus or Delphi, where coloured syntax highlighting makes the operators blindingly obvious and as far as I can see eliminates any justification for spaces around them: 2_301737_210000000.png  Likewise in the excellent Notepad++ coder's text editor you have full control over the syntax highlighting: 2_301735_120000000.png  Notepad++ (free) is at: http://notepad-plus-plus.org/ Thanks for the link to the Pascal style guide. I have never seen that page before. But I disagreed with so much of it that I stopped reading half way through. Sigh. Martin. |
|||
|
posted: 30 Nov 2019 23:11 from: Martin Wynne
click the date to link to this post click member name to view archived images |
Hi Graeme, Looking at this again with an hour to go before the December deadline , I notice you have made a few changes from my Delphi original:2_301737_210000000.png I had if full_size_mm=True You have commented off the =True (and put a space between = and True). I realise this is optional in Pascal, and I sometimes use both forms. But I think the =True form is clearer, and certainly makes for faster reading when skimming through the code to check the program flow. I agree it makes more sense to leave off the =True in a case such as if a=3 then rather than if (a=3)=True then But if you are not going to add =True to the condition, why leave it as a comment? That seems to defy any logic. I also noticed that you moved the ends so that they no longer line up with the begins (or in fact with anything else). Whatever that is trying to achieve, it certainly fails with me. Apologies if this is all getting too pedantic. Perhaps I need to spend less time on the computer and more time in the hills with my camera. cheers, Martin. |
|||
|
posted: 1 Dec 2019 05:33 from: Graeme
click the date to link to this post click member name to view archived images |
So after waiting for the December 'Clips' I decided that formatting was worthy of a topic in its own right, and so the remaining item here that I wanted to comment on was better here in November so it is nearer the original post. Martin Wynne wrote: I had if full_size_mm=True Hahaha - again, my view is pretty much the exact opposite. IF is followed by an expression with a boolean value. A boolean variable is a perfectly good expression and with a carefully chosen name produces very readable code. Adding '=True' to the end adds nothing but visual clutter, and gives you more to read. For me the less I read the quicker I will be, in general. BUT ... the main point of this post ... You have commented off the =True (and put a space between = and True). I had noted that elsewhere that you omitted the redundant '=True', but I still felt it would be a bit rude to simply change your code. I left the comment there as a reminder to prompt a discussion. It was not meant to be a permanent artifact. I also noticed that you moved the ends so that they no longer line up with the begins (or in fact with anything else). Whatever that is trying to achieve, it certainly fails with me. Hmmm - error on my part. As per my previous post, I would normally have ends lining up. (This is the second time. I am beginning to wonder if I am having some spaces vs tabs issue. )Apologies if this is all getting too pedantic. Perhaps I need to spend less time on the computer and more time in the hills with my camera. Not at all. I promised myself that I would not get into any specific formatting discussions, but it is hard not to. With the views you have around, I am surprised that you get to the computer at all! Cheers, graeme |
|||
| Please read this important note about copyright: Unless stated otherwise, all the files submitted to this web site are copyright and the property of the respective contributor. You are welcome to use them for your own personal non-commercial purposes, and in your messages on this web site. If you want to publish any of this material elsewhere or use it commercially, you must first obtain the owner's permission to do so. |