Description: Deleting a Piece item doesn’t delete the Piece item from the pattern file.
This behavior may be related to sporadic reports of patterns that can no longer be opened after complex changes have been made in Piece mode.
Desired behavior:
Delete the entire piece information, including any internal paths.
Here is a file after creating a piece, adding an internal path, deleting the piece, then creating a different piece with the same internal path then deleting the piece, then saving and exiting the pattern. It retains each copy of the piece that was deleted.
So, when I have this problem, I just delete all the lines in the <modeling> section in which inUse="false", right? Until it’s automated properly, of course.
But don’t remove the <modeling> tags themselves. That’ll definitely kick up an error.
Looking at the attached pattern file, and the description of the order of operations it’s easy to conclude… if you delete a “draft block” - which is defined between the draw tags… the whole draw section needs to be removed from the Dom doc. I would guess it’s not. What would be more telling is what does a pattern file look like after creating a single draft block, deleting it, and saving? There should be no < draw> < /draw> element section at all.
That being said… this brings up the issue IMO… < draw> < /draw> should be < draft> < /draft> and < details> < /details> should be < piece> < /piece>.
Just out of curiosity… how did you delete the piece? Currently there is no “delete” function… yet. I have added it in my ver:
It should be noted you can’t delete all the pieces… this may be were the issue is? If I recall - you have to leave at least one < draw> block in the pattern. We should have the capability to clear it though leaving just it’s name and base point.
That being saidl it’s clearly an issue. It would seem logical that if you delete a draft block (piece), then it should remove the < draw> block completely… as well as the tools’ container data.
Also as an aside… because it drives me crazy. We keep referring to the initial draft as a " [pattern] piece" and the actual pattern pieces as “details”. It doesn’t make any sense.
Currently if you look at the xml you have
< draw>
…
< details>
< groups>
< /draw>
IMO - It makes more sense to have:
< draft> or < draft block>
< calculation/>
< modeling/>
< pieces>
< piece>
< /piece>
< piece>
< details>
< patternInfo>
< grainline>
< /details>
< /piece>
< /pieces>
< groups/>
< /draft> or < /draft block>
Because you can have multiple “pattern pieces” in a “draft block”. And “details” are items (like labels, grainlines, symbols, etc) added to a “pattern piece”. A detail is NOT a piece. You also have to look at the source code which gets even more confusing when the draw’s are referred to as PPieces and the actual pattern pieces - which are contained within the class VPiece & VToolSeamAllowance are referred to as details. ??? It’s maddening to keep track of all the inconsistencies in the naming conventions from the class names to the ui to the tooltips to to the png’s to the dialogs… etc.
Considering that it’s only the subject matter within the <modeling> section of the presented XML which is repeated, I’m pretty sure you are the only one doing so here.
I had forgotten to draw a line, & so ended up with a mask pattern which would not resize. I tried to delete the junk nodes but couldn’t, even after I deleted the tracing/piece which should have been the only dependency. But I recalled that this topic had recently been made, & figured that the deletion had not succeeded, & that there was a phantom tracing remaining. So I opened my VAL in a plaintext editor. After a bit of scrolling, I found my inUse="false" modeling section, & having written the first half of my above post, deleted it. Hence my note not to delete the tags. (I had not been so hardy as to close my XML window, so it was easy to undo.) After a little more thumping it upside the screen it worked, I was able to delete the bad point & arc, & replace it with a functional line & arc, & tracing/piece.
So…
…you just go to the Piece mode, right/ctrl click the tracing you want to edit, & Delete is right there at the bottom of a very short menu, with a fancy trashcan icon beside it.
The New / Rename / Delete UI update is fantastic user design. Thanks.
I deleted the “Piece” item (formerly “Detail”). Agreed, this terminology is confusing. “Draft” is perfect, but “Piece” is appearing to be a bit overloaded, it means several things.
Let’s start a new thread to discuss naming conventions. The XML, UI tools, etc. should all use the same terms.
RIght, XML tags don’t get deleted. When the ( eg Piece/Detail in the UI) section is empty, the default XML tag is
My bad… I thought we were talking about deleting a PPiece… er um draw… er um draft block. Yes… when deleting a detail (VPiece & VToolSeamallowance) the modeling block is not getting cleared.
Unless you delete a stage 1 draft block, in which case the whole … block gets deleted.
Agreed. Since I know a good portion of the code… and a lot of the issues, I’ll put together an outline of what changes I think we should make, and we can go from there.
I think there’s a better way to handle internal paths, and this requires a big discussion about the .val file format. For now, removing all of the xml of the deleted pattern piece is the right thing to do.
Especially with the alterations that @Douglas has spoken of, (selecting the tracing before choosing the internal path, rather than after, as it currently stands,) that’s the only solution that makes sense when the tracing is being deleted.
But what if it’s only the internal path from the tracing that someone wants to get rid of?
As it stands at the moment, unless I’m missing something, it is utterly impossible to delete internal paths without a texteditor. The delete option merely throws them into a limbo of being undetectable except by the inability to delete nodes that support them.
So,
the easiest solution would be to implement the fix you have spoken of, & to remove the delete option from the internal paths dialog.
A better solution would be to fix it so that internal paths are actually deletable,
& the best solution, as you mentioned, is still a mystery.
I favor what I consider to be the better solution in the short term, unless that can’t be done without the best solution being decided, in which case I’ll be content to work with the easy solution for now.
Summary:
If coupled with the removal of the ersatz delete option from the internal paths dialog, this is a satisfactory solution for now.
I just deleted an internal path… Saved the pattern and loaded it back in no problem??
Yes you can use the same points to create multiple internal paths, and no it did not pose a problem creating a second piece using the same draft block above, adding an exact internal dart path, and deleting the Waist Dart ipath from the 1st piece.
I would probably tend to agree, but remember any time the schema is changed we have to be aware of what effect that will have on the ability to convert from a previous version so as to not break the older patterns. If we didn’t care about older ver patterns there would be no problem changing the XML schema.
The “pattern piece” being everything between a < detail>… < /detail> block and modeled objects such as < point> or < paths> that the piece uses. Can I presume the 2nd part is NOT happening and that’s the problem of the topic? In other words - using your included example - should not the modeled points id= 12, 13, 14, & 15 be deleted and not just tagged as "inUse=“false”? In other words - what’s the point of inUse - it’s not like you can make those points inUse=“True” once the piece (detail) is deleted - right?
To delete an internal path, delete the <iPath> element in the <detail> section and the elements in the <modeling> section., as a temporary fix to stop file crashes.
Is it possible to:
Update the “Internal Paths” tool in Draft mode to open a dialog which lists all internal paths for the current Draft piece, creates new internal paths, and edits existing ones. If an internal path is not referenced by a workpiece then it can be deleted.
Change the XML schema so that the original Internal Path <path> elements from the <modeling> section move up into their own section, and a new <mPath> element is added to the <modeling> section which points to the original <path> element. This would allow a single original internal <path> element to be referenced in multiple <modeling> sections. It also means that an internal path <iPath> can be deleted from a workpiece without deleting the original <path> definition.
Update the workpiece Options Internal Path tab to select Internal Paths from a dropdown list of all internal paths applicable for the current workpiece. This tab would not allow editing of the original internal path (that would be done in Draft mode’s “Internal Path” tool), but would allow selecting the linetype.
Possible… but the thing is the iPaths belong to the piece (detail), not the draft. However, The modeled < paths> exist between the draft and the piece. If, we are able to base a dialog on the modeled path, I don’t see why it could then not be used in more than 1 piece, in which case the “inUse” tag would now have a purpose… as it would show inUse=True if it used any pieces, false if not used. In other words more like anchor points (pins) are defined and used. So the idea would be to be able to delete the instance of a path in piece mode, and delete the definition in draft mode ( provided it is not in use in any pieces).
