Repaint logic of DefaultSingleCDoskable

Byte-Welt - Projekte / Projects DockingFrames
1

Hi all,

I would like to have more info on who is going to call the “repaint” method of each CDockable (to repaint its contentpane) and when.
In particular, I have a dock, in the center, where I draw vector images (like autocad) and then on the sides I have moveable docks. When I move one of this dock around, I have a strange behavior of the center drawing the lines are not redrawn everytime I move the mouse to relocate the dock and they are drawn in the coordinate system of the center dock as it was not resizing).

In particular, I have a JPanel (A) added to the center dock. (A) has a borderlayout and other two jpanels (B, C) are added at borderlayout.center (B) and borderlayout.south ©.

If I override the paintComponent method of (A) in order to force repaint also on (B) and ©, it works but I have a defect: when dragging the side dock around, it draws A first as if it was not resized and then as it was resized (the acutal call to the overridden paintComponent method works).

Thank you.

2

Let me reformulate the problem.
In my center dock I have a Jpanel where I draw vectors. I’ve implemented zoom in/out and pan functionalities through affinetransform.
And the fact that I do affinetransformations in the panel is the reason of the problem in the relocation of the sides dock.
In particular, when a side dock is dragged around, the framework looks for a possible drop area and an animation occurs, resizing the other docks. In particular, the center dock (the drawing area) get resized and during the animation the vectors in the center panel are drawn correctly (according to the last affinetransform performed). However if I continue to move the dock targeting at THE SAME drop location (no new animation occurs) the vectors seems to be drawn in a coordinate system with the 0,0 in the OLD (not resized) top left corner of the jpanel.

Thank you for your help.

3

[ot]Beni was not yet here today, but I’m sure he will respond soon. At least, we’ll soon have another DockingFrames expert who can then answer other questions here :slight_smile: [/ot]

4

DockingFrames tries not to do any evil stuff with painting (it is just using the standard AWT/Swing mechanisms for painting).

If I understand you correctly the AffineTransformation is somehow reset or lost. I have to write a little application to check if I can reproduce the issue, you’ll get an answer either on saturday or on sunday.

5

Although I don’t have the slightest idea about DockingFrames (unfortunately), I’d like to jump in with two wild guesses:

  • Are you missing a super.paintComponent(g); call in some overridden paintComponent method?
  • Are you, by any chance, calling graphics.setTransform(someAffineTransform); anywhere? (Note the constraints for this method in the JavaDoc!)

If not… it’s up to Beni to figure this out (though from my experience with other projects and Forums and Q/A sites in general), examples where the issue can be reproduced are tremendously helpful

6

I played around a bit with painting different shapes and transformations, but really could not reproduce anything like the bug you describe. For this one you need to post some code (a very small application is preferred). Usually these kind of bugs mean something very small has a defect, and the bug can only be seen under very special circumstances.

7

Thank you very much. I was using the setTransform method improperly. There’s nothing wrong with the framework.
Thank you again.