[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Ups - not sent to mintlist:

Helmut Karlowski wrote:

> This is a multi-part message in MIME format. To properly display this message you need a MIME-Version 1.0 compliant Email progr
>
> ------MIME delimiter for sendEmail-960234.977611439
> Content-Type: text/plain;
>   charset=iso-8859-1
>   Content-Transfer-Encoding: quoted-printable
>
> Peter Persson wrote:
>
> >
> > 4 aug 2010 kl. 19.56 skrev Helmut Karlowski:
> >
> > > Maybe this says something to you:
> > >=20
> > >      titles =3D k->m.titles;
> > >      about =3D k->m.about;
> > >      ks =3D k->p.parent;
> > >      kc =3D k->m.current;
> > >=20
> > > ks is msg[7], kc msg[3]. I don't know what's what ...
> >
> > I have to test it to be sure.
>
> I guess these are needed for nested submenus (menu from a menu). But
> then the topmost 'parent' should point to - the window, shouldn't it?
>
>
> > > I really do not think that it's a valuable information for a client to
> > > know who sent an MN_SELECTED (who else could/would do this other than
> > > the AES?)
> >
> > Probably not :)
> >
> > Another solution would be to only allow menu bar access on topped =
> > windows. The API problem goes away, and does it really matter for the =
> > user?
>
> That would probably be the most safe solution, and maybe better for the
> user, because I cannot imagine a situation where he/she wants to open a
> menu in an untopped window.
>
> So first would be: use source-pid for handle
>
> Second: only send MN_SELECTED to the top-window, or top that window
> whose menu gets selected.
>
>
> -Helmut
>
>
>
> ------MIME delimiter for sendEmail-960234.977611439--
>


-Helmut