5.22 on Win10: Problems with setting Elevations


Robert Scott
 

Adam.

Its strictly a preference thing, what I am accustomed to.

If you consider how a real railway is placed on a real landscape, it begins by identifying the features that they need to go around and joining the curves with tangents. Nature doesn't do straight lines and perfect circles, so in "terrain", curves of varying radii and tangents that are large radius curves are the norm.. On the flatland, straight track and uniform curves, but in hill country, the track accommodates the landscape, flowing across it

Bob

On Monday, March 29, 2021, 04:13:51 p.m. EDT, Adam Richards <adamjmrichards@...> wrote:


Would be interested in the modify, edit or split comment detail. There have been some advances in V5.2 on that, and I’m always interested in new use cases.

FWIW - Cornu are now fully splittable and you can add also pins to modify them to “pin” to follow any route if you dislike the default one. Pins are supported in modify by round-trip editing (Adjacent Cornu that result from a pin or split operation automatically open as a single Cornu with a pin at the joint which you can move or remove or leave ad you alter the rest of the curve). The only interesting edge case I have come across is if you split a Cornu, delete one half and then snap on a straight or curve. In that case modify/editing may change the shape because the end conditions changed (from whatever the split end radius was to the new joined track). We could add a check and recompute the curve when joining to an existing Cornu.

Adam


On Mon, Mar 29, 2021 at 11:31 AM, Robert Scott via groups.io <sparky1bob=yahoo.ca@groups.io> wrote:
Thanks for the info.

Cornu curves, while convenient, can be difficult to modify, edit or split. I find i am happier with the result if I join curves of varying radii with easements.
i guess the result is 10,000 track pieces, although in reality, full length flex track would be shaped to follow the center line.
The number of pieces does slow updating as the map is moved.

Bob
On Monday, March 29, 2021, 11:28:38 a.m. EDT, Adam Richards <adamjmrichards@...> wrote:


The fixes for Ian's issues were relatively late, so the latest code has the issues he raised fixed and that is what I tested with.  A major difference will be the that blue ball will only appear with Alt.  (On Mac, Alt could be  
Cmd depending on XQuartz Input settings).

Adam

--
Adam Richards


Robert Scott
 

Good day.

Those are trees, on the landscape layer, multiplied using copy and paste, although I can't imagine I will put 10,000 of them on the layout.

Layers 9 thru 16 are non track objects, efforts to fill in the details between the tracks, such as water, trackbed, landscape and structures.
The track plan I attached is far from complete.

Bob

On Monday, March 29, 2021, 03:07:06 p.m. EDT, Dave Bullis <sillub@...> wrote:


I haven't looked at the elevation but I was curious how you got 10K objects
Turns out almost all of them are green filled circles: wow!
You have about 180 track pieces

Dave


Adam Richards
 

Would be interested in the modify, edit or split comment detail. There have been some advances in V5.2 on that, and I’m always interested in new use cases.

FWIW - Cornu are now fully splittable and you can add also pins to modify them to “pin” to follow any route if you dislike the default one. Pins are supported in modify by round-trip editing (Adjacent Cornu that result from a pin or split operation automatically open as a single Cornu with a pin at the joint which you can move or remove or leave ad you alter the rest of the curve). The only interesting edge case I have come across is if you split a Cornu, delete one half and then snap on a straight or curve. In that case modify/editing may change the shape because the end conditions changed (from whatever the split end radius was to the new joined track). We could add a check and recompute the curve when joining to an existing Cornu.

Adam


On Mon, Mar 29, 2021 at 11:31 AM, Robert Scott via groups.io <sparky1bob=yahoo.ca@groups.io> wrote:
Thanks for the info.

Cornu curves, while convenient, can be difficult to modify, edit or split. I find i am happier with the result if I join curves of varying radii with easements.
i guess the result is 10,000 track pieces, although in reality, full length flex track would be shaped to follow the center line.
The number of pieces does slow updating as the map is moved.

Bob
On Monday, March 29, 2021, 11:28:38 a.m. EDT, Adam Richards <adamjmrichards@...> wrote:


