Templot5 - progress discussions

[Martin Wynne]

Who else have you got uploading to github?

Hi Steve,

You are the only one to send me a pull request, but I don't know if others can upload anything? We have 4 forks showing (not including me, who is not allowed to have one).

Chair labels look promising. At present it's possible to identify the chairs by going into the chair heaving -- that might be a way forward?

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
You are the owner of the main Github Templot5 repository.
You can make a branch, work on it, then push your change to main, or merge your branch into main ( ie it gets rid of your branch)
Your branching is the equivalent of my working only better!

At present you have not granted contributor status to me, so I cannot create branches, only forks.

forks are a special type of branch so cannot push changes into your main, only create pull requests for you to action.

The same applies to other interested parties, who so far can only make forks.

You could grant me contributor status, and then i would be able to create a branch, and update components in that, then push changes to your current head without your intervention.

But for now probably best to stick with current method.

There should be no problem for you to apply the o e line change to dfx_unit and commit it.
I believe github warns of any conflicts.

Steve

 

[Martin Wynne]

@Steve_Cornford

Thanks Steve.

Would you like contributor status? Presumably if the bus does its worst, someone needs to be?

How does that differ from collaborator status? Of course, I have no idea how to make such changes.

I was told that in Git, pull requests are the key to life, the universe, and everything. So far I have never made a pull request, and don't seem able to do so.

It doesn't seem to matter, but I'm not too happy to be in a different status to everyone else. I assumed that everyone would be created equal.

cheers,

Martin.

 

[Steve_Cornford]

Sorry Martin, I got it the wrong way round.

You may invite me to be a collaborator.

Contributor was just my term for someone who is helping but is not a collaborator

As owner you are in effect equal to all collaborators

Just don't google github great dictator for your own peace of mind



Steve

 

[Steve_Cornford]

Hi Martin,

Another step forward (I think).....:-

The chair types are correct.
Just need to work out how to get the position correct.
How to get the labels to appear on top of the chair outlines.

The labels seem to be a fixed size. Does that matter?

with a white trackpad.

I will of course add the usual caveat...
This is still experimental

All opinions gratefully received.
Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

We are both working on the same thing at the same time. Must be something in the air.

I have done it as an extension to the timber numbering (code 99).

I'll show you my code if you show me yours.

Martin.

 

[Steve_Cornford]

Hi Martin,

Yours is better!

I was using the Rails none as a switch to display the chair types.

Your idea of using the timber numbering as a switch is better.

Now you just need to roll it out to print_unit and pdf_laz_unit

Steve

 

[Martin Wynne]

Yours is better!

@Steve_Cornford

Not sure about that. Your yellow boxes are more prominent, and could be made clickable for a quick access to the chair heaving.

Timber numbering switch is here:

Needs a more prominent button somewhere for chairing. Labels also working on background templates, numbering switch is on the bgkeeps dialog.

file below,

search // MW 01-08-2024 in 3 places, lines:

23878
24312
26023

Now you just need to roll it out to print_unit and pdf_laz_unit

That should be working (just the labels, not the chair outlines), just checking ...

cheers,

Martin.

 

[Martin Wynne]

p.s.

The labels are there but prefixed with the template ID. Might be a lot of work to fix (might need to parse the label for known chairs).

This is PDF:

 

[Steve_Cornford]

Hi Martin,
Looking at your code, it is simpler and more elegant than mine, and mine only seems to work on the trackpad (so far).

I note on your printed version there is no label for the AA chair.
Also on timber X3-X there is an XN label, but on your trackpad it is ZY.

As far as the prefix is concerned could you parse the label text deleting all characters up to & including the period (fullstop or . to us mortals)?



Also I have a query regarding the labels for the CCL/R and CCR/L chairs.
Should the ones at the switch end of the check rails both be CCL/R?
And conversely should the ones at the opposite ends of the check rail both be CCR/L?


Steve

 

[Phil O]

Steve,

On the prototype, there's a CCR and a CCL at each end, no idea how that works in 3d printing.

 

[Martin Wynne]

Hi Martin,

Looking at your code, it is simpler and more elegant than mine, and mine only seems to work on the trackpad (so far).

@Steve_Cornford

Hi Steve,

My code inserts the chair labels at the template-building stage, which means there is a separate entry put in the marks list for each label.

Your code is creating the labels at the drawing stage from the existing marks list data for the chair outlines.

There are pros and cons to both. Your code is needed to be replicated in up to 9 separate places:

