Menu problem under 4.1 update 1

I'm using the same struct NewMenu array on multiple windows. If I have one window open then menus works as usual. But if I have two or more windows open then it takes several seconds menus to appear on screen. There wasn't this kind of problems before update1. Do anybody have any ideas why that happens ? And if anybody wants to test/verify this, the app in question is YetAnotherDesk.

@TSK

Check the autodoc for IDCMP_MENUVERIFY.

Simon

@Rigo

Quote:
I added IDCMP_MENUVERIFY into my windows IDCMP flags but that didn't change anything. Can you give any example how to use it ?

Quote:
What I meant earlier is the main menu strip opens immediately but sub menus opens after short time period.

@TSK

OK, I'll explain it once more for the last time.

By default, window.class enables the IDCMP_MENUVERIFY bit when the window has helphints enabled (There may also be other situations where this bit is set).

When intuition detects that the right mouse button is pressed, it sends all open windows a MENUVERIFY msg if the window has the above bit set. The windows event loop has to process events in order for the msg to be replied to ( to be precise, the WM_HANDLEINPUT method has to be called).

If a child window is opened, the usual course of action from the application is to run through the events for the child only, so the parent doesn't get a chance to reply to the verify msg thereby stalling intuitions verify check that it's OK to open the menus.

Changes in intuition for Update 1 have made that msg "time out", which is why holding down the button makes the menus appear eventually, after intuition has given up waiting (typically 10 seconds).

The best course of action is to set the WA_BusyPointer attribute on the parent window object with SetAttrs(), this removes the IDCMP_MENUVERIFY bit for the duration that the window is busy. Do not confuse this with the window attribute set with SetWindowAttrs() as this by-passes window.class completely, and won't clear the bit. If you are opening an ASL file requester, you can pass the parent window in ASLFR_SleepWindow and ASL will set the window busy for you, and intuition skips sending the menu verification message to the parent window.

Alternatively, if you want multiple window.class objects open simultaneously, make sure that all events for all objects are handled correctly at all times.

Any program that doesn't handle this is simply not structured correctly, and/or is not adhering to the rules for intuition message handling. It has been this way since OS2.0, and if it worked before then it's more luck than judgement, as this is a well documented "feature".

Further in-depth explanations can be found in the IDCMP section of the Intuition.library chapter of the RKRMs.

Simon

@TSK

There is a problem like this for tunnet asl req. menus. 4.1 update 1 versin

@my_pc_is_amiga

This has been fixed for the next update of TuneNet. Resolved by setting ASLFR_SleepWindow (in addition to ASLFR_Window).

Cheers,
Bean

@Rigo

Thanks. The tip about SetAttrs() instead of SetWindowAttrs() was very helpful. (One never stops learning I guess.)

@trixie

Quote:

When using window.class, you are dealing with BOOPSI objects, the resulting intuition window is a result of that object. Setting an attribute of the window with SetWindowAttrs() simply sets it for the intuition window, and bypasses the window.class object completely, which is not the intended behaviour. Object attributes should always be set with SetAttrs() in order that the controlling object is aware of the changes.

Simon

@Rigo

I realized what was wrong finally. I've thought always that one don't have to take care of Intui events of inactive windows. And that's wrong. Doh. That didn't affect previous versions of the AmigaOS.

That was also a good note that one shouldn't mix window.class functions and Intui-window functions.