[PATCH 10/11] server: add calls to get/set menu item info
tkho at ucla.edu
Fri Jun 30 15:15:49 CDT 2006
On 6/30/06, Robert Shearman <rob at codeweavers.com> wrote:
> Thomas Kho wrote:
> > On 6/30/06, Robert Shearman <rob at codeweavers.com> wrote:
> >> Thomas, can you regenerate this patch using "void *" for bmpitem (or
> >> perhaps add a new gdi_handle_t type)?
> > I'll add the gdi_handle_t type and resubmit two patches (I caught
> > another use in the menu struct).
> As others have said, GDI objects are not shared between processes. GDI
> objects are DCs, regions, bitmaps, palettes, fonts, and brushes. I
> assumed that they were shared, because icons are shared, but they are a
> user32 object.
> You'll have to write a test to see whether Windows allows you to
> retrieve and use the bitmap for a menu from another process.
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?
I did some probing and was able to change the values of the four gdi
objects (MENUINFO.hbrBack, and bitmap, (un-)check bitmaps in
MENUITEMINFO) from an external process. Specifically, I changed the
brush to one returned by GetStockObject(WHITE_BRUSH), changed the
bitmap to one of the predefined handles, and set (un-)check bitmaps to
an invalid value that was correctly returned upon a GetMenuItemInfo
query. So, I think regardless of the scope of gdi objects, it's the
right behavior for the menu code to blindly set and get the gdi
More information about the wine-devel