On Mon, 26 Dec 2005 21:50:54 -, you wrote:
>Glancing through the patch, I see what you are trying to do, and some
>comments (and remember this is just from a glance so far)
>
>1. I'm not sure the MENU_SetItemData for the ownerdraw case is correct as it
>doesn't actually take a copy of the data
"Rein Klazes" <[EMAIL PROTECTED]> wrote:
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__ITEM macro's ( or rename them to reflect the
>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__ITEM macro's ( or rename them to reflect the true intention).
Glancing through the p
On Mon, 26 Dec 2005 10:57:04 -, 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
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> wrote:
PS While I think about it, I've also fixed another menu issue as well (bug
3095), and have attached a sample patch to the bug report which includes
this and the changes to fix and test that one, and if you have an interest
in the menu code you mi
>>The fact that you need to intorduce the txtWasAllocated flag suggests that
>>something is wrong. Also MF_OWNERDRAW certainly does not qualify as a
MF_STRING
>>alias. I'll try to play with your test case and see if I can find a better
fix.
The particular problem in the bug report was that the own
On Mon, 26 Dec 2005 16:13:10 +0800, you wrote:
>
>The fact that you need to intorduce the txtWasAllocated flag suggests that
>something is wrong. Also MF_OWNERDRAW certainly does not qualify as a MF_STRING
>alias. I'll try to play with your test case and see if I can find a better fix.
You are co
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> wrote:
In the case of ownerdraw -> string -> ownerdraw, the calls do indeed work
and keep the saved string. Debugging on windows seems to show the string is
copied and saved as well, which concurs with the rest of the patch.
The fix (rather than the te
>You don't check SetMenuItemInfo return code after the above calls and I
very
>much suspect that they fail leading to the observed results.
Well spotted, thanks!
In the one case of string -> ownerdraw you are right, and I have now
modified the tests to flag a todo where this unexpectedly works on
"Ann & Jason Edmeades" <[EMAIL PROTECTED]> wrote:
Copy and store the dwTypeData of a menu item even for a ownerdraw item, and
ensure the memory allocations/freeing occurs correctly
+/* Just change ftype to string and see what text is stored */
+memset(&info, 0x00, sizeof(info));
+
10 matches
Mail list logo
