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

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

Finding location of current menu

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

Contents

  Finding location of current menu Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-01-30 23:43 +0000
    Re: Finding location of current menu druck <news@druck.org.uk> - 2020-01-31 08:10 +0000
    Re: Finding location of current menu news@sprow.co.uk - 2020-01-31 00:55 -0800
      Re: Finding location of current menu Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-02-02 13:19 +0000
        Re: Finding location of current menu Alan Adams <alan@adamshome.org.uk> - 2020-02-02 20:12 +0000
    Re: Finding location of current menu Steve Fryatt <news@stevefryatt.org.uk> - 2020-01-31 22:45 +0000
      Re: Finding location of current menu Jean-Michel <jmc.bruck@orange.fr> - 2020-02-01 20:38 +0100
      Re: Finding location of current menu Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-02-02 13:17 +0000
        Re: Finding location of current menu Terry Kelly <tk@cestriant.plus.com> - 2020-02-02 16:45 +0000
          Re: Finding location of current menu Steve Fryatt <news@stevefryatt.org.uk> - 2020-02-02 19:44 +0000
        Re: Finding location of current menu svrsig <chris@svrsig.org> - 2020-02-14 06:48 -0800
          Re: Finding location of current menu Matthew Phillips <spam2011m@yahoo.co.uk> - 2020-02-14 22:03 +0000
            Re: Finding location of current menu svrsig <chris@svrsig.org> - 2020-02-19 10:45 -0800

#5954 — Finding location of current menu

Menus are implemented as windows, but handled by the Wimp, as I understand
it.

In RiscOSM you can open a menu to view web pages relating to the item on the
map.  The software used to open the menu straight away, just showing the
links we could calculated direct from the map data.  A few versions ago we
enhanced it to look up the map item in Wikidata and obtain a wider range of
web links from there.  This came at a price: the menu does not open
immediately because the Wikidata API has to be called and return its results,
so we have a timeout (defaulting to five seconds) after which the basic links
appear and the Wikidata lookup is abandoned.

As a further enhancement, we're wanting the menu to open immediately, showing
the links derived direct from the map, and for the links from the Wikidata
lookup to be added once they have been fetched.  This will entail making the
menu longer, and therefore reopening it.

We know where we opened the menu initially, but the user might have dragged
the menu across the screen, so reopening it by giving explicit co-ordinates
might make it jump back to the original location.

The other option would be to use Wimp_CreateMenu passing 0 in R2 and R3, like
you do if you are reopening a menu after an Adjust click on one of the
items.  But that only works if you have not changed R1, the pointer to the
menu block.  When we add items to the menu, we sometimes have to move the
menu block because a larger block of memory has had to be allocated.  So
that's no good.

We were wondering if there is any way of finding the location of the current
menu so that we can open the lengthened menu in the right place.  I cannot
see a suitable SWI anywhere.

We came across Wimp_GetMenuState which refers to the window handle of the
menu in R2, but bizarrely that is as an input value, and I cannot see how you
are supposed to know the window handle of any menu!  The PRM explanation of
that call is quite unenlightening and it's hard to know how you are supposed
to use it with R0=1.  The RISC OS Select Wimp PRM does not say anything more.

That's rather irrelevant to our problem, but it does show that it seems to be
very difficult to get any information about the currently open menu, other
than the current tree state for menus you have opened.

Any ideas?  We're currently favouring reopening the lengthened menu where we
first opened it.

-- 
Matthew Phillips
Durham

[toc] | [next] | [standalone]

#5955

On 30/01/2020 23:43, Matthew Phillips wrote:
> We know where we opened the menu initially, but the user might have dragged
> the menu across the screen, so reopening it by giving explicit co-ordinates
> might make it jump back to the original location.

[Snip]

> Any ideas?  We're currently favouring reopening the lengthened menu where we
> first opened it.

I suspect that is the best solution if you want everything on the main 
menu.

An alternative would be to put all of the discovered links in to a 
dynamically created submenu, that way you can display the main menu 
immediately, and start fetching the links. Any delay would only occur if 
attempting to open the sub menu while still fetching. The main menu 
wouldn't then need redisplaying, so no need to worry about its position.

---druck

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

#5956

On Thursday, 30 January 2020 23:43:19 UTC, Matthew Phillips  wrote:
> Menus are implemented as windows, but handled by the Wimp, as I understand
> it.
> 
> In RiscOSM you can open a menu to view web pages relating to the item on the
> map.  The software used to open the menu straight away, just showing the
> links we could calculated direct from the map data.  A few versions ago we
> enhanced it to look up the map item in Wikidata and obtain a wider range of
> web links from there.  This came at a price: the menu does not open
> immediately because the Wikidata API has to be called and return its results,
> so we have a timeout (defaulting to five seconds) after which the basic links
> appear and the Wikidata lookup is abandoned.