The fixes for Ian's issues were relatively late, so the latest code has the issues he raised fixed and that is what I tested with.  A major difference will be the that blue ball will only appear with Alt.  (On Mac, Alt could be  
Cmd depending on XQuartz Input settings).

Adam

--
Adam Richards


Dave Bullis
 

I haven't looked at the elevation but I was curious how you got 10K objects
Turns out almost all of them are green filled circles: wow!
You have about 180 track pieces

Dave


Robert Scott
 

Thanks for the info.

Cornu curves, while convenient, can be difficult to modify, edit or split. I find i am happier with the result if I join curves of varying radii with easements.
i guess the result is 10,000 track pieces, although in reality, full length flex track would be shaped to follow the center line.
The number of pieces does slow updating as the map is moved.

Bob

On Monday, March 29, 2021, 11:28:38 a.m. EDT, Adam Richards <adamjmrichards@...> wrote:


The fixes for Ian's issues were relatively late, so the latest code has the issues he raised fixed and that is what I tested with.  A major difference will be the that blue ball will only appear with Alt.  (On Mac, Alt could be  
Cmd depending on XQuartz Input settings).

Adam


Adam Richards
 

The fixes for Ian's issues were relatively late, so the latest code has the issues he raised fixed and that is what I tested with.  A major difference will be the that blue ball will only appear with Alt.  (On Mac, Alt could be  
Cmd depending on XQuartz Input settings).

Adam


Adam Richards
 

Robert,
The open circle appears wherever there is a track joint (or end). I tested on your xtc and that is accurately showing those points where a click will allow an elevations to be set. All the signalled points at 10'x4' are track joints.  You have, in at least one case, remarkably small track pieces, all of which will have the open ball at both their ends.  You'll see this when zoomed in. This maybe how you arrived at over 10,000 track pieces - one of the highest totals I have seen. If I might be so bold, your plan could benefit from some use of Cornus to replace these sections and so drop the track count which would speed up loading.  

Note that the track being followed by the blue ball can flip as tracks are near each other if the other track is higher in "draw order". The assumption by the tool is that higher tracks will be "Above" lower tracks and so preferred. But there is no actual enforcement of order in XTrackCAD and new tracks are always "Above" older tracks until the Above/Below is used.  As the ball flips tracks, that may give rise to a suspicion that it is "jumping" - it literally is - to the other track. This draw order also determines which track is listed first when a square appears.

The square will find any crossing track. It was designed to find all such tracks so that all clearances would be shown.  The fact that a track is hidden is not of concern to it as it currently exists - since seeing clearances to a hidden yard is exactly what may be required.  It could be possible to add a maximum clearance but we don't actually have vertical clearances per scale/gauge in our settings currently - it's an idea I have thought about as side clearances might also be useful in some cases. 

Adam


Robert Scott
 

Good morning.

I download the file.
It works fine.

Maybe I'll take up Knitting.

Bob


Robert Scott
 

Gentlemen.

Am running 5.2.1a on Windows 10.

"Elevations" continue to act up, in that the software seems to be reacting to track that is not displayed or does not exist.
The open circle may appear in the middle of nowhere when moving the cursor, the open square senses tracks 24" below the table top and the values from the blue circle can be nonsense right next to a defined point. ! have attached the full layout, however the aberrant behavior is most noticeable in the area of 10' vertical, 4' over.


Robert Scott
 

Gentlemen,
Am still running 5.2.1a on Windows 10, so this may have been dealt with,

It appears that "Elevation" pays attention to track that is not being displayed, so the open circle will appear "in the middle of nowhere." At times, the square seems to sense track that is 24 " below the table top and the blue ball gives odd readings right adjacent to a fixed elevation.
 I will attach the full layout, however the aberrations are most evident in the trackwork in the area of 10' vertical  and 4' horizontal.

Again, thanks for  the work you fellows do.

Bob


Robert Scott
 

Gentlemen,


Adam Richards
 

OK - change made and manual updated.


Adam Richards
 

I'll look later - I see what you mean - elevation/clearance info should be optional.  But endpoint finding is always on. 


Robert Scott
 

