I am a total beginner with the software, and have been practicing drafting basic bodice blocks. I saved a front bodice pattern, and when I tried to re-open it, it won’t let me due to a critical error:
I haven’t gotten very far, the file only contains some guidelines so far. Yesterday I finished the front bodice pattern, and encountered the same critical error when I went to open it today. So I re-started it, and when I tried to open it later on in the afternoon, the same error window popped up.
How do I fix this issue? And avoid running into it again in the future when I am working on more complex and time-consuming patterns?
Hmmm… taking a quick look at the xml file - looks like the “draw” elements are in an incorrect order. There are certain elements of a pattern that are expected to come before the < draw > tag… thus the error saying “draw” not defined in this scope.
I have ask, but by chance did you manually edit the file? If not I will have to try and figure out why the file got written incorrectly.
I’ll take a closer look later when I can try and open the pattern on my machine.
I am a complete novice to Seamly, so I am following some simple tutorials and the manual to draft a basic bodice front to practice.
I am not sure how I could have “drawn” out of order, since I just put down some simple guidelines. I would love to find out where I have gone wrong to avoid to the same mistake.
Just out of curiosity, what OS are you using, and can you check which build ver (date) the app is - check the Help → About. Also if you could just try adding a new pattern, with no measurements, add a couple points, save, close and try to open. In other words, I’m trying to see if this pattern was an anomaly, or if there’s indeed a bug.
BTW… for future reference, when you share / post a pattern file, we also need the measurement (vit) file, or we can’t directly open the pattern. I did create an empty measurement file by importing from the pattern, but had to make an educated guess what the measurements could be.
The build version of seamly I am using is the latest, 05/23/2022. The OS I am using is Windows 11. I just tried adding a new pattern, with no measurements, added some points and lines, saved it, and opened it again and it showed no similar issue.
I wonder if it has something to do with my measurement file? I did encounter the same error twice yesterday drafting the same bodice pattern with the same measurement file. So I did repeat the same error. However, I used the same measurement file to draft another set of front and back bodice patterns earlier this week and I did not encounter error when re-opening the files.
I am going to begin anew the same bodice pattern today and see if I can repeat the error, and send all the information to you to see if we can get to the bottom of it.
I was thinking the same thing. It could be done, just not a priority for me at this time.
That being said, I’m at a loss why the order in writing a pattern file would get mixed up. I’ve built and run every ver since Val, saved and opened files 100’s - if not a 1000+ times and have not had this error.
Hmmm… that’s going back to the Val days. At least in that thread a cause was thought to be updating the pattern to a newer version of the app… I don’t think this was the case with Nina? Although converting a pattern could be an explanation as something would have to causing a file to get out of order… more specifically a draw block is getting inserted as the 1st node in the dom doc and saved as the xml. If it is a bug, it’s one of those sporadic, hard to track things. And of course it’s always hard for anyone to always remember what steps they did to cause an error.
Yes, it was the only one that I could find quickly. I know that I fixed a number of files with this same problem, for a few different people - I just can’t remember exactly how long ago or what the title was for the topics or whether they were private messages or not.
Yes, one creates a pattern and reaches a point of design completion before closing. One doesn’t expect your pattern file to corrupt itself between the closing and the reopening.
I’m just wondering… Was the pattern saved immediately after creating the new file? or was it saved for the 1st time just before closing the pattern? If it was saved for the 1st time just before closing the pattern, it could be that the auto-save is causing the order problem… Dunno, but something to think about.
I encountered the error twice. The first time I saved the file before closing the program (I had finished the front bodice at that point). When I went to reopen it several hours later, the error window popped up.
The second time I started the bodice anew, and saved the file after a few guidelines were drawn. I closed the program. Then the same error showed up when I went to open the file. That’s when I decided to reach out in the forum.
I finished the front and back bodice yesterday, saving, closing, and opening many many times throughout the day following the exact same drafting order and measurement file. No problems at all. Very mysterious!!
Yeah… I tried a few different things to see if I could cause the error… no luck. I don’t think it’s the autosave. What to keep in mind is that the pattern file is actually a Qt Dom document - basically a copy of the file in memory. When you save, or when the autosave saves the document to a file, it’s just writing what’s in memory. So something, or some order of steps is causing the draw element to saved to the dom doc as the 1st node.
Something I pondered last night… I wondering if this is some sort of timing issue. Without getting in the weeds too deep - Qt apps are event driven, and rely on a signal-slot (function) system - where you can tie one event to another by emitting a dignal and the slots that are connected to that signal are acted on. For example when you click on a point it sends a signal out This point was clicked… for ex: the Property Manager is connected to this signal and when it recieves the signal it displays the point’s properties in the dock.
The thing is, events are queued, as well as in most cases daisy chained. It’s possible that something - a mouse move, a disk access, etc - could cause a signal to be delayed, being acted on after some other signal, when it should have been acted on before. Such as writing a draw element before the information elements. OR maybe a signal wasn’t connected or not passed on ( daisy chained)? In any case, I think there is an issue, I just don’t know if it’s a bug, or if it’s just due to some random circumstances that can’t be accounted for at any given time… such as a slow machine, low memory, multi thread issues, etc.
Just for interest sake, did you save the pattern immediately after create the New pattern?
I get you, thank you for explaining I haven’t upgraded my Windows 10 to Windows 11 yet, so it could also be something new in Windows 11 that is causing it. I think that most of the previous problems were with one of the Mac versions.
If it’s happening on multiple OS’s I’d be inclined to think it related to something else. I took a quick look at the code, and it’s possible it could be some timing or thread issue, as the app will set the data for each of the elements such as author, pattern name, units, variables, etc… then emit a pattern changed signal for each… so it’s possible the order that the elements are getting written is getting mixed up. I just have a feeling it’s going to be one of those things that only happens when events outside the app line up. ???
I took a quick look at part of the code… and the parsing section, handles the tags in a switch, so it should be able handle elements is any order… thing is some of those initial elements are skipped over in the switch and handled else where. I can kinda of see the reasoning as for ex: you don’t need to keep parsing the pattern name each time a parse of the tools is required.
I believe I did save the pattern immediately after create the New pattern. My laptop I think was also doing auto update from Window 10 to Window 11 that day in the background, which might explain the error. I haven’t encountered the error again since.
Aha. Could be like I suggested… some event outside Seamly2D that could have delayed the timing sequence of writing the various elements to the dom document, which is then saved to disk when you save.
When I have sone time I’ll look deeper into the issue… maybe it might need some well placed QTimer lines of code to delay the app until after each element section is written in the correct order.
In any event (pun intended ), glad it’s working for you.
Ah! Yes, please let me know how you get on with Windows 11 I’ve been hanging back because I have my PC networked with the laptop and the PC isn’t Windows 11 compatible - along with a number of programs that I’ve been bringing forward from XP that I already battle with.
I’ve been hanging back because I have my PC networked with the laptop and the PC isn’t Windows 11 compatible - along with a number of programs that I’ve been bringing forward from XP that I already battle with.