This content has been marked as final. Show 13 replies
Are you mixing Swing and AWT components? Change your Canvas subclass to a JPabel subclass,
and usually this implies overriding paintComponent instead of paint.
I've solved it!
For those struggling with simmilar stuff, this is what needs specifying:
For everyone else -- stick to Swing!
The solution should be to modify the Canvas subclass to change "extends Canvas" to "extends JPanel" and change the "paint" method to "paintComponent"
The solution should be to modify the Canvas subclass to change "extends Canvas" to "extends JPanel" and change the "paint" method to "paintComponent"Indeed, that's what I wrote above. Is it just me, or does there seem to be a lot more stubborn posters laterly?
yeah, (didn't notice your first response)... seems a lot of people using Canvas lately for some reason. Makes me wonder what the teacher's doing.
Why solve in two steps when can be done in one?
What are the benefits of doing it the way u suggested?
You mean your 1 step of calling "JPopupMenu.setDefaultLightWeightPopupEnabled(false);"?
That method is meant specifically for using popup menus when you are mixing AWT and Swing components. The reason is because of the problem you first posted about. It's a way to get around that problem. But really, it's more of a hack that is used when dealing with old AWT-based components which you can't (or won't), for whatever reason, "update" to Swing versions. (Say from a 3rd-party library).
It is not recommended to mix AWT and Swing components, as already mentioned. The provided link above is an article that explains the issues with this. The fact that you can doesn't mean you should.
If you are writing this Canvas subclass yourself, and it's going to be typically used in a Swing application, you will have problems later, most likely. For example, why don't you try puting your Canvas class in a JScrollPane so you can make it bigger then the window and scrollable? You'll have scrollbar visibility issues. Fine, you can use java.awt.ScrollPane, I guess. Then I can think of several things one might do with JLayeredPanes which would create problems as well. And there is no simple "setDefaultLightWeightEnabled()" option to fix those.
So eventually, as your app, or library, matures, you start running into these problems cuz you are using AWT components where you should be using Swing components, and you start making more hack-like fixes for all these problems like using setDefaultLightWeightPopupEnabled() and explicit sizing instead of layout managers and limiting yourself to what you can do with your components.
Thx... I see your point. However, my app is a prototype for testing a particular model and I am not concerned with 'maturation', only development speed.
However, my app is aDo you realize that in the time it took to write this, you could have changed your Canvas subclass to be
prototype for testing a particular model and I am not
concerned with 'maturation', only development speed.
a JPanel subclass?
I've made changes in two places and it worked all the same - thx a lot I am more conformant now!!!
The next problem, forcing repaint on JPanel (formerly Canvas), is beyond my abilities - simple call repaint does not do the trick, it repaints after a followup interaction is triggered (right-click popup-menu).
Any suggestions on how to force the repaint to happen when I need it to happen???
you can't usually force it, actually... repaint() really just marks it as needing repainting and it'll do it sooner or later (relatively speaking). That's a technicality, though...
You could try calling...
panel.invalidate(); // or panel.revalidate();
I believe that how it works is that for Canvas, since it's not a container, it's sorta always "invalid", thus always needing repainting. But JPanel, and other containers, probably need to be marked invalid (like happens when modifying it's contents) so it repaints. Otherwise, the painting subsystem ignores it to save time.... (someone correct me if I'm wrong, of course.)