Date   

Re: V5.2 Migration - weird messages about a jpg #Bug

Adam Richards
 

Here's how to add a file to a post


Re: V5.2 Migration - weird messages about a jpg #Bug

Adam Richards
 
Edited

Thanks for the file, that helped a lot, Gavin.

There is another issue that I just found and have fixed with Note as well. Select was abending on Notes that were >76 characters long.

I confirmed that the 5.1.2a Note format of your file would read and then be rewritten properly in 5.2 format. 

Adam


Re: V5.2 Migration - weird messages about a jpg #Bug

Gavin Dewar
 

Martin
You should have received by email several .xtc files showing the problem.
Also an .xtc file with just the four Comments I had in the problem file.
  Sorry - not sure how to add filse to the forum yet - need to RTFM !

I see on the XtrxkCAD sourceforge page, under Project Activity, that Martin has fixed the problem.
Presumambly this will be ready to download in due course.

Thanks to you all.
   Gavin


Re: V5.2 Migration - weird messages about a jpg #Bug

Adam Richards
 

Gavin,
As I sent in email just now, the original message forwarded to me by Martin was stripped of attachments and of images - hence why I thought the error involved .jpgs - because I thought that text was part of the two error messages!!

Please attach the .xtc here in the forum, or reply to the email I sent you directly with them. 

Thanks,
Adam

----------

Now we are homing in on Notes and Windows, involving bad loading and saving, we are getting somewhere because there are BOTH platform specific code parts AND the format of the Notes entries has changed a lot between versions.

The old code at parm <12 and >9 was a single line of setup, several lines of content and a terminating END

NOTE parm parm parm ...
Line1
Line2
Line3
END

the new format is just one line

NOTE parm parm parm .... "Lines with escaped linefeeds \n, doublequotes "" and backslashes \\"  

The text string(s) (for Windows is also UTF8 encoded rather than system codepage).

The new code should read in the old parmlevels of .xtc correctly, however.  I suspect that the issue is somewhere in all this.

By reading in a V5.1.2a NOTE badly it is likely mangling some definition following it (hence your missing stuff) and then writing the badly read note out in the new V5.2 format causes some exception (there is an assert if the type of the Note object is not >0 and <2, for example).  There even seems to be an issue with writing a simple note at V5.2 level on Windows based on other's observations as well. 

The input .xtc will show us a lot, I expect. 

Adam


Re: V5.2 Migration - weird messages about a jpg #Bug

Gavin Dewar
 

Hi Adam
Of the three files I sent you in earler email:

The following two are from V5.1.2a  and contain the "Draw-Notes-Comments" in Layers 1 & 4,
they both load into V5.2.0 OK but are corrupted on saveing.

"Rowandale - 200"
is my full version with all Layers

"Rowandale - 200 -Layout Only -L1 L4"  - is cut down to just the two layers containing the four "Draw-Notes-Comments"

The following is modified to operate correctly in v5.2.0
  "Rowandale - 200 -Layout Only -L1 L4  - No Comments" is the one which V5.2.0   loads , saves  and re-loads OK
the only difference is that the comments have been removed.

I replied on the thread earlier - but maybe only Dave saw it?

So repeating direct to you
I initially found the problem appeared to be a fault in a "custom turnout" I had setup

a number of years ago - a return loop with a couple of points included.
When I edited the parameters file to remove it - the original problem disappeared
 
But then I found I still had problems when saving in Version 5-2-0 GA
 and then getting errors when reloading the file, with only part of the layout being displayed.
 
After a lot of to & froing between 5-2-0 & 5-1-2a

        - Removing various layers & individual items:

a) Load original in 5-1 - remove layers/items & save with new name.
b) Load into 5-2 - looks fine - Save from  5-2
         Realised after a bit 5-2 crashed out immediately after saving ( or was it part through ?)
c) Load again into 5-2 - gives loads of error messages & eventually
                only loads part of the layout.

I seem to have narrowed the problem to embedded "Draw - Note - Comment" containers.

  When I remove the four of these I had in two layers, then the new version now works
     for me with no problem.

 

