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.
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.)