Ok I am still working on my top level menubar. I am having a problem.
I am using text buttons as the top level menu item on the menu bar. The buttons have a custom look and feel that paints it based on mouse over, mouse not over and mouse down.
I have an event handler that fires when any button is pressed, which shows the appropriate popup window.
Originaly I was displaying the popupwindow right beneath the textbutton, aligned so they look they are one component. But I found that when you exit the menu, either by selecting an item or clicking outside of it, sometimes the textbutton would repaint after the menu dissapeared, with a slight delay that appeared to be a flicker/artifact, since it wasn’t timed perfectly.
My perfectionist mindset was not happy. It did not look good.
So now I am painting my popup menus right on top of where the text button is. When I click out I am still having the problem. THe underlying text button is not being redrawn until after the menu is exited.
I tried forcing button->repaint() before calling popupmenu.showat(), but no matter what I do, the LookAndFeel event doesn’t fire until after the menu is exited.
How can I force the lookandfeel code to repaint the button to a normal state before the popupmenu is displayed, so that once the popupmenu dissapears, there will be no subsequent drawing on the button, eliminating the artifact?
Sounds like it’s the fact that the button’s not updating its mouse-over state until the modal popup menu has gone away. Not sure of a quick hack, but I guess you could disable the button while the menu’s visible?
Ok I’ll try this, but what would disabling the button do? Its weird that even when I explicitly call repaint on the button, that the L&F handler does not get called until after the menu goes away. Wouldn’t disabling it have the same limitation?
If you call repaint, then it will definitely call the paint() method - I’m guessing that it’s still stuck in the ‘down’ state because there’s another component modal, and that’s why it looks like it’s not repainting…
disabling would just make it return to it’s normal state, i.e. not ‘over’ or ‘down’.
[quote=“jules”]If you call repaint, then it will definitely call the paint() method - I’m guessing that it’s still stuck in the ‘down’ state because there’s another component modal, and that’s why it looks like it’s not repainting…
disabling would just make it return to it’s normal state, i.e. not ‘over’ or ‘down’.[/quote]
Another idea I thought of was to customize the button so it handles the mouse down, at which point it would repaint itself to normal. This should be called before the popupmenu would be shown I think, since the popupmenu is shown in the actionlistener for the button.
The only problem I see with that is that I could have the reverse issue, where the menu button repaints to normal in a visible way for a split second before the popupmenu paints over it with the new “fake” menu button.
I wonder how Windows accomplishes this so that I never see this artifact?