I think you have it, sir.
90 % or more of the time, the open circle is the item of interest.
The square and ball just clutter the display.

Bob

On Friday, February 19, 2021, 10:31:52 a.m. EST, Adam Richards <adamjmrichards@...> wrote:


The issue of the open circle (meaning here is the end track) not displaying instead of the blue ball reliably is addressed in the fix. It should be a lot more consistent now.


The square appears if two tracks are overlaid and shows the clearance between them. I think therefore you are essentially asking to make that behavior suppressable.


At the moment Shift means “I intend to split”, Ctrl means “I want to move an endpoint description”. I guess that leaves Alt to suppress the square. I think the square should live with the blueball showing elevation so if Alt suppresses all elevation info leaving just the end point open circle if close?

If we wanted to be fancy we could make it a toggle with magnetic snap, but it isn’t exactly the same thing, of course.
 

Adam


Adam Richards
 

The issue of the open circle (meaning here is the end track) not displaying instead of the blue ball reliably is addressed in the fix. It should be a lot more consistent now.


The square appears if two tracks are overlaid and shows the clearance between them. I think therefore you are essentially asking to make that behavior suppressable.


At the moment Shift means “I intend to split”, Ctrl means “I want to move an endpoint description”. I guess that leaves Alt to suppress the square. I think the square should live with the blueball showing elevation so if Alt suppresses all elevation info leaving just the end point open circle if close?

If we wanted to be fancy we could make it a toggle with magnetic snap, but it isn’t exactly the same thing, of course.
 

Adam


Robert Scott
 


Good morning,

When in the "elevations" mode, an open square, a blue ball and an open circle are displayed, depending on proximity to track elements. The display can flick from one to the other in rapid sequence, making it difficult to select the end point you want. It would be very useful to be able to turn off the features that are not in use.

Thanks

Bob

On Friday, February 19, 2021, 01:31:31 a.m. EST, Adam Richards <adamjmrichards@...> wrote:


Right - any use of a different window brings up the need to reestablish focus coming back, The Map or another window like Describe are examples. This is basic windowing technology, we never see the focus clicks, they get swallowed by the OS/GTK. The way around this is to either make the user click on "Done" which returns focus because it has to go somewhere!, or use UI items that show-up and hide inside the same window.  If you think about the Office "ribbon" it does a lot of this as you select elements, which allows it to instantly accept clicks off the pseudo-window pop-up as well.  Then all the handling is within the program (which has to remember what is active but sees everything).  Once we have a unified UI this is stuff is much easier to think about. 

Can you explain the "3 objects" comment - I'm not following that, so I can't answer yes or no. 

Adam



Adam Richards
 

Right - any use of a different window brings up the need to reestablish focus coming back, The Map or another window like Describe are examples. This is basic windowing technology, we never see the focus clicks, they get swallowed by the OS/GTK. The way around this is to either make the user click on "Done" which returns focus because it has to go somewhere!, or use UI items that show-up and hide inside the same window.  If you think about the Office "ribbon" it does a lot of this as you select elements, which allows it to instantly accept clicks off the pseudo-window pop-up as well.  Then all the handling is within the program (which has to remember what is active but sees everything).  Once we have a unified UI this is stuff is much easier to think about. 

Can you explain the "3 objects" comment - I'm not following that, so I can't answer yes or no. 

Adam



Robert Scott
 

Good evening,
Would it be possible to toggle the three objects on and off individually??
All three active at the same time can make for a confusing display.

The need to click twice often presents itself in other functions. When clicking on the map window when an instruction is active, such as "curved track", the click on the map window also establishes the start of the track and then the "return to main window" click also establishes the end point of the track. Other two step functions such as "curved line" and "box" do the same.

You fellows work hard enough and I hesitate to "complain."
Thanks for your efforts.

Bob


Adam Richards
 

No - all you have to do (according to my testing) is to try clicking twice in the right place. The code that is showing whether or not showing the endpoint circle is not determining if that place actually exists or not because ---> 