on the control template screen
on the background templates screen
on the paper print output for the control template
on the paper print output for the background templates
on the PDF output for the control template
on the PDF output for the background templates
on the 2D DXF exports
also perhaps on the image exports / sketchboard if we get it going in T5
and maybe also on the drawings in the storage box, although the labels wouldn't serve much purpose there.

That's not as bad as it seems -- mostly copying and pasting -- with the advantage that each one can be modified for colours, font sizes, etc. to suit each location.

My code goes to all those automatically because it is coded 99 as a timber number. So it will be the same size, font, colour, etc. as the timber numbers, and won't appear in places where the numbers don't. For example if the timber numbers layer combo is switched off in the DXF.

The better solution than either of those is to invent a new code number for the chair labels, and create a suitable representation just for them in each place. This also has the advantage that they can be made clickable. But that's a lot more work -- which is why I hadn't got round to it yet.

In fact, mine are clickable if the timber shoving is active, and it messes up the timber shoving:

Which one shall we push to GitHub for now, and come back to later?

I note on your printed version there is no label for the AA chair. Also on timber X3-X there is an XN label, but on your trackpad it is ZY.
As far as the prefix is concerned could you parse the label text deleting all characters up to & including the period (fullstop or . to us mortals)?

They are not the same size template, hence the XN instead of ZY. But where the AA label went is a puzzle.

Removing the template ID prefix that way won't work because it would remove it from the timber numbers too. There is no intelligence at that stage to differentiate chair labels from timber numbers. They are all code 99. But maybe the template ID isn't needed in such situations? It would be more logical to identify the brick rather than the template. So much still to think about, but hopefully it can wait until T5 is up and running. That is beginning to feel more urgent for some reason.

Also I have a query regarding the labels for the CCL/R and CCR/L chairs.
Should the ones at the switch end of the check rails both be CCL/R?
And conversely should the ones at the opposite ends of the check rail both be CCR/L?

That foxed me for a moment too. Perhaps I need to change the designations to avoid confusing everyone. CCL/R means CC-FLARE-IN and CCR/L means CC-FLARE-OUT (for running in the facing direction on either road). These chairs a very complex because of the option to adjust the flare lengths and end gap individually on each check rail.

Perhaps they could be called CC-ML/TR and CC-MR/TL for MS and TS roads.

Thanks again.

cheers,

Martin.

 

[Steve_Cornford]

I suppose I was thinking that there was an error as the two CCL/R are not identical in reality, nor are the two CCR/L chairs.
Depending on which check rail they are on the angle is opposite.

As far as the actual labels are concerned perhaps we can pencil in a new code, or as you have identified there are 9 places for code to be inserted, can that be done by performing a procedure or function?
In my old programming days eg Microcobol we had the option of performing a paragraph, or calling a sub routine. This OOP stuff is all new to me!

Also can we pencil in a Control Template Options form, similar to the Background Options form, and the Output Options form.
So that we can add Display Chair labels etc.


Trouble is, is this all displacement activity that gets in the way of Templot5 & hence 8 sided objects?




In the long term, would it be possible for chair labels to be moved adjacent to the chair on the timber, direction of move dependent on which rail they belong to.
Also size of label scaled in a similar way to the timber size.



Sorry for all these questions, but this Temploting is addictive!

Oh, one more question.
Would the cut & paste approach get rid of the
Template prefixes?

Steve

 

[Martin Wynne]

I suppose I was thinking that there was an error as the two CCL/R are not identical in reality, nor are the two CCR/L chairs.
Depending on which check rail they are on the angle is opposite.

As far as the actual labels are concerned perhaps we can pencil in a new code, or as you have identified there are 9 places for code to be inserted, can that be done by performing a procedure or function?
In my old programming days eg Microcobol we had the option of performing a paragraph, or calling a sub routine. This OOP stuff is all new to me!

Also can we pencil in a Control Template Options form, similar to the Background Options form, and the Output Options form.
So that we can add Display Chair labels etc.


Trouble is, is this all displacement activity that gets in the way of Templot5 & hence 8 sided objects?




In the long term, would it be possible for chair labels to be moved adjacent to the chair on the timber, direction of move dependent on which rail they belong to.
Also size of label scaled in a similar way to the timber size.



Sorry for all these questions, but this Temploting is addictive!

Oh, one more question.
Would the cut & paste approach get rid of the
Template prefixes?

Steve