If it's just a single flat menu (no submenus) could you, having noted that the Wimp constructs menus from windows and icons just the same as any other, create your own menu handling routines which create it as a normal window? You'd then be free to manipulate it as a normal window.

Just be sure to close it if the user Menu clicks somewhere else, otherwise there would be 2 menus on screen at once!
Sprow.

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

#5960

In message <ae07e9e3-7e1f-43de-a6c3-83b8e2b1bbac@googlegroups.com>
 on 31 Jan 2020 news@sprow.co.uk wrote:

> On Thursday, 30 January 2020 23:43:19 UTC, Matthew Phillips  wrote:
> > Menus are implemented as windows, but handled by the Wimp, as I
> > understand it.
> > 
> > In RiscOSM you can open a menu to view web pages relating to the item on
> > the map.  The software used to open the menu straight away, just showing
> > the links we could calculated direct from the map data.  A few versions
> > ago we enhanced it to look up the map item in Wikidata and obtain a wider
> > range of web links from there.  This came at a price: the menu does not
> > open immediately because the Wikidata API has to be called and return its
> > results, so we have a timeout (defaulting to five seconds) after which
> > the basic links appear and the Wikidata lookup is abandoned.
> 
> If it's just a single flat menu (no submenus) could you, having noted that
> the Wimp constructs menus from windows and icons just the same as any
> other, create your own menu handling routines which create it as a normal
> window? You'd then be free to manipulate it as a normal window.

Yes, that would be an option. Hilary changed the bookmarks menu in RiscOSM
recently to implement it as a window that looks like a menu. This allowed her
to add an edit and a delete icon next to each menu item to make it easier to
change the bookmarks.

-- 
Matthew Phillips
Durham

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

#5963

In message <ac3f013c58.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:

> In message <ae07e9e3-7e1f-43de-a6c3-83b8e2b1bbac@googlegroups.com>
>  on 31 Jan 2020 news@sprow.co.uk wrote:

>> On Thursday, 30 January 2020 23:43:19 UTC, Matthew Phillips  wrote:
>>> Menus are implemented as windows, but handled by the Wimp, as I
>>> understand it.
>>> 
>>> In RiscOSM you can open a menu to view web pages relating to the item on
>>> the map.  The software used to open the menu straight away, just showing
>>> the links we could calculated direct from the map data.  A few versions
>>> ago we enhanced it to look up the map item in Wikidata and obtain a wider
>>> range of web links from there.  This came at a price: the menu does not
>>> open immediately because the Wikidata API has to be called and return its
>>> results, so we have a timeout (defaulting to five seconds) after which
>>> the basic links appear and the Wikidata lookup is abandoned.
>> 
>> If it's just a single flat menu (no submenus) could you, having noted that
>> the Wimp constructs menus from windows and icons just the same as any
>> other, create your own menu handling routines which create it as a normal
>> window? You'd then be free to manipulate it as a normal window.

> Yes, that would be an option. Hilary changed the bookmarks menu in RiscOSM
> recently to implement it as a window that looks like a menu. This allowed her
> to add an edit and a delete icon next to each menu item to make it easier to
> change the bookmarks.

I have done something similar to allow keyboard navigation of my menus. 
The "menu" is a window I created, and the icons can have input focus, 
allowing keypresses to be returned. The selected item changes with for 
example the up and down arrow keys, done by toggling flags in the icons.

In my case I don't use the toolbox, but the Wimp_ calls directly. For 
normal menus, not the "fake" ones, the important thing is to understand 
that the menu structure passed to the wimp to create the menu is used 
subsequently by the wimp, so you can't mess with it while the menu is 
open. (You can change things, but you need to understand what can be 
changed.) Submenus can be changed on the fly, i.e. as the pointer moves 
over the submenu arrow, the wimp calls your application, and at that point 
the menu structure is created and Wimp_CreateSubMenu called.

As only one menu can be open at a time, you only need a single memory 
block for the main menu, and one for the submenu.

-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

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

#5957

On 30 Jan, Matthew Phillips wrote in message
    <30e2ae3a58.Matthew@sinenomine.freeserve.co.uk>:

> We came across Wimp_GetMenuState which refers to the window handle of the
> menu in R2, but bizarrely that is as an input value, and I cannot see how
> you are supposed to know the window handle of any menu!  The PRM
> explanation of that call is quite unenlightening and it's hard to know how
> you are supposed to use it with R0=1.