There remains the accuracy of the blue ball versus the actual cursor position  The ball is placed onto any track when it is less than 2 trackguages away OR a distance of scale*0.25 (so for HO, ~1.2" at 1:1 and 2" at scale 4:1). The test currently used for showing and finding the end point is a IsClose() distance of 10 pixels at 1:1 that's 1/7th of an inch at 4:1 that's 0.5" - so in the code you found a bug that this test was not using the ball to endpoint distance but the cursor to endpoint - which means the ball could appear on the end of the track but the endpoint not be shown as the cursor was too far away).  In the revised code the distance is always measured from the blue ball to endpoint regardless of the real cursor pos...  This means that it should always show and use the real endpoint even if the cursor is off the track more than that distance but the blue ball is close enough. 

So try to position the cursor (real) accurately (wiggle it to center on the joint remembering that the ball appears before you get there) and try to get the end open ball to show but regardless always click twice...    I realize that's not as good as the fix in showing you if the result is going to find the end accurately, but clicking twice will at least get past the focus issue and not require closing/ESCing. 

Adam 

 


 


On Tue, Feb 16, 2021 at 5:48 AM Ian <ilox11@...> wrote:
Thanks, Adam and Dave. So my next step is to ESC out of Elevations once I have done one setting or evaluation?
I am Old School enough that Elevations used to work just like Information. Once I started in that mode I could shift all over the Layout making changes and the Box would update the new information. Well, it seems that isn't going to work any more so how best do I do a stack of Elevation evaluations and changes?

On Tue, 16 Feb 2021 at 20:43, Adam Richards <adamjmrichards@...> wrote:

Ian,
The most basic problem is that once an elevation point is selected, the elevation window is open and GTK/Windows gives it focus and is expecting input in that window (or a close button on it).

