Discussion:
Finding location of current menu
(too old to reply)
Matthew Phillips
2020-01-30 23:43:37 UTC
Permalink
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
druck
2020-01-31 08:10:45 UTC
Permalink
Post by Matthew Phillips
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]
Post by Matthew Phillips
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
n***@sprow.co.uk
2020-01-31 08:55:07 UTC
Permalink
Post by Matthew Phillips
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.
Matthew Phillips
2020-02-02 13:19:28 UTC
Permalink
Post by n***@sprow.co.uk
Post by Matthew Phillips
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
Alan Adams
2020-02-02 20:12:13 UTC
Permalink
Post by Matthew Phillips
Post by n***@sprow.co.uk
Post by Matthew Phillips
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
***@adamshome.org.uk
http://www.nckc.org.uk/
Steve Fryatt
2020-01-31 22:45:00 UTC
Permalink
On 30 Jan, Matthew Phillips wrote in message
Post by Matthew Phillips
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.
Post by Matthew Phillips
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/
Jean-Michel
2020-02-01 19:38:01 UTC
Permalink
Post by Steve Fryatt
On 30 Jan, Matthew Phillips wrote in message
Post by Matthew Phillips
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.
Post by Matthew Phillips
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 :***@orange.fr

RiscOS 5.23 : RiscPc/IyonixPC/Raspberry/ARMX6.
Matthew Phillips
2020-02-02 13:17:24 UTC
Permalink
Post by Steve Fryatt
On 30 Jan, Matthew Phillips wrote in message
Post by Matthew Phillips
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.
Post by Steve Fryatt
Post by Matthew Phillips
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
Terry Kelly
2020-02-02 16:45:02 UTC
Permalink
In message <***@sinenomine.freeserve.co.uk>
Matthew Phillips <***@yahoo.co.uk> wrote:
[snip]
Post by Matthew Phillips
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
Steve Fryatt
2020-02-02 19:44:23 UTC
Permalink
On 2 Feb, Terry Kelly wrote in message
Post by Terry Kelly
[snip]
Post by Matthew Phillips
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/
svrsig
2020-02-14 14:48:18 UTC
Permalink
Post by Matthew Phillips
Post by Steve Fryatt
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!
Matthew Phillips
2020-02-14 22:03:16 UTC
Permalink
Post by svrsig
Post by Matthew Phillips
Post by Steve Fryatt
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
svrsig
2020-02-19 18:45:00 UTC
Permalink
Post by Matthew Phillips
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.
Loading...