Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #1023 > unrolled thread

Mixing Toolbox Menu objects with Wimp sub menus

Back to article view | Back to comp.sys.acorn.programmer

Contents

  Mixing Toolbox Menu objects with Wimp sub menus wpb <w.blatchley@yahoo.com> - 2011-11-15 13:16 -0800
    Re: Mixing Toolbox Menu objects with Wimp sub menus Martin Wuerthner <spamtrap@mw-software.com> - 2011-11-15 23:29 +0100
      Re: Mixing Toolbox Menu objects with Wimp sub menus wpb <w.blatchley@yahoo.com> - 2011-11-15 22:26 -0800
      Re: Mixing Toolbox Menu objects with Wimp sub menus Rik Griffin <nospam@denbridgemarine.com> - 2011-11-16 10:10 +0000
        Re: Mixing Toolbox Menu objects with Wimp sub menus Rik Griffin <nospam@denbridgemarine.com> - 2011-11-16 10:12 +0000
          Re: Mixing Toolbox Menu objects with Wimp sub menus wpb <w.blatchley@yahoo.com> - 2011-11-16 02:28 -0800
            Re: Mixing Toolbox Menu objects with Wimp sub menus Rik Griffin <nospam@denbridgemarine.com> - 2011-11-16 10:57 +0000
              Re: Mixing Toolbox Menu objects with Wimp sub menus wpb <w.blatchley@yahoo.com> - 2011-11-16 03:35 -0800
        Re: Mixing Toolbox Menu objects with Wimp sub menus wpb <w.blatchley@yahoo.com> - 2011-11-16 10:52 -0800
    Re: Mixing Toolbox Menu objects with Wimp sub menus Erik G <erikg@noname.invalid> - 2011-11-16 15:28 +0100
    Re: Mixing Toolbox Menu objects with Wimp sub menus Gerph <gerph@gerph.org> - 2011-11-17 01:54 -0800
      Re: Mixing Toolbox Menu objects with Wimp sub menus wpb <w.blatchley@yahoo.com> - 2011-11-17 06:40 -0800
        Re: Mixing Toolbox Menu objects with Wimp sub menus Gerph <gerph@gerph.org> - 2011-11-17 06:57 -0800
          Re: Mixing Toolbox Menu objects with Wimp sub menus wpb <w.blatchley@yahoo.com> - 2011-11-17 14:36 -0800
            Re: Mixing Toolbox Menu objects with Wimp sub menus Matthew Phillips <spam2011m@yahoo.co.uk> - 2011-11-18 08:01 +0000

#1023 — Mixing Toolbox Menu objects with Wimp sub menus

Hello,

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.

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

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.

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.

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.

I feel sure this must have been done before. Can anyone tell me where
I'm going wrong?

Is there a way to stop the Toolbox constantly delivering the submenu
action event?

Thanks,

WPB

[toc] | [next] | [standalone]

#1024

In message <3870129f-889e-4871-9647-1a9d61625548@x26g2000prf.googlegro 
ups.com>
          wpb <w.blatchley@yahoo.com> 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
---------------------------------------------------------------------

[toc] | [prev] | [next] | [standalone]

#1029

On Nov 15, 11:29 pm, Martin Wuerthner <spamt...@mw-software.com>
wrote:
> > 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).

I could do that, but as generating the submenu structure is relatively
expensive, I thought it best that it persisted for the lifetime of the
menu. I could do what you say, though I'd definitely have to check if
it had already been created (=displayed on screen in that case),
because of the problem I describe of getting loads of submenu action
events.

[snip]
> > 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).

Yes, I hadn't thought of that. Just to satisfying my memory allocator,
really, which will scold me if I allocate memory I don't subsequently
free! ;)

> > 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?

No, it's a non-Toolbox Wimp menu I'm opening - not a window. There
will be no menu selection event from the Toolbox, because it's not
under the Toolbox's control. I'll have to listen to normal Wimp
messages to decode the menu.

> > 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?

Yes, I would very much like to eliminate my bool! But the fact is,
while the pointer is sitting over the relevant menu option, I get
those events repeatedly. Can anyone else confirm they've seen the same
thing?