@Steve_Cornford @KHC1

Hi Steve,

Yes, addictive -- don't forget to eat and drink.

I've been thinking that Keith is right -- chair labels are a significant omission at present, it's a bit silly that you have to go into the chair heaving to see which chair is which.

So perhaps we should do this thing properly, rather than a temporary stop-gap?

I suggest giving chair labels their own mark code(s) and separate option(s) to switch them on and off. Labels clickable to access the chair heaving function or other settings.

The full mark code list is a complete mess, resulting from piecemeal additions over decades. A major task to do anything about that, so for now we need to make it worse by adding some more There is a suitable range at 460..478 which we can use (479 is the dropper wire ridges).

So maybe

461 = interchangeable chair labels
462 = switch block chair labels
463 = V-crossing chair labels
464 = K-crossing chair labels
... ... other specials

468 = SC customizable chair labels

If I get the bare bones started, perhaps you could fill in the details and cosmetics?

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

I agree that there should be new tick-box options:-
Control template - display chair labels
Background Templates - display chair labels
Output options - output chair labels
Print options - print chair labels.

But only relevant to templates that have experimental chairing switched on.

This leads me to pose the foloowing:-


<Devils advocate>
Do we need a new set of mark codes for chair labels?
Could we not just have them as options associated with the existing chair outline codes?
</Devils advocate>

Adding new Mark codes 460-478

If I get the bare bones started, perhaps you could fill in the details and cosmetics?

If that is the route you prefer(as I assume you know what is coming down the road with future chair development), then yes, I will contribute where possible.

Would it be ok for you to outline what .pas & .lfm files need action?

I am a little occupied this week with grandchildren minding duties but will attempt to keep up.

Steve

 

[Martin Wynne]

I agree that there should be new tick-box options:-
Control template - display chair labels
Background Templates - display chair labels
Output options - output chair labels
Print options - print chair labels.

But only relevant to templates that have experimental chairing switched on.

This leads me to pose the foloowing:-


<Devils advocate>
Do we need a new set of mark codes for chair labels?
Could we not just have them as options associated with the existing chair outline codes?
</Devils advocate>

@Steve_Cornford

Hi Steve,

I'm just tinkering about to see where it gets me. I've put some switches here, but they might go somewhere else:

We do need new codes if we want to make the labels clickable, and control their position without a lot of complex geometry. It's much easier to set the position before the template is curved and transformed to its final location on the grid. i.e. to have the transformed label position already in the marks list.

But there are always different ways of doing things. Quite often I change my mind half-way through.

Would it be ok for you to outline what .pas & .lfm files need action? I am a little occupied this week with grandchildren minding duties but will attempt to keep up.

Don't worry about keeping up, family stuff is more important than our toy trains.

I will see how far I get -- James needs a screenshot asap for an article in S4 News. I will post what I'm doing, and maybe push it to GitHub if it looks promising.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,

That looks good.
Does the show mean it affects display, output & print?


re the check rail chairs:-

Existing users of Exactoscale & C&L chairs are used to identifying the end check rail chairs as CCL and CCR, and I believe they are used as follow:-
ms stock rail Working end == CCL, ms stock rail extension end == CCR
ts stock rail Working end == CCR , ts stock rail extension end == CCL

I think this is what @Phil O was implying.

Am I right in this description?

I suppose what I am saying is that CCL/R and CCR/L might confuse some (well it did me)

I suppose being pedantic they ought to be labelled S1CL, S1C, S1CR as per REA
Steve

 

[Martin Wynne]

Hi Martin,

That looks good.
Does the show mean it affects display, output & print?


re the check rail chairs:-

Existing users of Exactoscale & C&L chairs are used to identifying the end check rail chairs as CCL and CCR, and I believe they are used as follow:-
ms stock rail Working end == CCL, ms stock rail extension end == CCR
ts stock rail Working end == CCR , ts stock rail extension end == CCL

I think this is what @Phil O was implying.

Am I right in this description?

I suppose what I am saying is that CCL/R and CCR/L might confuse some (well it did me)

I suppose being pedantic they ought to be labelled S1CL, S1C, S1CR as per REA
Steve

@Steve_Cornford @Phil O

Hi Steve,

Well strictly, show means generate. I might remove the word show.

Once generated (i.e. into the marks list when the template is built) there can/will be downstream switches as to which outputs they appear on. They can't appear anywhere until generated.

The CCL / CCR thing is complicated, and I'm not sure we have it right yet, but I don't know what else to do.

