2020-01-30 23:43:37 UTC
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.