I also can't see why the system would send this event multiple times.
It surely only needs to fire once for each *new* time the pointer
moves over the menu item in question.

I'll try just ignoring the fact that the menu's already open and
opening it again, but it's a shame to be sucking up CPU time.

[snip]
 > 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.

No, it shouldn't really be necessary, I agree. But in the example
above, it would help alleviate the problem.

Thanks,

WPB

[toc] | [prev] | [next] | [standalone]

#1030

In message <58ecbb3252.martin@bach.planiverse.com>
          Martin Wuerthner <spamtrap@mw-software.com> wrote:

> In message <3870129f-889e-4871-9647-1a9d61625548@x26g2000prf.googlegro 
> ups.com>
>           wpb <w.blatchley@yahoo.com> wrote:
> 
> > 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).

I've just done a quick test in ResTest and it does seem to be the case that
the Menu_SubMenu toolbox event is delivered repeatedly while the mouse
pointer is over the submenu arrow.

Looking at the toolbox source code reveals that this event is sent on
receipt of a MenuWarning Wimp message. So is the Wimp sending this message
repeatedly too? I've been using the Toolbox for so long I've forgotten how
the Wimp is meant to behave! More investigation is required.

Wimp 5.13, Toolbox 1.53, Menu 0.36 (ROOL versions).

[a short time later...]

It seems that the Wimp will keep sending MenuWarning messages until the
application opens the submenu. I suspect the problem is that the submenu
being opened is not the submenu specified in the parent menu's data.

Of course if the submenu was a Toolbox object, the Toolbox would correctly
fill in this data field.

I think the ultimate answer is to implement the submenu using the Toolbox.

-- 
Rik Griffin
Standard disclaimer, not speaking for anyone but myself, blah blah
(Reply-To may be broken: use rik dot griffin at denbridge marine dot com)

[toc] | [prev] | [next] | [standalone]

#1031

In message <f01cfc3252.rik-news@iyonix.elements>
          Rik Griffin <nospam@denbridgemarine.com> wrote:

> I've just done a quick test in ResTest and it does seem to be the case
> that the Menu_SubMenu toolbox event is delivered repeatedly while the
> mouse pointer is over the submenu arrow.

Just to clarify - this only happens if the menu item is flagged as having a
submenu, but no submenu object is specified. I only tested this in ResTest
so I don't know what happens if the application opens a (Toolbox) submenu
in response to the message, but I suspect it'd work correctly.

-- 
Rik Griffin
Standard disclaimer, not speaking for anyone but myself, blah blah
(Reply-To may be broken: use rik dot griffin at denbridge marine dot com)

[toc] | [prev] | [next] | [standalone]

#1033

On Nov 16, 11:12 am, Rik Griffin <nos...@denbridgemarine.com> wrote:
> In message <f01cfc3252.rik-n...@iyonix.elements>
>           Rik Griffin <nos...@denbridgemarine.com> wrote:
>
> > I've just done a quick test in ResTest and it does seem to be the case
> > that the Menu_SubMenu toolbox event is delivered repeatedly while the
> > mouse pointer is over the submenu arrow.
>
> Just to clarify - this only happens if the menu item is flagged as having a
> submenu, but no submenu object is specified. I only tested this in ResTest
> so I don't know what happens if the application opens a (Toolbox) submenu
> in response to the message, but I suspect it'd work correctly.

Rik - thanks a lot for running those tests.

Shouldn't the Toolbox stop delivering the event if the event handler
returns 1 to say its handled the event?

[toc] | [prev] | [next] | [standalone]

#1034

In message <a298d608-b705-4378-8e76-ece909a93851@d37g2000prg.googlegroups.com>
          wpb <w.blatchley@yahoo.com> wrote:

> Shouldn't the Toolbox stop delivering the event if the event handler
> returns 1 to say its handled the event?

When your event handler claims an event, it's only notifying eventlib not
to pass the event along to any more handlers. The toolbox itself doesn't
have any knowledge of this.

Anyway, it's the Wimp that's ultimately delivering the event repeatedly,
probably because you're opening the "wrong" submenu.

-- 
Rik Griffin
Standard disclaimer, not speaking for anyone but myself, blah blah
(Reply-To may be broken: use rik dot griffin at denbridge marine dot com)

