Date   

5.22 Crashed: Modified a Structure and Crashed

Ian
 

I was modifying a structure - the Canal Bridge at the very bottom of the layout - and was doing the last step and Grouping it again. It was giving me a different name - the name of the boat in the middle of the structure which wasn't highlighted. So I gave in an entirely new name and clicked OK. Sudden instant crash. Wow!
Layout and Ini files attached. I accidentally started this by clicking on the Layout file so the Log file wasn't updated. Sorry.
--
-- Ian


Re: 5.22 on Win10: Problems with setting Elevations

Adam Richards
 

OK - change made and manual updated.


Re: 5.22 on Win10: Problems with setting Elevations

Adam Richards
 

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


Re: Can rolling stock have just one coupler?

Adam Richards
 

Russ, 
No - our model for cars is relatively unsophisticated, I'm afraid. There are assumptions that all Cars - 

1. Have two couplers (either attached to the frame or the bogie)
2. Have two bogies with 2 wheels each (this doesn't matter much as the layout view is always overhead and the body of the car usually masks the wheels. The picture shown in Car definition super-imposes the bogies, but that is definition time sugar. We don't define pony trucks, which makes the coupling movements somewhat un-realistic for engines in particular - where the bogies are defined at the limit of the driving wheels to ensure the engine sweeps the correct envelope. The coupling for a non-body shape is either at the car end (prototype engine but often not model) or in a straight line from the outer driving wheel center  to the next car's bogie center. 
3.  These two bogie inter-center distance are defined (distance between and in V5.2 any offset from the center of the car to the center of the bogies). 
4. Can navigate any radius curves we have defined
5. Actually don't care about the gauge track they sit on - it is left as an exercise for the user to place as desired - this allows use of imprecise "re-gauged" equipment.

The suppression of coupling in one or both directions (in the model we may have a dummy coupler on any Car as well as your snow-plough case) would be a feature request.

Adam


Can rolling stock have just one coupler?

Russ Bonny
 

I would like to add a snowplow to my roster. It has a coupler on only one end. Can that be done in xtrackcad?


Re: 5.22 on Win10: Problems with setting Elevations

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


Re: 5.22 on Win10: Problems with setting Elevations

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


Re: 5.22 on Win10: Problems with setting Elevations

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



Re: 5.22 on Win10: Problems with setting Elevations

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



Re: 5.22 on Win10: Problems with setting Elevations

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


Re: Export DXF to Structure File (xtp) #Parameter #structure

Russell Shilling
 

Happy to do it. I wanted a way to take my CAD drawings and convert them to structures. It grew from there.

Be sure to share what you've done if it might be useful to other modelers. 
--
Russell Shilling
http://shilling-or.com


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. 

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


Re: 5.22 on Win10: Problems with setting Elevations

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


Re: Crash, Segment Fault -- reproduceable

Adam Richards
 

Fix found and pushed. 

The Cornu Split code was not properly processing Bezier segments. 

Adam


Re: 5.22 on Win10: Problems with setting Elevations

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

 

 


Re: Crash in UpdateBezier

Adam Richards
 

Several bugs found and fixed surrounding Bezier Describe (track and line) 

1. Using endpoints for non-track

2. Not altering angles when end points or control points altered

3. Wrong type of angle results for altering track ctl points when end tracks

4. Not clearing old track when updating

5. Not making endpoint 1 R/O when end track at that end

6. Bonus - angles a0 and a1 were not set up properly on creation of track/line


Re: Crash, Segment Fault -- reproduceable

Jack Haverty.
 

Cool, thanks.   I also filed it as a bug report on sourceforge.  /Jack

On 2/15/21 6:20 PM, Adam Richards wrote:
I’ll look - there is the chance that this has been fixed since 5.2.1a 

Adam


Re: 5.22 on Win10: Problems with setting Elevations

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


 


Re: Crash, Segment Fault -- reproduceable

Adam Richards
 

I’ll look - there is the chance that this has been fixed since 5.2.1a 

Adam


Re: Crash in UpdateBezier

Adam Richards
 

I’ll look later but basically the angle is the “end angle” between the control point and the end point in each case.

Adam

301 - 320 of 12641