Event dispatching in lightweight component
Hi all
I'm trying to figure out how the event dispatch works for the Swing's lightweight component, and there's something I can't find in the tutorials I found.
Lightweight components doesn't have a peer, so they don't receive directly paint events, but it's their containers that call it inside their paint() method (and that's why one should always write super.paint() if wants to override the container's paint() ).
But what about the other events? I suppose they are received by the container (just as paint events) but I can't understand how that container dispatches them to the right lightweight container...
Thank you
[666 byte] By [
lexisa] at [2007-10-3 10:20:36]
I don't understand the question, but you should not override the paint() method, you should override the paintComponent() method is you need to do custom painting.
My question is about "how it is underneath", I want to know how the event dispatching is organized between a heavyweight container and the lightweight components it contains.
For instance:
suppose I have a JButton and I click on it. Since the JButton is a lightweight component, the event ButtonClick is dispatched to the first heavyweight JButton's container (let's call it c ).
The button does what is supposed to do even if it didn't receive the event directly, that means that somewhere in the code of c there's a call to the right method of the instance of JButton.
My questions are:
1) where is that code?
2) how can the container know that it has to call that particular method of that particular lightweight component when it receive a method?
Hope I explain myself more clearly than before
This is what I know about the painting in light weight component in Java.
Lets us concentrate on the button only.
Whenever we press the button we change it s state from 'normal' to 'pressed'. ( Some boolean might be used in the actual code ).
Like wise whenever we do some user inputs to the button ( or any other lightweight component ) it results in the change in the state of the button.
These basic actions are handled by BasicButtonListener.
Now whenever the state of a component is changed it triggers a ChangeEvent associated with that perticular state change.
The implementation of the button is such that it calls the repaint method itself whenever any state of the button changes.
So it is the component itselt who calls its paint method and not its outermost container as you think.
The container of any component can result in repainting of its child component only when it revalidates itself.
I think lexis want to know the underlying code to understand the exact process of painting in Swing.
Its like knowing the internal working of a car is not neccessory to drive it but if we know that it would be nice. You would then be able to iddentify the exact pros and cons of the previous Car and next time we would be able to produce is his own car that fits to our requirement perfectly.