Alsotried  a new blank file, then  Draw > Notes > Comment, Placed the default Note on drawing.
Then File > Save   and immediate crash out exit from file. !!
Restart 5-2  - Yes to Offer to recover  - blank file.  Also tried a few tracks - no problem.
Then again Draw > Notes > Commen, Placed the default Note on drawing. Immediate crash on Saveing.

So does seem to be a problem with the "Comments"

I am using Windows10 - with all updates.

Gavin




Re: Odd messages and crash on V5.2.0

Adam Richards
 

As I recall, the window settings are not saved until an actual save or program close. 


Re: Odd messages and crash on V5.2.0

Rob Pearce
 

On 02/12/2020 15:52, Adam Richards wrote:
On Linux, the situation is different. The user has to take action to cope with screen changes, as I read Ubuntu they have to scan to find new screens and tell the OS what to do with them. In general, it seems from my reading that Linux (especially at GTK2 level) is pretty hard to manage dynamic screens with, especially in combinations with different DPI and real-estate.  A fair amount of OS config twiddling seems to be needed just to get the desktop extended.
I am running Linux. The screen setup can be controlled as required, but the OS doesn't try to second-guess you and most window managers don't provide a GUI for it. But that's fine - I have a desktop with two screens and I never move them so why would I need a GUI to change something that never changes? If I regularly plugged my laptop into a second screen then I'd have more to say on the dynamic screen situation but I don't recall it being a big problem.

My experience with V5.2.0 so far is that it usually opens with the main window full width of the left hand screen (but not consistently full height) and the map window on top of it. This is not how I had it when last run because I always move the map window to the right hand screen. But it's better than V5.1.2 used to do.


Re: V5.2 Migration - weird messages about a jpg #Bug

Adam Richards
 

Also, can we get precision on which platforms people are using, please?   There are sometimes (as it seems in this case) differences - and we then can try running in the right place.

The only change I can find post V5.2 for Note is that I upped the largest note size that could be edited.  But that failure was soft (after editing in Modify the note was truncated before the fix). So this is something else. 

Adam

 

 


Re: V5.2 Migration - weird messages about a jpg #Bug

Adam Richards
 
Edited

There does seem to be something "odd" about Notes in general (and not just Comments).  I am not seeing them added properly on Mac (the icon is not showing). They are being written out properly for me on save, though. So that's one thing to be addressed.

