[PATCH 10/11] server: add calls to get/set menu item info

H. Verbeet hverbeet at gmail.com
Thu Jul 6 02:53:01 CDT 2006


On 06/07/06, Thomas Kho <tkho at ucla.edu> wrote:
> On 6/30/06, H. Verbeet <hverbeet at gmail.com> wrote:
> > On 30/06/06, Thomas Kho <tkho at ucla.edu> wrote:
> > > I'm not 100% clear what the problem is. My interpretation of your
> > > first email was that there was a necessary distinction in type between
> > > user/gdi handles as stored in the server, but now my understanding is
> > > that you're concerned gdi objects in MENUITEM/MENUITEMINFO should not
> > > be mutable by external processes. Is that right?
> > The basic problem is that if you create a HBITMAP in one process, then
> > pass the handle to another process, you can't read the contents of the
> > bitmap in that other process.
> >
> > So suppose you create a menu item in one process and set a custom
> > bitmap on the menu item. Should the menu then display correctly in
> > another process if you pass it the menu handle?
>
> This is a case that isn't clearly defined by MSDN and seems to have
> buggy behavior in practice. I tried just this and found that nested
> popups were drawn intact except for missing bitmaps (as expected for
> gdi objects). Windows even lets you set a top-level-menu in one app to
> a menu item's popup menu in another app, which happens to mess up the
> drawing of the original top-level-menu.
I guess that means Windows does store the handle rather than its contents.

> Your original critique was that GDI objects aren't user handles, and
> Rob suggested I create a gdi_handle_t in the server to correctly type
> the gdi handles that need to be stored on the server but are
> meaningless unless in the context of the process that created the gdi
> object. I understand that much. Is there something else I'm missing
> that needs to be addressed?
I only looked over the patches briefly, but the bitmap handles kinda jumped out.



More information about the wine-devel mailing list