• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

repaint() will not always repaint()

 
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a graphics intensive app in a View which is a container for a Frame (I think).

I call another frame and through coded gyration the second frame acts as a modal (-- won't give up focus until the user exits from it)

Back at the main Frame I need to repaint() because of modifications made fom the smaller Frame. So I call repaint() when I reactivate the main Frame :
All this is in the constructor of the MyProjectView class (which extends FrameView)

It doesn't work !!!
Only this works :

What is happening?? Is it a timing issue? Am I violating some rule of using repaint()?
At the beginning the proper use of repaint() was a real hassle. It's a bit frustrating to have this limitation on repaint():

 
Sheriff
Posts: 22783
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What happens if you add the repainting to the windowClosed event? The windowClosing event is triggered when someone clicks on the X at the top right (or left for Mac OS). The windowClosed event is triggered when the window is actually closed.
 
Dave Elwood
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Within the smaller Frame, first in WindowClosing() and then in WindowClosed(), I sent a repaint() to the main panel.

Didn't work.

It appears that it will only repaint if I place it in the windowActivated() code of the main Frame.

I just wonder why.
 
Sheriff
Posts: 3837
66
Netbeans IDE Oracle Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'd suggest a different approach: create a "model" that will keep all data needed for the painting of the main window, and provide this model with addListener() methods to allow listening to the changes in the data it manages. Then repaint the main window whenever data changes using listeners added to the model. Use the modal form to just modify data in the model, and have the model call the listeners when data changes. This setup allows providing different listeners and different granularity of the events. By the way, this is how most standard Swing components work, and you can get lots of inspiration by inspecting JDK code (JTable is a fine example).
Hooking up the repaints into the inner mechanism of frames does not sound right to me. Especially focus handling is a delicate mechanism which can be partially platform dependent, and it is easy to mess things up.
 
Dave Elwood
Ranch Hand
Posts: 84
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It seems like an interesting approach Martin, except I have no idea what you are talking about.

Please define

Model

. Heidi Klum it isn't, so let's start there. Do you mean to put all the "data needed for the painting of the main window" into a seperate class?
However I cannot rip the paintComponent() out of my JPanel and stuff it into another class. That would compromise functionality,
And are you truly speaking of a "Modal" or just misspelling "Model"?

provide this model with addListener() methods to allow listening to the changes in the data it manages


If you mean a new class, can I really use an addListener() on it? Or do I need an extension of JPanel when making this new class. I don't think I could concoct an addListener() method out of thin air.
You should know that I've got a MyProjectView extending FrameView with a MyPanel extending javax.swing.JPanel in it.
This has my head spinning.
 
Martin Vashko
Sheriff
Posts: 3837
66
Netbeans IDE Oracle Firefox Browser
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Dave Elwood wrote:It seems like an interesting approach Martin, except I have no idea what you are talking about.


If this is case, I'd say you should get more familiar with Swing framework. This tutorial is perhaps somewhat large, but it served me extremely well. You seem to be designing a component of your own and taking some inspiration of how components are designed in Swing itself would be very useful (or so I believe), but you need some prior knowledge before diving into Swing's sources in the JDK.

However I cannot rip the paintComponent() out of my JPanel and stuff it into another class. That would compromise functionality


Yes, you can , but more on this later.

Separation of concern is a good design practice. Your paintComponent() method surely needs some data to know what has to be painted, and managing these data inside your child of the JPanel class is not a good idea. Model is the class that would manage the data for you, and it would provide methods which would allow your component to obtain the data it manages and use them for painting. A TableModel, which is actually an interface, is a good example of this.

There are some design patterns describing similar concepts. A look at the Model-view-controller design pattern might give you another useful ideas.

As a side note, the paintComponent method can delegate the painting onto another class and most Swing components do exactly this; this allows the components to be painted according to the look and feel of the system or application. I don't know whether this is necessary for you; I just wanted to demonstrate that delegating the painting out of the component itself, when done right, does not compromise functionality at all.

And are you truly speaking of a "Modal" or just misspelling "Model"?


I used the words "modal form" to refer to the "smaller frame" you've described. You've mentioned it behaves like a modal form. You want this form to change the way the master form paints itself, and I suggest to do this by manipulating the data in the model.

I don't think I could concoct an addListener() method out of thin air.


More or less, this is what I hinted you to do. You'd implement your own addListener() methods in your model, when you created one. Maybe we could return to this subject later, when you get more familiar with Swing.

Edit: I've "refactored" this post somehow to better untangle the "modal"/"model" confusion.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic