Re: 5.22 on Win10: Problems with setting Elevations

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. 




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:

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. 




-- Ian

Adam Richards

Join to automatically receive all group messages.