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

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

Use (and abuse) of Wimp_CreateMenu

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

Contents

  Use (and abuse) of Wimp_CreateMenu Steve Fryatt <news@stevefryatt.org.uk> - 2011-11-15 23:11 +0000
    Re: Use (and abuse) of Wimp_CreateMenu Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-11-16 00:19 +0000
      Re: Use (and abuse) of Wimp_CreateMenu Martin Bazley <martin.bazley@blueyonder.co.uk> - 2011-11-16 00:51 +0000

#1025 — Use (and abuse) of Wimp_CreateMenu

It's standard practice (and documented in the PRM) that following receipt of
a menu selection event to Wimp_Poll, calling Wimp_CreateMenu again will
repoen the existing menu structure in the position that it was in when the
selection occurred.

However, what isn't documented AFAICS is calling Wimp_CreateMenu at other
times while the menu is open, using the same menu handle, to refresh the
menu with new values (say because a selection has changed and the menu
entries relating to selections need to be updated).  I'm looking at some
code which I've inherited that does this, and it seems to fail: the menu
drops back to only displaying the first level.  However, the exact behaviour
varies between versions of RISC OS, which makes me wonder if it's straying
towards the boundary of 'defined behaviour' (or just buggy, which is far
from impossible :-).

So: does anyone know if a menu's ticked/shaded state can be changed while
it's open but *not* on a menu selection?  And if it can, how does one do it?
 Is it just a case of calling Wimp_CreateMenu with the same handle as the
currently open menu again?

-- 
Steve Fryatt - Leeds, England

http://www.stevefryatt.org.uk/

[toc] | [next] | [standalone]

#1026

The following bytes were arranged on 15 Nov 2011 by Steve Fryatt :

> It's standard practice (and documented in the PRM) that following receipt of
> a menu selection event to Wimp_Poll, calling Wimp_CreateMenu again will
> repoen the existing menu structure in the position that it was in when the
> selection occurred.

I've always strongly suspected that this is accomplished by means of an
extremely crude hack in the Wimp such as poking cached submenu states
into the first call of Wimp_CreateMenu.  It wouldn't be without
precedent - see, for example, Wimp_RedrawWindow's stipulation that "it
must be the first Wimp call after Wimp_Poll".

Here's another example to try: if you respond to an Adjust-click by
calling Wimp_CreateMenu with *different* x and y coordinates, does it
work? (NB: I have no idea what the answer is.)

> So: does anyone know if a menu's ticked/shaded state can be changed while
> it's open but *not* on a menu selection?  And if it can, how does one do it?

Just clutching at straws here, but have you considered first altering
the data structure contents and then using Wimp_ForceRedraw?  This
assumes some method of persuading the Wimp to divulge the coordinates of
a submenu, of course, which I can't think of off the top of my head.

> Is it just a case of calling Wimp_CreateMenu with the same handle as
> the currently open menu again?

There's no such thing as a 'menu handle', only a static pointer to a
menu data structure, and I don't think the Wimp keeps track of them
anywhere, so it'll be as if the user changed their mind and clicked Menu
at some completely different coordinates.  I too have found this rather
irksome in the past.

-- 
  __<^>__   "Start off every day with a smile and get it over with."
 / _   _ \  - W.C. Fields
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

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

#1027

> The following bytes were arranged on 15 Nov 2011 by Steve Fryatt :
>
> > So: does anyone know if a menu's ticked/shaded state can be changed while
> > it's open but *not* on a menu selection?  And if it can, how does one do it?

[snip]

Ooh - thought of another one!  Try abusing Wimp_SendMessage to slip
yourself a fake Menu_Selection event.  Set a flag to remind yourself
that you've done it, and on the next Wimp_Poll, if the flag's set, call
Wimp_CreateMenu and take no further action.  Check before all of this
that a menu that might need redrawing is actually open, via
Wimp_GetMenuState (although I'm not sure if that copes with being called
when the pointer is currently elsewhere either).

-- 
  __<^>__   "Start off every day with a smile and get it over with."
 / _   _ \  - W.C. Fields
( ( |_| ) )
 \_>   <_/  ======================= Martin Bazley ==========================

[toc] | [prev] | [standalone]

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

csiph-web