[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 10/11] server: add calls to get/set menu item info
From:       "H. Verbeet" <hverbeet () gmail ! com>
Date:       2006-06-30 21:18:59
Message-ID: d658b69e0606301418p31c1f58ct4a4ea3609a0ccb4d () mail ! gmail ! com
[Download RAW message or body]

On 30/06/06, Thomas Kho <tkho@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?

> 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.
Stock objects are somewhat special, since they're not created / owned
by the current process.


[prev in list] [next in list] [prev in thread] [next in thread]