Closed Aresius423 closed 6 years ago
That is correct. The first commit addresses the issue directly: resetZoom() retains the translation from the previous AffineTransform, so the picture will mostly stay in the same place.
Sometimes the plugin will reload the image prematurely, resulting in an error message. After correcting the code, the non-existent translation of the error message will be carried over, and the actual image is scrolled back to the top again. For me, this is the most apparent when trying to use multi-line notes in sequence diagrams.
I haven't found a way to differentiate between error messages and small diagrams, but I don't think switching between large and small diagrams is a use case to be considered. The second commit will therefore restore the translations only if the respective scrollbar is active for the new image, and only stores the translation from similar images, since usually the error message cannot be scrolled.
The image containing the error message is generated by the plugin (it's the message of the Exception thrown from the plugin.jar), so that info. could be propagated into the ImageControl. That could give more precise control of how to restore the translation. Would that be better?
That would be better indeed, but from what I can gather, all of this happens in the SourceStringReader constructor @Diagram.java:87, and I cannot catch any exceptions. Maybe I'm missing something, but I couldn't find a way to extract that information from the reader object.
I tried importing SyntaxChecker, but even that doesn't recognise the error message: (system instanceof PSystemError) at SyntaxChecker.java:102 should flag the error, but system is recognised as an activity diagram (which can also be seen in the reader object - DiagramDescription desc contains "(7 activities)" for my error diagram).
The imageControl.showErrorMessage method creates an image from an Exception and is used by DiagramImageControl.updateDiagramImage for exceptions created during the image creation process.
That function was my starting point as well, but the image creation process doesn't create exceptions for most syntax errors. See the attached screenshots:
This is my coverage after triggering a syntax error message with the following code:
participant a
participant b
a->b=
This results in the usual black box + green/red/white text error message.
This is my coverage after triggering a different error with the following code:
participant a
@startdot
@enddot
The newline between @startdot and @enddot is important, without that you only get a black box error message saying "Empty description".
Here is the test application showing the inserted "testme!" in the error message lines.
Is it possible that since this part of the code was implemented, the plantUML plugin was modified to stop throwing exceptions for that?
You're right syntax errors are reported as an image by plantuml.jar. It's coming back to me now, I think I copied plantuml.jar's technique of providing the error message in an image, since I then didn't need to switch between image and text control.
The heuristic that the error image is small enough to not use the scrollbars is the best we can do, I guess.
If I understand this correctly, your code restores the previous translation in resetZoom(), but uses the last scrolled-to value, if there is one, not the current one. This avoids reusing the translation (or lack thereof) from an error message (image).