Re: 5.22 on Win10: Problems with setting Elevations


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

Join to automatically receive all group messages.