[toc] | [prev] | [next] | [standalone]

#1035

On Nov 16, 11:57 am, Rik Griffin <nos...@denbridgemarine.com> wrote:
> In message <a298d608-b705-4378-8e76-ece909a93...@d37g2000prg.googlegroups.com>
>           wpb <w.blatch...@yahoo.com> wrote:
>
> > Shouldn't the Toolbox stop delivering the event if the event handler
> > returns 1 to say its handled the event?
>
> When your event handler claims an event, it's only notifying eventlib not
> to pass the event along to any more handlers. The toolbox itself doesn't
> have any knowledge of this.

Ah, I see. Thanks for the clarification.

> Anyway, it's the Wimp that's ultimately delivering the event repeatedly,
> probably because you're opening the "wrong" submenu.

I'll have a play around and see if I can persuade it to behave as I
want. It shouldn't be so hard to hook up a regular menu to a Toolbox
one. I'm surprised this isn't a more common problem...

Anyway, thanks for your input and I'll report back if I have any
success.

WPB

[toc] | [prev] | [next] | [standalone]

#1039

On Nov 16, 11:10 am, Rik Griffin <nos...@denbridgemarine.com> wrote:
> It seems that the Wimp will keep sending MenuWarning messages until the
> application opens the submenu. I suspect the problem is that the submenu
> being opened is not the submenu specified in the parent menu's data.
>
> Of course if the submenu was a Toolbox object, the Toolbox would correctly
> fill in this data field.

Yet the PRM says (pg. 3-156):

"Bit 3 of the menu flags changes the submenu behaviour. If it is set,
then moving over the
right arrow will cause a MenuWarning message to be generated. The
application can
respond as it sees fit, usually by calling Wimp_CreateSubMenu (page
3-196) to display
the appropriate object. Note that in this case the submenu pointer in
the menu structure
does not have to be valid, but it is passed to the application in the
message block
anyway. The submenu pointer is important if Wimp_DecodeMenu will be
used later on."

So it doesn't sound like you *have* to give matching submenu pointers.

I'm getting these repeated Toolbox events, even though I open the
submenu on getting the first one.

[toc] | [prev] | [next] | [standalone]

#1036

On 15-11-2011 22:16, wpb wrote:
> I'm trying to integrate a non-Toolbox submenu onto a Toolbox Menu
> object.

Why not create the submenu as a Toolbox object?

I would strongly discourage mixing Wimp objects and Toolbox objects.
There would have to be a compelling reason to do so.

When mixing, you will constantly need to guess how the Toolbox handles
objects and which Wimp events and which Toolbox events you can and
should expect and use. Often you need to find the Wimp handles of
Toolbox objects, and perform Wimp actions on them. You need to think
about which Wimp calls you can make without messing up the Toolbox.

In short, you should stick to the Toolbox whenever possible.

In my experience, if you need to set the Toolbox aside and use the Wimp
for certain objects, then you are attempting to do things that lie
outside the Style Guide. (Bring on the flame :-) )

> 1) Create the Wimp (sub)menu structure on an abts event for the
> Toolbox parent menu.

As a general rule, make sure that you always have a consistent menu
structure. That is, if a menu has a submenu pointer, there should exist
an object that is pointed to.

If necessary use a bare-bones object for the submenu, with only the
title filled in (or not even that) and the minimum of menu items (maybe
even zero). You can then fill in the submenu on an AboutToBeShown event.

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

As noted by others, this is probably caused by the non-existence of the
submenu when the user hovers over the submenu arrow in the parent menu.

This problem is avoided if a submenu object already exists before the
parent menu is shown, as described above.

Enjoy!

-- 
Erik G.
From address is fake
See http://erikgrnh.home.xs4all.nl/

[toc] | [prev] | [next] | [standalone]

#1040

On Nov 15, 9:16 pm, wpb <w.blatch...@yahoo.com> wrote:
> Hello,
>
> I'm trying to integrate a non-Toolbox submenu onto a Toolbox Menu
> object. This is what I have so far:

Number 1 on my 'Things Not To Do' for pre-Adjust/Select 3i4:
 * Create a Toolbox menu with a non-toolbox object as part of its
tree.

