Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!newsfeed.kamp.net!newsfeed0.kamp.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Martin Wuerthner Newsgroups: comp.sys.acorn.programmer Subject: Re: Mixing Toolbox Menu objects with Wimp sub menus Date: Tue, 15 Nov 2011 23:29:08 +0100 Organization: MW Software Lines: 62 Message-ID: <58ecbb3252.martin@bach.planiverse.com> References: <3870129f-889e-4871-9647-1a9d61625548@x26g2000prf.googlegroups.com> X-Trace: individual.net 430vaCEj9yOCmXy23Xz1vAMPk9akqvSDtD3L/euWO65HwYmZpB X-Orig-Path: bach.planiverse.com%martin Cancel-Lock: sha1:0rn4/aMFW12mVc35oh9C9tH86fs= X-Editor: EmailEdit 6.00 User-Agent: Messenger-Pro/6.03 (MsgServe/6.00) (RISC-OS/5.16) NewsHound/v1.50-32 Xref: x330-a1.tempe.blueboxinc.net comp.sys.acorn.programmer:1024 In message <3870129f-889e-4871-9647-1a9d61625548@x26g2000prf.googlegro ups.com> wpb wrote: > I'm trying to integrate a non-Toolbox submenu onto a Toolbox Menu > object. This is what I have so far: > 1) Create the Wimp (sub)menu structure on an abts event for the > Toolbox parent menu. This is not really necessary. Why not simply create the submenu structure in 3) below? Delete it in 2). > 2) Destroy the Wimp (sub)menu structure on a hidden event for the > Toolbox parent menu. > So far so good. One caveat I've discovered. The Toolbox menu in > question is an iconbar menu, and when I select quit, I never get a > hidden event. So I also need to destroy the Wimp (sub)menu structure > on application quit, too. But that's off topic here... Why? When the application goes, there is no need to destroy anything (unless you decided for some strange reason to allocate the memory in the RMA or somewhere else outside application space). > 3) Listen for a submenu action event on the Toolbox menu item that's > supposed to lead to the Wimp submenu. When it fires, call > Wimp_CreateSubMenu to open the Wimp menu. Yes, that sounds reasonable - except that if this is a submenu rather than a dialogue, the Toolbox will not really know what to do with the menu selection event, so I presume you are opening a non-Toolbox Wimp window? > 4) The Toolbox *constantly* delivers these submenu action events. This > is the crux of the problem. I have to keep track of the fact that I've > opened the submenu already with a static bool, and don't keep trying > to open it. That sounds wrong. As you noted in 5) below, you do not know when this particular submenu is closed, so you cannot keep that flag up to date. I cannot see why the Toolbox would want to notify your program constantly. As I read the documentation you should only get the event once (after all, this is just a Wimp submenu warning event that the Toolbox passes on, and that event is sent only once, too). However, if the Toolbox decides to send it more than once, why not simply accept that fact and open the submenu each time you get the event? > 5) Due to 4), I need to know when the submenu closes (but the main > Toolbox Menu stays open), to reset my bool variable. This I can't do. > I tried listening to the MenusDeleted Wimp message, but that only > seems to be delivered when the *whole* menu structure is closed. Yes, correct. There is no easy way to find out when a submenu is closed by the Wimp, but then, I have not seen any reason why a program should need to know. -- --------------------------------------------------------------------- Martin Wuerthner MW Software http://www.mw-software.com/ RISC OS Software for Design, Printing and Publishing ---------------------------------------------------------------------