Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!
You are not logged in or you do not have permission to access this page. This could be due to one of several reasons:
You are not logged in. If you are already registered, fill in the form below to log in, or follow the "Sign Up" link to register a new account.
You may not have sufficient privileges to access this page. Are you trying to edit someone else's post, access administrative features or some other privileged system?
If you are trying to post, the administrator may have disabled your account, or it may be awaiting activation.
is the method you override if you want to change how a component displays.
There is a Renderer interface which allows you to change what you do with the components (i.e. you could have a PrintRenderer that dumps straight to a printer) though it's very low level and personally I've never seen it implemented.
Ah right. I implemented TreeCellRenderer back around 1999, which is why my memory of the whole setup is a bit hazy
Correct me if I'm wrong, but don't Swing components delegate their painting to a Renderer object, rather than a paint method? This decoupling is what allows for pluggable UI rendering... although it's been a while since I did any Java UI stuff, so maybe I'm remembering it incorrectly
Excellent point about the UI thread
public void paintComponent(Graphics g) {}
is the method you override if you want to change how a component displays.
There is a Renderer interface which allows you to change what you do with the components (i.e. you could have a PrintRenderer that dumps straight to a printer) though it's very low level and personally I've never seen it implemented.
As for how they fit together, basically all components extend the base component and implement a couple of methods to paint themselves and fire events. This all happens on one thread (the event despatch thread), so you should never, ever run any code of your own on the current thread or you'll lock the GUI - always run your own code inside it's own thread(s). This is the most basic mistake that most beginners make and also why there are so many crap Swing GUIs out there leading people to believe that Swing is slow.
Correct me if I'm wrong, but don't Swing components delegate their painting to a Renderer object, rather than a paint method? This decoupling is what allows for pluggable UI rendering... although it's been a while since I did any Java UI stuff, so maybe I'm remembering it incorrectly
As for how they fit together, basically all components extend the base component and implement a couple of methods to paint themselves and fire events. This all happens on one thread (the event despatch thread), so you should never, ever run any code of your own on the current thread or you'll lock the GUI - always run your own code inside it's own thread(s). This is the most basic mistake that most beginners make and also why there are so many crap Swing GUIs out there leading people to believe that Swing is slow.
I've downloaded the Sun docs, great description of components in isolation. My background is comms, kernels and drivers (no GUI). I'm looking for a good coherent overview of how these GUI components fit together.
Leave a comment: