This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
reproducible with 061201 steps: 1. create diagram from first screenshot 2. select all lifelines and change font size to 36 3. close diagram with save 4. reload ide 5. open the diagram see screenshot 2
Created attachment 36477 [details] good diagram
Created attachment 36478 [details] corrupted diagram/data loss
This should not be a high use case scenario. Doing zooming would be a more common way usage. Lowering priority to P3.
P1, after discussion with Peter(data loss), but not a stopper for coco (may be not common usecase), I'm not sure if we still need to add coco_waived after cut-off date
I was never able to get the diagram to corrupt like the issue. However, I was able to find what I thought corrupted the diagram. Basically, when you change the font of the lifeline, you change the size of the lifeline top. Therefore, all of the messages need to be adjusted. This seem to be really important when have a create message. Because the create message also moves, which moves the entire lifeline. Just the create lifeline are no longer matching the opposite end of the message. An additional fix is moving create message. The same problem existed. So, I think this problem is fixed, but again I was never able to actually replicate the same problem.
yes, the main cause is relayout after font change and best solution is to fix relayout to expand combined fragments, move lifelines and messages correctly, but a mimimum solution is to relayout right after font change rather then after reload (so user will be able to close diagram without saving, we'll have at least some workaround) Did you try quite complex diagram similar to one on attachments? most layout problems on sequence diagram occurs with "real" diagram which is quite big and complex and aren't reproducible on "test" diagrams with 2-3 lifelines and 2-3 messages. I'll try to replicate a bit later, but it will take a significant amount of time to create something "real".
still corrupted after font change, but diagram is changed right after font change so now there is a workaround to close the diagram without saving, may be the issue should be rephrased to something like "relayout has problems... "
please attach your model, so I can use your model in my testing.
able to reproduce messages mixing but even if "mixing" will be fixed we still will have data loss if proper handling of combined fragment borders won't be implemeted.
Created attachment 38492 [details] open sequecnce diagram, select all, change font size to 36
corruption seems dependent on current zoom level, diagram became corrupted even with change to 18px font size.
What was the zoom level that you used.
for size 36: something about 50% for size 18: with zoom 100% corruption is enormous, with zoom about 50% corruption isn't big but exists
sorry, in previous comment 100 should be replaced with 51 and 50 with 26
low use case not currently impacting our installed user base.
Planned for drawing area upgrade after NB 6.0.
Should not use resolved/later status.
Targeted in the drawing area redesign.
REstoring the original priority and using the NB 6.0 waiver process.
Diagram area bugs waived for 6.0 will also be waived for 6.1.
Verification currently blocked by font issue filed in bug #135640 for 6.5
Removing obsolete assignments. Bugs will be reassigned for M2.
some parts are fixed already with redesign, need to test more and fix remaining issues with font changes
http://hg.netbeans.org/uml-main/rev/397757e5498c should work now, after font change messages and lifelines are updated without reloading.
verified in build 20080728