On 6/30/06, Robert Shearman rob@codeweavers.com wrote:
Thomas Kho wrote:
On 6/30/06, Robert Shearman rob@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 handles.
Tommy