My guess is that Wimp_GetMenuState is primarily aimed at handling
Message_HelpRequest, where you get provided with a window and icon handle,
and the problem is working out how they relate to your application.

> Any ideas?  We're currently favouring reopening the lengthened menu where
> we first opened it.

I have to say that Druck's solution sounds better, both from a GUI point of
view and from the fact that you can change and re-open the submenu as much
as you like without the base menu address changing.

I can't immediately think of a legal way to get the menu's window handle.

-- 
Steve Fryatt - Leeds, England

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

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

#5958

In message <mpro.q4ztv001i3wxf02ho.news@stevefryatt.org.uk>
          Steve Fryatt <news@stevefryatt.org.uk> wrote:

> On 30 Jan, Matthew Phillips wrote in message
>     <30e2ae3a58.Matthew@sinenomine.freeserve.co.uk>:

>> We came across Wimp_GetMenuState which refers to the window handle of the
>> menu in R2, but bizarrely that is as an input value, and I cannot see how
>> you are supposed to know the window handle of any menu!  The PRM
>> explanation of that call is quite unenlightening and it's hard to know how
>> you are supposed to use it with R0=1.

> My guess is that Wimp_GetMenuState is primarily aimed at handling
> Message_HelpRequest, where you get provided with a window and icon handle,
> and the problem is working out how they relate to your application.

>> Any ideas?  We're currently favouring reopening the lengthened menu where
>> we first opened it.

> I have to say that Druck's solution sounds better, both from a GUI point of
> view and from the fact that you can change and re-open the submenu as much
> as you like without the base menu address changing.

> I can't immediately think of a legal way to get the menu's window handle.

I have a similar problem in my Xml Editor to find window handle from a 
gadget, to move an resize it (treeview).
Rick Griffin (treeview 0.23) added a method to get window id / toolbox  
object, and now  I get the toolbox object and  call 
window_get_wimp_handle().

A question : when you create a menu structure dynamically, you have to 
create the object ?
toolbox_create_object()
     Defined in:  oslib/<toolbox=>toolbox_>.h
     Declaration:  extern <toolbox_o>  toolbox_create_object
         ( <toolbox_create_flags> flags,
           <toolbox_id> id
         );

     Description: Creates an object from a named resource or an 
     object structure.

sorry for my English
-- 
Jean-Michel BRÜCK (France)
Mél :jmc.bruck@orange.fr

RiscOS 5.23 : RiscPc/IyonixPC/Raspberry/ARMX6.

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

#5959

In message <mpro.q4ztv001i3wxf02ho.news@stevefryatt.org.uk>
 on 31 Jan 2020 Steve Fryatt  wrote:

> On 30 Jan, Matthew Phillips wrote in message
>     <30e2ae3a58.Matthew@sinenomine.freeserve.co.uk>:
> 
> > We came across Wimp_GetMenuState which refers to the window handle of the
> > menu in R2, but bizarrely that is as an input value, and I cannot see how
> > you are supposed to know the window handle of any menu!  The PRM
> > explanation of that call is quite unenlightening and it's hard to know how
> > you are supposed to use it with R0=1.
> 
> My guess is that Wimp_GetMenuState is primarily aimed at handling
> Message_HelpRequest, where you get provided with a window and icon handle,
> and the problem is working out how they relate to your application.

That's a very good point. I had not thought of that. I don't think I've ever
provided interactive help over menus, but I can see it would be necessary to
do this lookup.
 
> > Any ideas?  We're currently favouring reopening the lengthened menu where
> > we first opened it.
> 
> I have to say that Druck's solution sounds better, both from a GUI point of
> view and from the fact that you can change and re-open the submenu as much
> as you like without the base menu address changing.

Another advantage of using a submenu is that it could be greyed out until the
links have been fetched.  If the items on the main menu changed while the
user had it open, there could be a situation where the user clicks the mouse,
and before their brain has completed the operation the application has
inserted extra items and so the user ends up clicking on something
unexpected.

-- 
Matthew Phillips
Durham

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

#5961

In message <250f013c58.Matthew@sinenomine.freeserve.co.uk>
          Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
[snip]
> Another advantage of using a submenu is that it could be greyed out until the
> links have been fetched.  If the items on the main menu changed while the
> user had it open, there could be a situation where the user clicks the mouse,
> and before their brain has completed the operation the application has
> inserted extra items and so the user ends up clicking on something
> unexpected.

Would it be feasible to have two separate sub-menus (initial links & 
further links), the second one being greyed out until the extra links have 
been received. This would avoid any problems from inserting extra items 
into a list, and possibly less confusing to the user.

-- 
Regards,
Terry

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

#5962

