When is the preferredSize() method of the Container class called?

[Chan Ag]

Hi,

I'm currently trying to understand how/why in multi-threaded applications that use Swing components, we need to access the Swing components only via the event-dispatching threads. I think I've understood that for the most part. It is one event callback method, I'm just having a little trouble with. One of the things that I've been trying to find out is which part of my code is invoking the preferredSize() callback method. I'm guessing this can't be a user action( a mouse click or a key pressed ) leading to a callback like keyPressed or actionPerformed methods. It'd be something similar to a repaint() method invoking paintComponent() method.

My example has a class that extends a JComponent and implements a custom created Listener. I have preferredSize() method in this class.

I think my example details are immaterial cause like repaint() method always calls paintComponent(), there must be some method that always calls preferredSize() too? I can't paste the code here anyway.

Could it be the getSize() method of the JComponent class? The description of getSize() method does not say so though.


public Dimension getSize(Dimension rv)
Stores the width/height of this component into "return value" rv and returns rv. If rv is null a new Dimension object is allocated. This version of getSize is useful if the caller wants to avoid allocating a new Dimension object on the heap.
Overrides:
getSize in class Component
Parameters:
rv - the return value, modified to the component's size
Returns:
rv

I have checked the API of the Container class and JComponent class and I still couldn't find anything helpful. A hint/help would be great. :-)

Is there a way netbeans can tell me which methods in my application are calling preferredSize()?

Thanks,
Chan.

[Darryl Burke]

Chan Ag wrote:I think my example details are immaterial cause like repaint() method always calls paintComponent(), there must be some method that always calls preferredSize() too?

I guess the nearest thing to what you're looking for would be LayoutManager#layoutContainer(...) and other LayoutManager and LayoutManager2 methods.

But just remember that not all LayoutManager implementations respect the preferredSize.

[Chan Ag]

Thanks, Darryl.

I will take a look at the LayoutManagers and update this post with what I find.

Chan.

[Chan Ag]

Hi again,

I think I've figured this one out. I guess it's to do with the layouts. Thanks.

I just chanced upon the following post (Darryl, I'm guessing it's your response in the other thread too. Awesome.)

http://www.java-forums.org/awt-swing/61039-pack-makes-jdialog-too-small.html

Coming back to my ( not mine - the book is Java Threads Ed 3 ) example class -

In another class that extends a JFrame ( and this JFrame has the JComponent in question ), they're invoking the pack() method of the Window class. This method invokes the getPreferredSize() method which in turn is calling the preferredSize() method to resize the custom canvas components in the JFrame.

This part ( the question I put in the current post ) is sorted.

My original requirement was to find out how preferredSize() method is being called by the event dispatching thread. I still don't have that clarity.
But I guess I'm going to skip over that part for now and take that as a given.
Just to keep things somewhat simple for now...

Thank you.
Chan.

[Paul Clapham]

Chan Ag wrote:My original requirement was to find out how preferredSize() method is being called by the event dispatching thread. I still don't have that clarity.

And what difference would it make if you knew the answer to that question?

But I guess I'm going to skip over that part for now and take that as a given.
Just to keep things somewhat simple for now...

Yes, that's what you should do. You should expect that the Swing internal code will call that method at some point in time to find out what the preferred size should be. So just make sure that when it's called it returns the right value. Also, the internal code might call the method one or more times, if it needs to. That shouldn't make any difference to you.

[Chan Ag]

And what difference would it make if you knew the answer to that question?

Not much actually.

Actually at the time of posting this question, I thought it'd be a simple method, perhaps a getSize() or something simpler that I just didn't notice. But I couldn't gather much even after referring to the API. The thing is I've had this question right from when I started testing this code from the first chapter.

More of a curiosity.
Also I thought the responses would help me in understanding how to debug my application better.

This is what happened after I had posted my most recent response to this thread last night. I read later that events come into picture only after the GUI is displayed, i.e after the show() method is invoked. But the pack() method I have is invoked before the show() method. So I couldn't gather how preferredSize() method was still invoked by the event dispatching thread. So somewhere I was still missing on some required bit.

One of the premise I had was there are no events before I have clicked on the start button on the GUI because the actionPerformed code for the start button enabled other components ( and hence other events possible ) on the GUI. This morning I added a few break points to the code and ran my application. I realized yes, you're right. The preferredSize() method is called by some method even after show() method is called. The debugging showed me that there were events ( I created an exception and printed a stackTrace at some points - This must have somewhat changed the algorithm too ) after show() method was invoked even though I had not clicked on the start button of the GUI. It must be one of these events that the dispatcher thread is dispatching by calling something that calls the preferredSize() method again to resize components and these calls must be the ones that the authors are talking about. This sort of at least gives me a guess-work sort of a reason to skip the further details on.

And I can see why I should just avoid trying to delve further into this topic. I can see there are event queues, native method calls, locks, synchronization and what nots ( I can see why you're saying what you're saying ) .... Since the book has yet not skipped mentioning the needed details, it is a good thing to consider that whenever internal details are somewhat skimmed through, there is a good reason behind it.

Thanks,
Chan.

[Darryl Burke]

Chan Ag wrote:One of the premise I had was there are no events before I have clicked on the start button on the GUI because the actionPerformed code for the start button enabled other components ( and hence other events possible ) on the GUI.

There are a whole lot of PropertyChangeEvents fired, one for every method call that changes a bound property of any Component. There are also various listeners added by the core Swing code, some of which are triggered even before the GUI is shown.

But as well said by Paul, a deeper understanding of this part of program flow is not essential for writing a good application. Now if you want to tweak default behavior, well that's another story.

[Paul Clapham]

Chan Ag wrote:And I can see why I should just avoid trying to delve further into this topic. I can see there are event queues, native method calls, locks, synchronization and what nots ( I can see why you're saying what you're saying ) .... Since the book has yet not skipped mentioning the needed details, it is a good thing to consider that whenever internal details are somewhat skimmed through, there is a good reason behind it.

I've been programming Swing for years and I don't know anything about all of that internal stuff. I know there's an event queue -- you have to get involved with that if you're trying to write a multi-threaded Swing application, so that fact is documented and there's a tutorial about it. But that's about all.

It's quite possible that I would be a better Swing programmer if I knew more about how it worked internally. But that's an "icing on the cake" sort of thing, i.e. don't mess with it until you have the basic foundations understood.