^^ Ignore me -> You have to be below scale 1:16 to see the note icons. :-(

Can we see your .xtc file (v5.1.2a) please?

Adam


Re: Table edge lines always curved in 5.2GA #Bug

Adam Richards
 

So it looks like the Windows build at least did not get the memo about the level to use...

Well, we will need a 5.2.1 shortly anyway which hopefully would clean this up. 

Adam


Re: Odd messages and crash on V5.2.0

Adam Richards
 

Rob,
Yes - it will be recorded, but more importantly it will be used at startup (subject to restrictions below).. 

Dual screen support (I can speak for GTK on Mac here, because that is what I am most familiar with) is really single-screen because the OS presents a single virtual screen that covers both screens.  The application is not presented with information that allows it to work out what to do - the original idea is that the OS should handle all this - which works OK for native apps, but with an X11 app, the OS sees it as a window of the X11/XQuartz app which is managing the app within an app. This makes it tricky because when one screen goes away, or the user redistributes them, the positions (and sizes) are all "off" and the only evidence is that the screen size mysteriously changed.  If there is a lack of a prior second screen, the x,y may be off-screen in fact, or so close to an edge that it might as well be. What the code attempts to do is to ensure that the app is actually visible within what it is told when it asks for the screen size. 

On Linux, the situation is different. The user has to take action to cope with screen changes, as I read Ubuntu they have to scan to find new screens and tell the OS what to do with them. In general, it seems from my reading that Linux (especially at GTK2 level) is pretty hard to manage dynamic screens with, especially in combinations with different DPI and real-estate.  A fair amount of OS config twiddling seems to be needed just to get the desktop extended. 

On Windows, I don't know. 

All this to say that it may be that if you are trying to manage between two different screen setups and don't wish to spend time redistributing when changing between them, it is possible to fix the positions per setup by altering the config file using a script for instance before starting up.

-----

In GTK3 we have the ability to try to build with native OS backend support, in which we may be able to simply delegate this all to the OS.  About a year ago I had that working for Mac, but there still seemed to be some things that didn't work as well as I would have liked in the UI in general (although window position and sizing seemed OK) so I mainly concentrated on getting the GTK3 UI complete in X11 mode. Then V5.2 intervened.  

Adam


On Wed, Dec 2, 2020 at 6:02 AM Rob Pearce <rob@...> wrote:
On 02/12/2020 02:19, Adam Richards wrote:
> The values of window size and position in the config file should work
> now at startup, so you can try to fix them at something you want.

Do you mean it should remember the last position and size, or do I have
to manually edit them? Does that include coping with dual screen?

Cheers,

Rob








--
Adam Richards


Re: "Check Pointing" Message box

Neil
 

Adam,  thanks for the excellent explanation.  I now understand but as you say don’t know why it happened if it is commented out as per Dave’s response.

Regards Neil

On 2 Dec 2020, at 02:15, Adam Richards <adamjmrichards@...> wrote:



The message's purpose was to explain any slight pause due to the file being written out as a checkpoint.  It would be a "blip" for small layouts, I expect. I can't comment on whether it should show up now, but it was always informational and not an error. 

The reason you may be seeing it is that we have changed the way the checkpoint/autosave code works to retain more information (and your layout) should we suffer a crash or even if you did something "bad". Previously the checkpoint frequency was a balance between being very current and losing the history at restart. And once you accepted the last checkpoint on start, the file was in immediate danger of being overwritten even if you realized it was not what you wanted. If you set a long checkpoint, you would usually go "back in time" after a crash and lose your work.  But if you set it short, all history was lost very quickly. And there was no auto-save, so you had to definitively remember to save, especially if you chose not to use the checkpoint.

Now we have checkpoints that create a rotating set of saved files (every x updates) and auto-save that periodically (every y checkpoints) auto-saves the file. There are two frequencies, one is how many edits you make between a checkpoint, and the other is how many checkpoints before an auto-save.  A zero in auto-save disables that feature but does not stop the checkpoints. On restart, you have the option of using the last checkpoint and continuing to edit, using it but resetting the filename so as not to overwrite the old file, or just using the last save instead.

Because a checkpoint is essentially a .xtc file, we can use the checkpoints to recover several earlier points in time, if we need to. 

All this means is that checkpoints will usually be written more often (unless you disable them).  

Adam

 


Re: V5.2 Migration - weird messages about a jpg #Bug

Gavin Dewar
 

Just tried  a new blank file, then  Draw > Notes > Comment, Placed the default Note on drawing.

Then File > Save   and immediate crash out exit from file. !!

Restart 5-2  - Yes to Offer to recover  - blank file.  Also tried a few tracks - no problem.

Then again Draw > Notes > Commen, Placed the default Note on drawing. Immediate crash on Saveing.

So does seem to be a prblem with the "Comments"

Gavin Dewar


Re: V5.2 Migration - weird messages about a jpg #Bug

Gavin Dewar
 

The   <cnmakaiimooadjca.jpg> and <lnchablgpehkadgd.jpg> were screen snips I sent to Adam when I first contacted him about my problem with Version 5-2-0


Re: V5.2 Migration - weird messages about a jpg #Bug

Gavin Dewar
 

The "weird jpg" was just a screen stip I took of the error message which I had inclluded in my email to Adam.

I initially found the problem appeared to be a fault in a "custom turnout" I had setup
a number of years ago - a return loop with a couple of points included.
When I edited the parameters file to remove it - the original problem disappeared
 
But then I found I still had problems when saving in Version 5-2-0 GA
 and then getting errors when reloading the file, with only part of the layout being displayed.
 
After a lot of to & froing between 5-2-0 & 5-1-2a

        - Removing various layers & individual items:

a) Load original in 5-1 - remove layers/items & save with new name.
b) Load into 5-2 - looks fine - Save from  5-2
         Realised after a bit 5-2 crashed out immediately after saving ( or was it part through ?)