On 2 Feb, Terry Kelly wrote in message
    <9311143c58.Terry@tez.freeserve.co.uk>:

> In message <250f013c58.Matthew@sinenomine.freeserve.co.uk>
>           Matthew Phillips <spam2011m@yahoo.co.uk> wrote:
> [snip]
> > Another advantage of using a submenu is that it could be greyed out
> > until the links have been fetched.  If the items on the main menu
> > changed while the user had it open, there could be a situation where the
> > user clicks the mouse, and before their brain has completed the
> > operation the application has inserted extra items and so the user ends
> > up clicking on something unexpected.
> 
> Would it be feasible to have two separate sub-menus (initial links &
> further links), the second one being greyed out until the extra links have
> been received. This would avoid any problems from inserting extra items
> into a list, and possibly less confusing to the user.

One of the dangers of updating the menu dynamically is the "dynamic webpage
link problem", where the user goes to click on a link, only to find that in
the time between thinking it and the mouse button being depressed, the page
has reflowed due to more content having been downloaded, and the click
actually follows a clickbait advert which now occupies the space under the
mouse[1].

The equivalent here is the menu entries shuffling around, so that the click
lands on a different entry in the menu from the one intended.

1. Online versions of Johnston Press newspapers suffer from this acutely.

-- 
Steve Fryatt - Leeds, England

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

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

#5977

On Sunday, February 2, 2020 at 1:19:46 PM UTC, Matthew Phillips wrote:
> In message <mpro.q4ztv001i3wxf02ho.news@stevefryatt.org.uk>
>  on 31 Jan 2020 Steve Fryatt  wrote:
> 

> > My guess is that Wimp_GetMenuState is primarily aimed at handling
> > Message_HelpRequest, where you get provided with a window and icon handle,
> > and the problem is working out how they relate to your application.
> 
> That's a very good point. I had not thought of that. I don't think I've ever
> provided interactive help over menus, but I can see it would be necessary to
> do this lookup.
>  
Shame on you. It only came in with RISC OS 3 but that was some time ago. I added it to my apps when I updated the Wimp_Initialise call to say it was RISC OS 3.10 compatible and that was more recently than I would like to admit!

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

#5980

In message <fc5e9237-db2d-4050-b89d-954fefc69ffa@googlegroups.com>
 on 14 Feb 2020 svrsig  wrote:

> On Sunday, February 2, 2020 at 1:19:46 PM UTC, Matthew Phillips wrote:
> > In message <mpro.q4ztv001i3wxf02ho.news@stevefryatt.org.uk>
> >  on 31 Jan 2020 Steve Fryatt  wrote:
> > 
> 
> > > My guess is that Wimp_GetMenuState is primarily aimed at handling
> > > Message_HelpRequest, where you get provided with a window and icon
> > > handle, and the problem is working out how they relate to your
> > > application.
> > 
> > That's a very good point. I had not thought of that. I don't think I've
> > ever provided interactive help over menus, but I can see it would be
> > necessary to do this lookup.
> >  
> Shame on you. It only came in with RISC OS 3 but that was some time ago. I
> added it to my apps when I updated the Wimp_Initialise call to say it was
> RISC OS 3.10 compatible and that was more recently than I would like to
> admit!

It's really badly documented in the PRM. The documentation of the help
messages does not give you any hints as to how to give help over a menu as
far as I can see, and the documentation of Wimp_GetMenuState does not give
you any clues as to what it might be for.

Was it only announced in an app. note or something?  Perhaps I have missed
something.

We do make quite a bit of effort to be style guide compliant and to provide
interactive help over windows, but I have never had any feedback from anyone
as to whether they have found it helpful.

-- 
Matthew Phillips
Durham

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

#5987

On Friday, February 14, 2020 at 10:07:21 PM UTC, Matthew Phillips wrote:
> In message <fc5e9237-db2d-4050-b89d-954fefc69ffa@googlegroups.com>
>  on 14 Feb 2020 svrsig  wrote:

> It's really badly documented in the PRM. The documentation of the help
> messages does not give you any hints as to how to give help over a menu as
> far as I can see, and the documentation of Wimp_GetMenuState does not give
> you any clues as to what it might be for.
> 
> Was it only announced in an app. note or something?  Perhaps I have missed
> something.
> 
> We do make quite a bit of effort to be style guide compliant and to provide
> interactive help over windows, but I have never had any feedback from anyone
> as to whether they have found it helpful.
> 
> -- 
> Matthew Phillips
> Durham

I agree it is badly documented. I cheated and saw how other apps did it. Take a look at CountDn or Cat and it is fairly clear then.

[toc] | [prev] | [standalone]

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

csiph-web