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.