When I wrote the designation CCL/R it means that on the main road stock rail it is CCL and on the turnout road stock rail it is CCR.

The chairs on the turnout side are generated as a mirror image of the ones on the main side. For the symmetrical chairs this makes no difference, but for chairs which are not symmetrical it does make a difference. The very same program code which generates a CCL when it is generating chairs on the main side, generates a mirror of CCL = CCR when it is generating chairs on the turnout side. i.e. the same program code and the same chair-code number, hence both have the same chair name -- CCL/R.

CCL/R is chair-code 14
CCR/L is chair-code 16

I don't see this being a problem in practice -- it is obvious which one is needed when plugging the chairs into the sockets.

---

For the interchangeable chairs, everyone of them is the same. An S1 is an S1 unless you change something, such as the rail section dimensions. This includes the CC chairs. They are all the same (unless you change the flangeway gap).

But it only includes the CCL/R and CCR/L as interchangeable chairs if they are set to fixed. i.e. meaning any template adjustments to the flare length and end gap are ignored. And only if you swap them over when using them on the opposite side of the crossing.

For the non-interchangeable chairs the designation refers only to the type of chair. A ZY chair from a 1:7 template is not the same chair as a ZY chair from a 1:8 template. They are not interchangeable, despite both being described as ZY.

This also applies to the CCL/R and CCR/L chairs when they are set to variable. They are not interchangeable and can be used only on the template they came from.

I hope this makes sense.

I can see me trying to explain this over and over again for years to come. Perhaps it needs a single chair-code and a single name, say CE chairs (check end). The snag there is that the wrong ones would be generated at the far end of the check rails -- no problem in construction, you just swap them over. But it looks daft on the templates and confusing on the raft.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin

I can see me trying to explain this over and over again for years to come.

This is what I am afraid of!

I had determined the chair code 14 & 16 business, also wondered if mark codes 501,502 and i believe 504, 505 might be able to be interpreted as CCL / CCR etc.

If we could somehow intercept the chair_type string of CCLR and CCRL and in conjuction with knowing which rail they were on map them to the widely accepted nomenclature of CCL or CCR that might be a possible solution.
As you have just stated , you must be discerning when they are used on the TS stock rail in order to generate the mirror image version.

Otherwise I can foresee users referencing the REA diagrams and wanting explanations overe & over again.

Just trying to pre-empt that.

Steve

 

[Martin Wynne]

@Steve_Cornford @KHC1 @James Walters

Hi Steve,

I now have this working on the control template. The check rail chairs are now labelled to everyone's satisfaction, I hope.

These labels are clickable, but don't yet do anything other than announce that they have been clicked.

It's all still to play for on default fonts, sizes and colours. The label backgrounds could be hatched instead of solid so that they don't totally block any detail, but the rails will always be in front of them.

I will push this to GitHub as it stands later today so that you can try it and see what you think. Getting it to look ok when straight, and when the template is curved and rotated, and for both hands, is a bit of a challenge, but it's somewhere near.

The chair labels appear only when the experimental brick_form is showing, even if the template is chaired. They can be switched off if a nuisance using the new tick-boxes.

cheers,

Martin.

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

Pushed up to GitHub.

Try rotating templates, swapping facing/trailing, swapping hand, etc.

I will now look at getting the clicks to do something useful, and then see about getting it onto the background templates and other outputs.

cheers,

Martin.

 

[Steve_Cornford]

Just synced my fork & fetched the origin, copied to my local & performed a build.
It all looks very good Martin.

Rotating
Swapping Trailing/facing
Swapping LH/RH

If I was booking.com I would award you genius level.

Good colour combination too, and the fact that the labels are now not impinging on the chairs is a definite improvement.

I just hope you enjoyed the coding.

Steve

 

[Martin Wynne]

I just hope you enjoyed the coding.

@Steve_Cornford

Thanks Steve.

I did actually. It made a nice change to be typing code instead of explanations. The weather was a bit grey today too, so no reason to go out much. And a boiled egg for lunch.

But it's all just a guess for colours and fonts and sizes. Feel free to have a dabble if you can see possible improvements. I'm intending to add a colour change as the mouse hovers over a label.

I've just added an extra field to Tmark to include the rail number code. It adds to the memory usage, but that doesn't seem to be an issue these days. 30 bits remaining unused for future options, only 2 bits needed to encode the rail number. It was easier than trying to kludge it into one of the existing fields, and it gives us some spare options for the future.

