On 6/30/06, Robert Shearman <[EMAIL PROTECTED]> wrote:
Thomas Kho wrote:
> On 6/30/06, Robert Shearman <[EMAIL PROTECTED]> 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
handles.
Tommy
