I created this issue: # Union Tool Problem #407
I’m not too sure exactly what is causing the Union Tool to create the error, so I really don’t know what to say there. 
1 Like
@Grace, if you can replicate the error, can add the steps to recreate the error in the issue? Because that will help us fix it faster.
1 Like
I really don’t know how to replicate it, it either happens, or it doesn’t. And it doesn’t tell you when it happens, it’s only when you try to open the file that the error is there. This is why I never use the union tool, but rather do my unions on the drafting table and why I think that the union tool is a very fickle tool 
I think that if you go through the code of @CorinaLV’s pattern, it may help to clarify it? Sorry, I’m really stumped with this one.
1 Like
I don’t recall anything recently, but then we’ve sort of been avoiding the Union tool.
I can say though in testing the notches in Unions, as well as using Grace’s Union test with updating the Pattern Piece too / dialog, I have had no crashes with it. I should note that part of the Piece testing involved centering the grainline and labels, and the piece locking feature - which involved testing it with a Union due to the fact you can’t delete a locked piece - which means if you merge 2 pieces and either one is locked, the pueces need to be retained. Again, in my recent tests it never crashed.
That being said, the tool does need some work. For one, we need to be able to flip a piece… or basically match which points are joining which.
UPDATE: Well it’s par for the course - finding other bugs when looking for a different bug. In trying track down an elusive bug in the update of the Pattern Piece dock list, I’ve discovered an error in the increment / decrement of piece items in the piece Undo / Redo commands. This could explain the eratic behavior of not only the Union Tool, but various element items not being cleared in an XML file. I can easily see a user forgetting that they may have used the undo / redo before closing a pattern, and upon reopening the pattern it crashes because the increment state is invalid. Hope fixing this will clear up those random issues. 
3 Likes
@slspencer, I haven’t had any problems reported on this for a while now, but what @Douglas says about an error with the Undo & redo makes a lot of sense about some problems I’ve come across in the past.
And I must say that the Union tool is working much better now.
1 Like
Yup… it makes a lot of sense. For one it just adds to the random nature of the crashes… when testing the Union tool who would of thought to check undoing and redoing before saving? Secondly it has to do with swapping an old and new copy of a piece. If anything has been added or deleted from one, it has to be oppositely mirrored in the other - currently it’s only updating either the old or new, and not both. It can easily result in objects being referred to that are not there, or deleting an object that has dependents, or just leaving referrences “in use” that no longer exist.
2 Likes
Is there an issue that needs to be submitted?
1 Like
Well… I can verify that there is an issue in the piece Undo commands. Why this could be relevant when it comes to the Union tool is that A) The original pieces may be deleted upon creation of the Union B) In the Union creation some nodes may go “missing” (RT’s terminology) between the 2 joined pieces. If the old and new are not incremented and decremented every time you undo / redo, eventually you hit the point where you have not incremented a node when it got added again, so eventually you hit 0 in uses and next undo. CRITICAL error.
This completely explains why I’ve probably never experienced an issue with the Union tool - I don’t ever recall using UNDO with it.
I’m making the changes to fix the piece undo commands and will test to see if I can crash it. If not, I think we have solved several mystery crashes.
2 Likes
Looking forward to having these mysteries solved!
1 Like
Yes, but I’ll do that (probably tomorrow after I test tonight) when I’m more or less assured that the undo incrementing issue is directly tied to some issue we can confirm. In other words I can say - yes - the piece undo commands needs to to be fixed, but WHAT issue(s) would it specifically fix? Hopefully I could say - yes it fixes such and such in the Union tool, or doesn’t leave deleted internal paths still “in use”.
3 Likes
Me too. Ironically I only stumbled on the piecesaveoptions undo while stepping through editing the piece properties with another bug (which I will submit an issue for) that always keeps setting the “In Layout” true in the piece list in the dock every time the properties are changed. Which I finally figured out.
3 Likes
Well… I can confirm that repeatedly undoing after creating a Union piece will cause the app to crash, it’s not related to the savepieceoptions - athough there has to be some undo cases where undoing a pattern piece should result in a crash - undoing a Union goes a lot deeper. There is also a savetooloptions undo command which is where the issue arises. Problem is, unlike the savepieceoptions there’s no increnenting / decrementing of dependencies of an old and new copy of a tool. And off the top of my head it’s going to take implementing a way to track the dependencies across ALL the tools when pushing the undo to the stack, not just the Union tool. There’s like 54 tools. 
2 Likes
@Douglas - Is there a way to catch if the app will crash, and just issue a warning to cancel?
1 Like
I’d have to look at it… it is throwing a critical error msg… thing is once you’ve Undone to the point of throwing the error, the (internal) pattern is already mangled. Even if just a warning is thrown, I don’t see how to recover. Can’t “redo” as that’s the problem in the 1st place… the dependencies are not accounted for in the savertooloptions undo command.
At least now I know where the issue is, just have to figure out how to fix it. It mostly seems to affect the Union tool, as we got 3 pieces sharing objects… undoing can pull the carpet out from under another piece because the dependencies aren’t being accounted for. If there was no Undo there probably wouldn’t be an issue.
2 Likes
Maybe the Union tooltip should include a BUGGY, with an error dialog that pops up when the Union tool is chosen giving more details about how it bombs undoing?
1 Like
Or I just fix it. Again the issue is, all 50+ tools use the savetooloptions, so if we need to pass old and new dependencies to it for the union tool, we need to do it for all the tools. Unless maybe I just create a saveunionoptions undo, and not worry about tge other tools - which don’t seem to have the undo crash issue.
2 Likes
So, walk me through how this would work?
1 Like
Well… I’m still kinda of walking through it myself. I did some union test patterns with undo earlier today, saving at each stage.
What I have determined so far is that the 3rd undo & crash is balking at not finding the 1st point of the 2nd piece which was removed by the 2nd undo. 1st undo resulted in the union obj’s inUse set to false - ok there. Why the parse trying to delete the 1st piece is looking for obj’s from the 2nd (deleted) piece is what I have to figure out. Again. I can only speculate it’s a (de)reference issue.
Also, the union tool doesn’t use the savetooloptions as it’s not a draw tool, but rather a modeling tool… so it looks like it’s already using it’s own undo.
.
1 Like
Could you help to enlighten me… I’m trying to wrap my head around the purpose of the “inUse” attribute. Seems if it’s false you don’t need the (tool) element tag at all… if the element is there, by default it’s true. I could see if the inUse showed the use count - that would make sense. but I don’t get the true / false. Again… it just seems to me once a tool is dereferenced to zero - just remove the entry.
1 Like