However, if I try opening “Tunic4” after failing to open “pattern”, it opens without issue, unless I’ve tried opening “pattern” several times in a row.
I haven’t tried fixing the files, since this is just a weekly release, not a stable release, but thought I should mention my experience in case it helps!
Hi, @Pneumarian.
I tested your patterns with the same results on Windows 10.
The Tunic4.val opened on the 2nd try but the pattern.val doesn’t want to open, throwing up the same error every time.
I’ll take a look at why the patterns are failing to open… it’s obviously somewhere in the conversion process.
Let me ask… are either of you running any anti virus? I found that on my window 8 laptop w / Avast sometimes patterns would open, sometimes not. Did not have any problems on my Windows 10 laptop with just Defender. Although that was with the same patterns of mine… there may some parsing case I missed. I’ll take a look.
Hmmm… Question - will Tunic4 open for you at all on it own without trying to open pattern.val? If it only opens AFTER and only after trying to open pattern.val - then I’m really baffled. Unless…
There also seems to be some other issue - which we discussed along with the “Close Pattern” bug… that is something flakey is still going if you close a pattern, and then open or try to another. Sometimes the program just closes. Sometimes the program will open the pattern in the same window, other times in a new window. This would seem to indicate that everything is not getting cleared and reset when a pattern is closed. BTW… can I assume you can close a pattern now without the program crashing?
Yes. the ExceptionBadId: is no longer happening, the segmentation fault, however is still current.
Another pattern has to have been opened first, but no, it is not reliant on pattern.val. I guess I got a little hyper-focused on the problem files.
no, not unless Ubuntu snuck one in somewhere.
Having tricked Seamly2D into opening tunic4, I have saved as, & it is having no apparent trouble with tunic4.2. Hand-editing the xml didn’t work out very well.
Now to go give the 20200914 weekly release a practice-run around the course…
Hmmm… I wonder if it’s a problem with the Linux build… I’ve never got the seg fault, just the program closing. I just tried like a couple dozen times on Windows 10 opening, closing, starting new, closing, opening, closing, new, close, new, open, close, ver 6.0.0 and 6.0.1 schema’s etc and can’t get the app to crash. I think I’m going to setup Linux on a spare desktop I have to be able to test Linux builds.
Yeah… you would have to make the pattern file conform to either 0.6.0 or 0.6.1 - can’t mix the 2…or the program is going to complain one way or the other.
At any rate I’m gonna create an issue and push the fix for the elArc problem… and for the sake of argument create a test pattern with every tool just to make sure I didn’t miss any elements and that they all convert properly.
BTW… in looking at the code again a good side effect will be that I can cut a few bytes off the program size maybe a few cpu cycles off the conversion process.
I believe I got the issue fixed… just want to run it through a test pattern tomorrow eve before pushing the fix.
But… in the process ran into other issues. For one, before I fixed the conversion part, if a pattern went critical - like pattern.val - I could not get any 0.6.0 pattern to open without closing the program and then opening the pattern. Hmmm. Likewise once I made the fix, if I tried to load a pattern and it was looking for the measurement file and I clicked “No”… it would go critical, and again I could not open a 0.6.0 pattern without it going critical. Double Hmmm.
First of all there is no way to gracefully exit the “load measurement file” dialog without it going critical. There should be a “Cancel” button… that actually cancels the open operation. Dialog 101.
Secondly, there also seems to be some (pre existing?) issue with closing a pattern that caused a critical error, causing a subsequent critical error when trying to open a pattern that needs to be converted right after without closing the program. Needs further investigation.
Thirdly… found another stray unused “?” in the Critical error dialog.
I pushed the fix for the missing elArc tool in the pattern conversion and squashed the unused title bar question marks in the error message boxes. Also created a pattern that used every tool and notch choices and it converted ok.
pattern.val (4.4 KB)
no, not unless Ubuntu snuck one in somewhere.