The reason for it is so that clicking one of the labels can discover the rail number and go into the chair heaving. Looking at that now.

cheers,

Martin.

 

[Martin Wynne]

But it's all just a guess for colours and fonts and sizes.

@Steve_Cornford

I think perhaps transparent labels are clear (!) without being so distracting? They now go yellow when the mouse is over them for clicking. Also added a more convenient tick-box for switching them all on and off:

Also found an ancient bug in the check rail end labels. fixed.

Martin.

 

[Steve_Cornford]

Wonderful.
Bit pre-occupied at the moment, looking after two grandchildren, but fortunately the children's festival part of Sidmouth Folk Festival has come to the rescue!
Maypole dancing etc....

Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

And when you click a chair label, this happens:

The shove and chair heaving functions open, with the selected rail/chair highlighted.

That dialog is a bit large, but can be resized in the usual way without losing the functionality:

I will push this to GitHub shortly. Done.

cheers,

Martin.

 

[Martin Wynne]

@Steve_Cornford

Pushed. 16 files changed.

Martin.

 

[Steve_Cornford]

Hi Martin,
Pull Request created containing check_diffs_unit cosmetic changes
Steve

 

[Martin Wynne]

Hi Martin,
Pull Request created containing check_diffs_unit cosmetic changes
Steve

@Steve_Cornford

Hi Steve,

Many thanks for that. I've pulled, made a few more changes, and then pushed again.

The change to TPanels instead of group boxes is a big improvement.

But it started off looking like this, and with scrollbars showing:

The panels have 3D-effect raised borders. This is a left-over from the early days of Windows. With coloured panels acting as group boxes, I think this looks better switched off, leaving plain panel borders:

I also increased the width of the panels, to leave a bit more space around the buttons.

This is a child form of pad_form:

For reasons known only to itself, Microsoft gives child forms a wide 9-pixel border all round, unlike all other forms which nowadays have a single line border. You can see that with a Width set to 512 the actual overall width is 530:

Accordingly we don't need datestamp_label to create a border, and I deleted it. I should have done that ages ago on all the child forms. We can use the dimensions of the yellow hide panel to set the corner of the client area and thus the client sizes when resizing with the program size slider.

Lazarus uses the form Width and Height values to mean the same as ClientWidth and ClientHeight. It's best to set them to match the original Delphi sizes showing in the OnCreate event for each form, and make sure the dimensions of the yellow hide panel correspond:

Left + Width, 452+60 = 512
Top + Height, 188+24 = 212

That way the form should look neat in all versions of Windows, and also after resizing with the slider.

If you temporarily change the form Color it is easier to see what's going on:

Changing it back to match the border colour $00F1E3D7 looks neater.

I've pushed these changes to GitHub, but feel free to make more changes if you wish.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin, that is strange as on my laptop it did not have the scroll bars.
I did increase the height to 220 to get the group panels to fit, without realizing the consequences of it being a child form.
Another thing to learn & check.
The trigger for editing it was testing the lengthen button when chair labels are switched on.

So for group panels our convention is all bevels set to bvNone, and border style bsSingle.
Which is what I thought I had set.

Steve

 

[Martin Wynne]

Hi Martin, that is strange as on my laptop it did not have the scroll bars.

@Steve_Cornford

Hi Steve,

That's odd. It may be related to your using 96dpi screen, or it may be because you are using the small program size setting at run time.

Have you fetched the changes which I've pushed to GitHub? How does it look when you run it?

The bevel setting is odd. Your original pull .lfm request contained no bevel detail at all:

My version which I pushed back has the outer bevel set to bvNone, but no mention of the inner bevel. Both were set to bvNone in Lazarus when I saved the file.

It seems that an lfm file contains only changes from the Lazarus defaults for a control. It would have been useful for us to have discovered that a lot earlier.

cheers,

Martin.

 

[Steve_Cornford]

I have been setting my desktop to 125% scaling when using lazarus ide.
I have got program slider set to small.
I have synced my branch and your changes look good.
Been having a play with panning_unit.
the up down symbols for the paper/scroll buttons are a bit strange.
Steve

 

[Martin Wynne]

Been having a play with panning_unit.
the up down symbols for the paper/scroll buttons are a bit strange.

@Steve_Cornford

Hi Steve,

The settings for the glyph bitmap on the buttons are:

Margin -1 is intended to mean the glyph is centralized on the panning button, but you may want to change it to get a better result.