--
Gerph

[toc] | [prev] | [next] | [standalone]

#1041

On Nov 17, 10:54 am, Gerph <ge...@gerph.org> wrote:
> On Nov 15, 9:16 pm, wpb <w.blatch...@yahoo.com> wrote:
>
> > Hello,
>
> > I'm trying to integrate a non-Toolbox submenu onto a Toolbox Menu
> > object. This is what I have so far:
>
> Number 1 on my 'Things Not To Do' for pre-Adjust/Select 3i4:
>  * Create a Toolbox menu with a non-toolbox object as part of its
> tree.
>
> --
> Gerph

He he! Haven't seen you around here for a long while... Though I'm not
often here myself, so maybe you've been around all along...

Anyway, thanks for sharing. It's a shame it's so hard really.

Anyway, I'm going to try to generate a toolbox menu on the fly
instead. I'll post back if I need any guidance (which is likely, I
think!)

Cheers,

WPB

[toc] | [prev] | [next] | [standalone]

#1042

On Nov 17, 2:40 pm, wpb <w.blatch...@yahoo.com> wrote:
> On Nov 17, 10:54 am, Gerph <ge...@gerph.org> wrote:
>
> > On Nov 15, 9:16 pm, wpb <w.blatch...@yahoo.com> wrote:
>
> > > Hello,
>
> > > I'm trying to integrate a non-Toolbox submenu onto a Toolbox Menu
> > > object. This is what I have so far:
>
> > Number 1 on my 'Things Not To Do' for pre-Adjust/Select 3i4:
> >  * Create a Toolbox menu with a non-toolbox object as part of its
> > tree.
>
> > --
> > Gerph
>
> He he! Haven't seen you around here for a long while... Though I'm not
> often here myself, so maybe you've been around all along...
>
> Anyway, thanks for sharing. It's a shame it's so hard really.

Of course, further details can be found in the documentation, albeit
the documentation is tailored for toolbox object authors, rather than
Toolbox users.

http://select.riscos.com/prm/toolbox/submenus.html

As discussed, the problems with such cases still exist for cases
outside those addressed by the changes to Objects.

--
Gerph

[toc] | [prev] | [next] | [standalone]

#1044

Thanks for all advice given so far, folks.

So, I've decided to abandon the Wimp menu, and construct a Toolbox
menu in memory on the fly. It seems straightforward enough. Just a
couple of things I'm not clear about that people here can probably
steer me the right way about:

1) Presumably I (the client) have to hang on to any Menu objects, menu
entry elements and strings that I allocate? In other words, the
Toolbox doesn't take copies of what I pass it?

2) My understanding of how malloc allocates memory for a Wimp task
is...well, pretty much non-existent. Presumably it takes a chunk of my
Wimp slot. Would it be sensible to do a single large malloc for all
the menu entries and menu text strings first, to avoid fragmentation?
Or is that being overly paranoid?

Thanks,

WPB

[toc] | [prev] | [next] | [standalone]

#1045

In message <7bb6072e-0080-4f2f-a1c6-ac518809359a@k10g2000yqn.googlegroups.com>
 on 17 Nov 2011 wpb  wrote:

> 2) My understanding of how malloc allocates memory for a Wimp task
> is...well, pretty much non-existent. Presumably it takes a chunk of my Wimp
> slot.

Yes, it takes a chunk of your Wimp slot and extends the Wimp slot if
necessary.  The extra Wimp slot is never relinquished again until the program
terminates.

> Would it be sensible to do a single large malloc for all the menu entries
> and menu text strings first, to avoid fragmentation? Or is that being
> overly paranoid?

It depends whether your routines for allocating that memory will end up being
better than the C Library's!  If you don't know much about it it's probably
best to let malloc do all the hard work.

Frangmentation only occurs if you free the memory.  If you can predict how
much memory you need well enough that you never need to free and reallocate
that large block you're proposing, then you could equally well allocate
adequate small lumps of memory, per menu entry and per text string.

If you can't predict that well, and you might have to free and reallocate,
then freeing and reallocating a big block of memory is going to cause
fragmentation on a larger scale, not reduce it.

-- 
Matthew Phillips
Durham

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.acorn.programmer

csiph-web