Ctrl-Z changes lines cords(associate, dependency, ...)

[GoogleCodeExporter]

What steps will reproduce the problem?
Possible steps(at least on my env)
1.A simple diagram with some lines(associate, dependency, any)
2.Move the diagram
3.Attempt for undo(ctrl-z) will changes the line cords(link the start to end 
point)

What is the expected output? What do you see instead?
Expected: Previous statement(undo)
Instead: Previous Statement plus some unexpected changes on lines

What version of the product are you using? On what operating system?
UMLet 13, Win7_64, JRE1.8.0.25

Please provide any additional information below.

Original issue reported on code.google.com by AraSh...@gmail.com on 3 Nov 2014 at 3:39

Attachments:

• umlet13.jpg

[GoogleCodeExporter]

Could you please upload the uxf file?
There are some weird undo bugs  in the old relation class, but the new one 
(which has been shipped with v13) should work without problems.

Original comment by AFDiaX on 3 Nov 2014 at 5:58

[GoogleCodeExporter]

If you're talking about the old relation, I guess I have found the bug.

If you add an old relation from the palette, then move the whole diagram (not 
only a linepoint of the relation) and undo, the relation has overlapping lines 
instead of a simple line.

It is fixed in r1229 and v13.1

I would still suggest to switch to the new relation class (the ones in the 
current palettes where autocompletion works and the line-end-description is 
placed nicely), as we will probably remove the old one in a future release 
(because it has several maintenance issues)

Original comment by AFDiaX on 3 Nov 2014 at 6:14

• Added labels: UMLet-13.1

[GoogleCodeExporter]

I have to note that the redo doesn't work with this issue, I also attached a 
sample about this (PFA)
This bug convinced me enough to rollback to previous version, but when I unzip 
the v12 again and tried to simulate the issue, it didn't show any sign of bug 
at the first, but a little you work(for some min) it will show up.

Thank you for your hard work and cool app.

Original comment by AraSh...@gmail.com on 3 Nov 2014 at 6:22

Attachments:

• temp.uxf

[GoogleCodeExporter]

^^^^*Sorry, by v12 I did mean V13, so sorry.

Original comment by AraSh...@gmail.com on 3 Nov 2014 at 6:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Thanks for the uxf, that seems to be the bug I fixed in #2 30 minutes ago ;)

Therefore will close this issue as fixed.

Thanks again for the report!

Original comment by AFDiaX on 3 Nov 2014 at 6:58

[GoogleCodeExporter]

I've been using Umlet since v9(I think), and this is the first time forced me 
to back to previous version, hope I could give some hand.

So when the new patch is going be ready for download sir?

Original comment by AraSh...@gmail.com on 3 Nov 2014 at 7:09

[GoogleCodeExporter]

I guess in the next few weeks (or now if you want to check out the source from 
svn and build a version for yourself)

But as I said above, this problem only occurs at the deprecated relation.
If you use any relation from a non-deprecated palette, you won't have the 
problem.

Original comment by AFDiaX on 3 Nov 2014 at 7:56

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

That's ok dear, but I think if there was a some internal diagram converter to 
new relations would be great, because I just found around 15 my diagrams 
altered with this bug into some action painting.
I've been using UMLet since V9 or 8 I think, most of the my diagrams were 
prepared by older versions(old relations), so if it's really essential to 
switch into new relations, please provide some internal/external converter for 
files.

Thank you.

Original comment by AraSh...@gmail.com on 3 Nov 2014 at 8:05

[GoogleCodeExporter]

If the time comes when we remove the old diagrams we will perhaps offer a 
conversion program (although we have only limited time so I cannot make any 
promises)

A simple converter should be quite easy to write as the main difference in the 
uxf file is:
old elements are identified using the qualified class name: 
<type>com.baselet.element.old.element.Class</type>
new elements are identified using a unique id: <id>UMLClass</id>

So a program which maps the old identification to the new one should be 
sufficient, although some elements have a slightly different syntax (e.g. now 
there is a standardized way to center the text content instead of several ways 
depending on the element) so a manual check if the commands are correctly 
interpreted would be necessary

Original comment by AFDiaX on 2 Dec 2014 at 7:34