c) Load again into 5-2 - gives loads of error messages & eventually
                only loads part of the layout.

I seem to have narrowed the problem to embedded "Draw - Note - Comment" containers.

  When I remove the four of these I had in two layers, then the new version now works
     for me with no problem.


Re: Odd messages and crash on V5.2.0

Rob Pearce
 

On 02/12/2020 02:19, Adam Richards wrote:
The values of window size and position in the config file should work now at startup, so you can try to fix them at something you want.
Do you mean it should remember the last position and size, or do I have to manually edit them? Does that include coping with dual screen?

Cheers,

Rob


Re: Table edge lines always curved in 5.2GA #Bug

Dwyane Ward
 

Adam,

I can confirm that the "Draw Table Edge" command is drawing a circle instead of straight line. It is similar to "Create a curve line from a cord" without the option to adjust the curve..

I have downloaded and re-installed 5.2.0GA as of today, on a WIN10 Pro.
--
Dwyane Ward


Re: Odd messages and crash on V5.2.0

Adam Richards
 

Rob,
The values of window size and position in the config file should work now at startup, so you can try to fix them at something you want. 

The new resize uses a pause mechanism that will only redraw the layout if the mouse pauses for a large fraction of a second (which is obviously true at the end of the resize operation).  So actually, the faster you move the mouse to what you want, the less drawing there will be. 

 Adam


Re: "Check Pointing" Message box

Adam Richards
 

The message's purpose was to explain any slight pause due to the file being written out as a checkpoint.  It would be a "blip" for small layouts, I expect. I can't comment on whether it should show up now, but it was always informational and not an error. 

The reason you may be seeing it is that we have changed the way the checkpoint/autosave code works to retain more information (and your layout) should we suffer a crash or even if you did something "bad". Previously the checkpoint frequency was a balance between being very current and losing the history at restart. And once you accepted the last checkpoint on start, the file was in immediate danger of being overwritten even if you realized it was not what you wanted. If you set a long checkpoint, you would usually go "back in time" after a crash and lose your work.  But if you set it short, all history was lost very quickly. And there was no auto-save, so you had to definitively remember to save, especially if you chose not to use the checkpoint.

Now we have checkpoints that create a rotating set of saved files (every x updates) and auto-save that periodically (every y checkpoints) auto-saves the file. There are two frequencies, one is how many edits you make between a checkpoint, and the other is how many checkpoints before an auto-save.  A zero in auto-save disables that feature but does not stop the checkpoints. On restart, you have the option of using the last checkpoint and continuing to edit, using it but resetting the filename so as not to overwrite the old file, or just using the last save instead.

Because a checkpoint is essentially a .xtc file, we can use the checkpoints to recover several earlier points in time, if we need to. 

All this means is that checkpoints will usually be written more often (unless you disable them).  

Adam

 


Re: Table edge lines always curved in 5.2GA #Bug

Adam Richards
 

In the V5.2 GA release, the very last change made was to fix the issue of Add->table-edge producing curved lines (rather than edges). Add->Circles were doing the same thing, incidentally.

Edges in the Xtrkcad object model are very definitely straight and have a more restricted property set than lines as well (see below).  So that's the first part. 

The question is - are you running at current GA, (and on what platform) - or did you happen to download it very early, before I had announced it was available, (the staging ran out briefly about a three days ahead, as I recall) because I remember we had to do a rebuild to include it?  Maybe we have a build that is not exactly right, for example. 

Now onto good news

Earlier than that bug, because people understandably wanted curved edges, but all changes needed to be very small to not destabilize the release, I had quickly made the display width parameter of lines (curved, or straight, or bezier) to be an absolute pixel number if width was set negative.

This means that curved lines could be used with, or instead of, table edges as the only real difference between the two (other than the possibility of lines being curved and coloured, of course) is how the width is treated in display. A table edge retains its pixel width regardless of zoom, where a non-zero width line scales as the zoom changes. A value of -3 and color black seems to my eye to be equivalent to a table edge (although other values and other colors are possible, giving the ability to convey edges at different levels and other such things). 

Adam