5.22 on Win10: Problems with setting Elevations


Ian
 

Hi friends, I am having some real problems setting my Elevations. The results are spotty at best.

Yep, there is another video about the problem and you can see just how strangely this beast is behaving.

Version: 5.22
OS: Windows 10
Files attached: Layout, Ini and Log.
--
-- Ian


Ian
 

Oh, and a video is what I said wasn't it. Sigh. Way past my beauty sleep tonight/this morning.

5.22 Beta - Elevation Tool seems to be broken - Watch Video



On Tue, 16 Feb 2021 at 04:31, Ian via groups.io <ilox11=gmail.com@groups.io> wrote:
Hi friends, I am having some real problems setting my Elevations. The results are spotty at best.

Yep, there is another video about the problem and you can see just how strangely this beast is behaving.

Version: 5.22
OS: Windows 10
Files attached: Layout, Ini and Log.
--
-- Ian



--
-- Ian


Dave Bullis
 

The problem is that the cursor appears to jump to the track when it's close showing a blue dot on the track
But the 'real' cursor is not actually jumping.  You'll notice that the cross-hair cursor appears briefly when you click
Also the X and Y Red markers on the side rulers don't match where the blue dot is.
The real cursor is what we are using to determine if we on an end-point to update the elevation dialog.

Try holding down the Ctrl key while you're looking for endpts.  You shouldn't have the jumping cursor.
In fact you won't see the blue dot or the current elevation either

Turning the magnetic snap on or off doesn't make a difference.

A bit of a nasty one

Dave


Ian
 

Thanks, Dave, I agree with your summation. With elevations being the basis of this project I really really do need to be able to establish and verify Elevations.


On Tue, 16 Feb 2021 at 09:58, Dave Bullis <sillub@...> wrote:
The problem is that the cursor appears to jump to the track when it's close showing a blue dot on the track
But the 'real' cursor is not actually jumping.  You'll notice that the cross-hair cursor appears briefly when you click
Also the X and Y Red markers on the side rulers don't match where the blue dot is.
The real cursor is what we are using to determine if we on an end-point to update the elevation dialog.

Try holding down the Ctrl key while you're looking for endpts.  You shouldn't have the jumping cursor.
In fact you won't see the blue dot or the current elevation either

Turning the magnetic snap on or off doesn't make a difference.

A bit of a nasty one

Dave



--
-- Ian


Adam Richards
 

The prediction of end point selection is my code - it should not move the “real” cursor (none of the magnetic snaps do that).  But what should happen is that the c-down code at the same cursor pos will result in that predicted point being selected. This allows users to know what (if anything) happens when they click. And that snap behavior should be inhibited by adding alt.  I think we may have an issue that a snap type behavior happens anyway. 

There is another possible conflict, though in the code which shows the elevation under the cursor. I’ll look at it today.

Adam


 


Adam Richards
 

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
 

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
 

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


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
 

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 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
 

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
 

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
 

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


Adam Richards
 

OK - change made and manual updated.


Robert Scott
 

Gentlemen,


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.

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
 

Good morning.

I download the file.
It works fine.

Maybe I'll take up Knitting.

Bob


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