The direction groupbox needs changing to a TPanel as before.

Thanks for doing all these -- there are far more forms needing attention than I realised.

cheers,

Martin.

 

[Martin Wynne]

I have got program slider set to small.

@Steve_Cornford

Hi Steve,

That's the reason you didn't see the scrollbars.

With the program size slider set to anything other than medium, the do_dpi_aware_scaling function in startup_unit.pas resets the ClientWidth and ClientHeight to match the new bottom-most, right-most corner of all the resized controls (instead of using the size settings in the OnCreate event). This is the purpose of the datestamp_label control -- to create a border space after resizing, around all the other controls, on forms where Windows doesn't add a border.

This has all been working fine in Delphi for years, but I'm wondering if it needs a change for Lazarus. Specifically, a resize call on every startup, even for the default medium setting. This would guarantee that no scrollbars appear at any time on any system.

I'm getting a bit bad-tempered with Lazarus -- so much stuff which worked fine in Delphi is needing cosmetic changes just to look right in Lazarus.

No doubt it will all be ok in the end, but it's making a lot of unnecessary work in the meantime.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
Be careful now, we don't want you to be sucked into Improving the Lazarus IDE system at the expense of PlugTrack development

Steve

 

[Martin Wynne]

Hi Martin,
Be careful now, we don't want you to be sucked into Improving the Lazarus IDE system at the expense of PlugTrack development

Steve

@Steve_Cornford

Hi Steve,

Don't worry, I'm not going there. I know I'm too easily distracted (47S ?) and need to guard against it.

Just at the moment I've been thinking about the sketchboard. A total re-write as an open-source function would be a major distraction. But there are two other options:

1. a separate helper executable similar to the way we have done the PDF export. Still a lot of work, but maybe doable.

2. a combined Templot2/Templot5 release which would permit swapping from one to the other and back with only a few clicks. This would mean:

a. users of Templot2 could swap forward to Templot5 to get the latest functions (clickable chair labels now, and other stuff when it's done such as the K-crossings, slab & bracket, etc,).​

​

b. users of Templot5 could swap back to Templot2 to get the sketchboard, existing file viewer, etc., and also to use the Templot2 automated program updates.​

​

c. we could get an interim version of Templot5 released in the short term (maybe before Scaleforum) without needing to remove all the rough edges first.​

​

---

The other attractive distraction is to forget the whole damn thing and go for a walk in the sunshine. I am feeling very weary of it all and I STILL haven't written a proper reply for Graham on creating GWR V-crossings from the Paddington drawings. I will maybe at least do the scans later today.

cheers,

Martin.

 

[Steve_Cornford]

Hi Martin,
I seem to have been hijacked by Sweep!

What's that Sweep?

A walk in the sunshine with a boiled egg picnic sounds like a good idea!

You think it's going to get warmer over the weekend!

Fresh air is good for your brain cells!

Sweep.

 

[Steve_Cornford]

pull request created for Panning_unit etc.
Steve

 

[Steve_Cornford]

Hi Martin,
Panning_unit
I changed the direction label fo t colour to blue in an attempt to visually link it to the 4 blue pan glyph.
I attempted the same for the radio butto text, but apparently this is ignored under the windows regime!
A solution is to replace the radio button captions with labels that can be blue.
Do you think it is worth it?
hope your walk restored you.
Steve

 

[Martin Wynne]

@Steve_Cornford

Hi Steve,

Thanks for doing that.

Yes, Windows won't allow different colours for the standard button controls and tick-boxes. It's been that way for ever, so we may as well accept it. We can't fix everything. If colour is essential we could use different controls.

There's a strange bug, if it is a bug, in Lazarus. I noticed it on the chair heaving form and its the same on the panning form. Shrinking the form on the buttons caused the ClientHeight to increase for no apparent reason:

(Those buttons can be clicked twice -- separate clicks, not a double-click -- to shrink the form in 2 stages. Useful to save space if working on a small screen, although I don't know how much they get used.)

I fixed it by adding a seemingly unnecessary line to both click events:

ClientHeight:=close_panel.Top+close_panel.Height;

Now pushed back to GitHub.

Nice short walk, but I had to get back for a visitor (family).

Thanks Sweep, and give my regards to Sooty.

Now I'm looking again at the 8-sided chair outlines and just wishing I had done them that way from the start. There's a lot of re-writing needed now.

cheers,

Martin.