Wimp menu handling oddity

While getting scrollwheel support for menus working last night, I discovered that (because menu windows are created and owned by the Wimp), the Wimp intercepts any Open_Window or Close_Window messages that programs try and send to them. Close_Window messages are accepted and acted upon, but Open_Window messages are rejected unless the request came from the Wimp itself. So it’s not possible to scroll a menu (or move it around the screen) by using Open_Window messages. This code seems to have been around as far back as Git goes (3.60)

But, one of the changes the nested Wimp introduced was the ability to directly open/move windows which belong to other tasks, by using SWI Wimp_OpenWindow. That call skips the “did it come from the Wimp?” check, and works fine when moving menus. So for the WindowScroll module I’m currently using the approach of checking to see if the window is a menu (by checking sending a null message to the window and seeing if the returned task handle is the magic &706d6957 ‘Wimp’ value), and using that to decide whether the OpenWindow SWI or message should be used. A bit nasty, but it gets the job done.

Any reason not to always use SWI Wimp_OpenWindow now?

In the general case, Open_Window messages are preferred, because it allows the app to make sure any panes associated with the window are kept up-to-date. But since all I’m doing is adjusting the scroll offsets, maybe going straight to the OpenWindow SWI would be acceptable.

Ah. I naively thought that SWI Wimp_OpenWindow would generate an Open_Window_Request message if needed to inform an app that someone else had moved/scrolled one of its windows for just such a reason!

I’m not sure – maybe it does send a message. I’ll check.

PipeDream and Fireworkz predate, and do not make use of, the nested Wimp features so have to manage their own pane stacks on top of a containing window.

This could be most noticeable in Fireworkz with window ‘splits’ active. With both horizontal and vertical windows splits active there are four panes in each view showing document content – one with no scroll bars at the top left, one with a vertical scroll bar at the top right, one with a horizontal scroll bar at the bottom left and one with both scroll bars at the bottom right. Code tries to keep panes scroll offsets appropriately synced.

So if the Wimp didn’t generate a message when processing SWI Wimp_OpenWindow from another task, things would go a wee bit awry. They may do already!

Can confirm: SWI Wimp_OpenWindow for another task’s window doesn’t generate an Open_Window message, and can easily confuse the target task.

Oh dear! ’Tis of somewhat limited use then… Thanks for investigating.