Re: [MiNT] XaAES: menus in windows - window handle?

["Helmut Karlowski" <helmut.karlowski@ish.de>]

Johan Klockars wrote:

> >> Just wait some time, when things have settled. Would you agree to do it the windows-way?
> >
> > Windows-way... which means clicking on a menu bar in the background tops the window? (I'm on OSX, can't really test the it my
> >
> > In such case - I think it should be optional. In my project, it could make sense to use e.g. edit->paste on a non-topped wind
>
> It's optional in Windows as well. At least none of my Windows machines
> top a window based on clicking anything within the window itself (they
> do top when the window border is clicked, though). Menus do get drawn
> on top of everything else on the screen, though, even if they belong
> to a window in the background (I suppose that makes sense, since it
> would be kind of difficult to see the menu items sometimes otherwise).
> This can look a bit strange if you use the keyboard to navigate the
> background menu, though.  ;-)
>
> Of course, this is not the standard behaviour under Windows, but I've
> not run into a single application that misbehaves.
> (I use a tiny (42 kbyte) utility called TXMouse to give X-like mouse
> behaviour. That is, keyboard and mouse events go to the window
> currently under the mouse cursor.)


I just tested this with keyedit in the background: It works and I think
it's pretty cool. So we definitely need both variants.


The behaviour should be controlled by the client. I'd suggest:

v1: pass window-handle not apid, don't top

v2: top window, pass apid

The client then would have to:

Set mn_keystate == 0x7f00 -> v1, else v2.

OR: use hi-byte of mode to control this.

mode&0xf >> 8 == 1 -> v1, else v2.


Drawback is that keyedit would get topped unless updated.


-Helmut