On Mon, 26 Dec 2005 10:57:04 -0000, you wrote: >>You are correct. The real problem is that the text field should not be >>used anymore for bitmaps handles after the hbmpItem field was added just >>for that. This is proven by the fact that strings cannot only be >>combined with owner draw menu, but also with bitmaps and even >>separators. > >Hmmm... As was found from the tests once I checked the rc, you cant convert >a string type to a bitmap type directly, although I didn't test adding a >valid bitmap handle. My tests haven't proved (or attempted to prove) whether >you can have a string attached to a bitmap type, but reading the MSDN it >states that a menuitem which is a bitmap has the low-order word of the >dwTypeData member as the bitmap handle, and hence implies you couldn't have >an associated text (as that is normally pointed to via the same field). >However, since Windows also copies the value, they too may have the >equivalent of the internal 'text' field which may or may not get cleared, so >perhaps this is wrong. It was outside the scope of what I was trying to fix.
This what I think that is happening, also including a MF_BITMAP flag to
the fFlags field if for backward compatibility it is needed.
>>I am too busy celebrating vacation atm, but I hope to send in a patch
>>with extensive tests somewhere tomorrow or so.
>
>Sure, thanks - I'll watch out for it.
I attach it here now (bzip2'ed for once because of its size). Before
submitting to wine-patches, I need some time to review the code once
more for remnants of old way of thinking and to get rid of the
IS_xxxx_ITEM macro's ( or rename them to reflect the true intention).
> Can you make sure you incorporate the
>specific tests for the bug report in it too please.
You tests from 4004.patch2 are included. I just removed the todo_wine{}
which is a probably a good sign.
Rein.
menu-textistext.diff.bz2
Description: Binary data
