I prefer to use sticky panels for menus, but often the OS seems to think that I'm not pressing down the mouse button long enough. Sometimes the menu does not come up at all, sometimes the bar appears and disappears again immediately.
I suspect this may have something to do with windows that have IDCMP_MENUVERIFY set and are not quick enough to deal with it, but that's just a guess. If so, this still should not happen, IMO. The mouse is working well and I've tried another one, so that won't be it.
Does anyone else experience this, or is it just me, as usual?
@djg
No problem here. Check your SYS:Prefs/Input prefs. You can switch your select & menu buttons and use the double-click test to see if you are getting spurious button clicks. I have some older PS2 mice with USB adapters that display symptoms similar to yours. Similar things can happen when a wireless mouse battery is getting low. I think it's more likely a mouse, cable or connector problem.
djg wrote:I prefer to use sticky panels for menus, but often the OS seems to think that I'm not pressing down the mouse button long enough. Sometimes the menu does not come up at all, sometimes the bar appears and disappears again immediately.
I suspect this may have something to do with windows that have IDCMP_MENUVERIFY set and are not quick enough to deal with it, but that's just a guess. If so, this still should not happen, IMO. The mouse is working well and I've tried another one, so that won't be it.
Does anyone else experience this, or is it just me, as usual?
Sometimes i have the same problem too, it may depends on the exact point of the top bar where you click or somethings similar ..
I've done what you said but I get the same result. I have wired mice without adapters. I've also noticed that the problem doesn't seem to occur right after booting, but does occur when I run one of my own programs (which does use IDCMP_MENUVERIFY). I will have to do some more testing in the next few days. Could be my own fault somehow.
Maybe. It also seems that the menu always appears immediately when you click the button while moving the mouse, but that there can be a short delay if you don't move it. But I am really super lazy, that's why I like sticky panels in the first place. That way I don't have to keep pressing the button while making my selection.
djg wrote:@xenic
I've done what you said but I get the same result. I have wired mice without adapters. I've also noticed that the problem doesn't seem to occur right after booting, but does occur when I run one of my own programs (which does use IDCMP_MENUVERIFY). I will have to do some more testing in the next few days. Could be my own fault somehow.
I'm not sure what effect menu prefs might have but here are some of my settings that might make a difference:
GUI Preferences/Menus - "Non blocking" is NOT set on my system.
GUI Preferences/Controls/Global Intuition Controls/Miscellaneous - "Screen menu snap" is checked (active).
I'm not sure what those prefs items do, but it might be worthwhile to check your settings.
djg wrote:@xenic
I've done what you said but I get the same result. I have wired mice without adapters. I've also noticed that the problem doesn't seem to occur right after booting, but does occur when I run one of my own programs (which does use IDCMP_MENUVERIFY). I will have to do some more testing in the next few days. Could be my own fault somehow.
I'm not sure what effect menu prefs might have but here are some of my settings that might make a difference:
GUI Preferences/Menus - "Non blocking" is NOT set on my system.
GUI Preferences/Controls/Global Intuition Controls/Miscellaneous - "Screen menu snap" is checked (active).
I'm not sure what those prefs items do, but it might be worthwhile to check your settings.
I think "Non blocking" means that rendering in windows will not be paused while a menu bar is active, and "Screen menu snap" makes sure the menu is visible on screens larger than the viewing area. I have Non blocking checked, as I know of no disadvantages. Same goes for "Screen menu snap". Neither made a difference.
The problem happens when I have the window of my own program open. I use IDCMP_MENUVERIFY so I can enable or disable a menu item before the menu will be shown. When the message arrives, I call ClearMenuStrip, enable or disable a menu item, and then call ResetMenuStrip. If I remove this code after getting the message, every click always brings up the menu, however short or light.
djg wrote:The problem happens when I have the window of my own program open. I use IDCMP_MENUVERIFY so I can enable or disable a menu item before the menu will be shown. When the message arrives, I call ClearMenuStrip, enable or disable a menu item, and then call ResetMenuStrip. If I remove this code after getting the message, every click always brings up the menu, however short or light.
Maybe calling ClearMenuStrip() while intuition is about to display the menu isn't such a good idea.
You could try IIntuition->OnMenu() and IIntuition->OffMenu() to enable or disable a menu item.
djg wrote:The problem happens when I have the window of my own program open. I use IDCMP_MENUVERIFY so I can enable or disable a menu item before the menu will be shown. When the message arrives, I call ClearMenuStrip, enable or disable a menu item, and then call ResetMenuStrip. If I remove this code after getting the message, every click always brings up the menu, however short or light.
Maybe calling ClearMenuStrip() while intuition is about to display the menu isn't such a good idea.
You could try IIntuition->OnMenu() and IIntuition->OffMenu() to enable or disable a menu item.
Maybe not, but isn't that the whole point of the verify flag?
All I am using it for is to enable or disable a menu item called "Insert", depending on whether or not there is text in the clipboard. This could change outside of my program, and I don't want to have the program check all the time whether this has happened. I will simply leave it enabled now, and if the clipboard is empty after selecting "Insert" have the program say so.
I've tried OnMenu()/OffMenu also, without ClearMenuStrip()/SetMenuStrip(), but that doesn't help. I suspect that maybe they call the functions themselves.
djg wrote:Maybe not, but isn't that the whole point of the verify flag?
No - the point of it is so you can back-up parts of the screen that are likely to get destroyed by Intuition, and potentially change the pen colours (or does Intuition do that itself? Can't remember)
I've tried OnMenu()/OffMenu also, without ClearMenuStrip()/SetMenuStrip(), but that doesn't help. I suspect that maybe they call the functions themselves.
OnMenu/OffMenu should work fine. No idea if they work as late as MENUVERIFY though, I've only ever called them during normal program execution.