So when you are trying to select a different elevation before closing that elevation window the first click you make only serves to give the main window focus (and isn't passed through to our event handler at least on GTK and I suspect also Windows). Once focused, a second click then is passed through and can change the point selected (tested on GTK). And so it likely looks to you like the new point doesn't exist when you first try to click. But after you close that window, or upon a second click (even a double click!!) on the main window with the elevation window left open - it selects. Note that the cursor movements over the main window are being sent to it all the time so the displayed cursor point is moving.  Clicks count as input to the windowing model and only one window can have focus at a time.

One way to fix this is to make that elevation window "modal" (which means the main window can't be used at all while it is open) - and I think it used to be like that - but that is a pain because you keep having to close it first and can't simply click twice. It is a real UI usability dilemma.  

Meanwhile there is some other stuff that was broken for elevation --->

1. The point would open circle snap to a nearby end-point to show what would happen on click. But it did not respect either magneticSnap with or without +Alt.  I have made it respect the magneticSnap and +Alt to invert the sense of magneticSnap.  So now it will only snap if magneticSnap is On without Alt or when it is Off with Alt. (Like the other uses of the snap).  
2. The point being tested for closeness was the cursor position, but not a point on the track nearest to that position. This meant that sometimes the cursor would be off, and a dot shown when it was actually near to an end point and should have shown an open circle. (I think this is why your end points did not at least open circle).
3. +Ctl was intended to enable moving track elevation descriptions -> it calls the Description Move code but that did not correctly only show elevation descriptions but was highlighting everything. This bug came along when the Move Description code was improved.  Fixed - now it highlights only elevations.
4. +Shift is the track split function within Elevation -> It will cause a new end-point if it can - which will be highlighted correctly. 
5. Note that when not using +Ctl or +Shift, when doing a left-click the code always snaps to a nearby endpt - even if magneticSnap is set off. That was the behaviour before the highlighting was introduced, it just wasn't as obvious where the endpts will be snapped to. I have added code to exactly simulate the non-magnetic behaviour - selecting the end point if within minLength of it rather than magneticSnap that is visually close (pixels rather than fraction of an inch). I note that an endpoint is near in the InfoMessage if magnetic Snap is defeated or off).  Let me know if that is too confusing - it was the original reason I didn't include magnetic snap/defeating in the first place the elevation code always does a form of snap anyway. 

I think overall the issue is that by providing highlighting function, the highlight circles leads people to expect a endpoint will be shown and that if it isn't it won't be (one bug), and then confusion is confirmed for them when the first click doesn't "work" because the window didn't have focus (expected behavior).  The fact that a second click would work is not known to them.  I added a note to the manual, but still this is likely to trip people up. This is the same reason there needs to be a second click when placing a Turnout/Structure, incidentally.  We haven't found a way to take and reprocess that first click that would provide identical behaviour in GTK and Windows. Ultimately, using windows rather than additional flyouts within the same window gives us much less control of this sort of behavior. 

Adam

 

 



--
-- Ian



--
Adam Richards


Ian
 

Thanks, Adam and Dave. So my next step is to ESC out of Elevations once I have done one setting or evaluation?
I am Old School enough that Elevations used to work just like Information. Once I started in that mode I could shift all over the Layout making changes and the Box would update the new information. Well, it seems that isn't going to work any more so how best do I do a stack of Elevation evaluations and changes?


On Tue, 16 Feb 2021 at 20:43, Adam Richards <adamjmrichards@...> wrote:

Ian,
The most basic problem is that once an elevation point is selected, the elevation window is open and GTK/Windows gives it focus and is expecting input in that window (or a close button on it).

So when you are trying to select a different elevation before closing that elevation window the first click you make only serves to give the main window focus (and isn't passed through to our event handler at least on GTK and I suspect also Windows). Once focused, a second click then is passed through and can change the point selected (tested on GTK). And so it likely looks to you like the new point doesn't exist when you first try to click. But after you close that window, or upon a second click (even a double click!!) on the main window with the elevation window left open - it selects. Note that the cursor movements over the main window are being sent to it all the time so the displayed cursor point is moving.  Clicks count as input to the windowing model and only one window can have focus at a time.

One way to fix this is to make that elevation window "modal" (which means the main window can't be used at all while it is open) - and I think it used to be like that - but that is a pain because you keep having to close it first and can't simply click twice. It is a real UI usability dilemma.  

Meanwhile there is some other stuff that was broken for elevation --->

1. The point would open circle snap to a nearby end-point to show what would happen on click. But it did not respect either magneticSnap with or without +Alt.  I have made it respect the magneticSnap and +Alt to invert the sense of magneticSnap.  So now it will only snap if magneticSnap is On without Alt or when it is Off with Alt. (Like the other uses of the snap).  
2. The point being tested for closeness was the cursor position, but not a point on the track nearest to that position. This meant that sometimes the cursor would be off, and a dot shown when it was actually near to an end point and should have shown an open circle. (I think this is why your end points did not at least open circle).
3. +Ctl was intended to enable moving track elevation descriptions -> it calls the Description Move code but that did not correctly only show elevation descriptions but was highlighting everything. This bug came along when the Move Description code was improved.  Fixed - now it highlights only elevations.
4. +Shift is the track split function within Elevation -> It will cause a new end-point if it can - which will be highlighted correctly. 
5. Note that when not using +Ctl or +Shift, when doing a left-click the code always snaps to a nearby endpt - even if magneticSnap is set off. That was the behaviour before the highlighting was introduced, it just wasn't as obvious where the endpts will be snapped to. I have added code to exactly simulate the non-magnetic behaviour - selecting the end point if within minLength of it rather than magneticSnap that is visually close (pixels rather than fraction of an inch). I note that an endpoint is near in the InfoMessage if magnetic Snap is defeated or off).  Let me know if that is too confusing - it was the original reason I didn't include magnetic snap/defeating in the first place the elevation code always does a form of snap anyway. 

I think overall the issue is that by providing highlighting function, the highlight circles leads people to expect a endpoint will be shown and that if it isn't it won't be (one bug), and then confusion is confirmed for them when the first click doesn't "work" because the window didn't have focus (expected behavior).  The fact that a second click would work is not known to them.  I added a note to the manual, but still this is likely to trip people up. This is the same reason there needs to be a second click when placing a Turnout/Structure, incidentally.  We haven't found a way to take and reprocess that first click that would provide identical behaviour in GTK and Windows. Ultimately, using windows rather than additional flyouts within the same window gives us much less control of this sort of behavior. 

Adam

 

 



--
-- Ian