Unfortunately it seems I was wrong about it stopping the QuickTime menu corruption... it merely reduces it and changes where it appears. The changes you gave below don't seem to change that, as far as I can see, so somehow we're missing a check that Windows does somewhere.
In particular the rather confusing nature of the calls Quicktime makes doesn't help:
SetMenuItemInfoA( 0x0006025F 0 TRUE [0x0013FD04] -> 44 , MIIM_CHECKMARKS | MIIM_BITMAP | MIIM_FTYPE , MFT_BITMAP | MFT_MENUBARBREAK | MFT_OWNERDRAW | MFT_SEPARATOR , 0x00000020 , 1310100 , 0x3C0052C4 , 0x00000311 , 0x00000202 , 0x00000000 , "x H" , 4 , 0x0013FD94 ) -> FALSE
fMask -> MIIM_CHECKMARKS | MIIM_BITMAP | MIIM_FTYPE fType -> MFT_BITMAP | MFT_MENUBARBREAK | MFT_OWNERDRAW | MFT_SEPARATOR
Which other than being API violations don't make sense anyway, why would any menu in quicktime need to have a vertical break?
I think you're right in that a full test case is needed, but I can't do that (at least, not in C, if Object Pascal is acceptable I might be able to do so).
On Thu, 2003-01-16 at 01:30, Dmitry Timoshkov wrote:
"Alistair Leslie" aleslie@neumaflo.com.au wrote:
Reading about the MENUITEMINFO structure. Take from MSDN The MFT_BITMAP, MFT_SEPARATOR, and MFT_STRING values cannot be combined with one another.
In that case the code which verifies MENUITEMINFO fields could be generalized. All existing checks in SetMenuItemInfoA should be removed and something like this should be added to SetMenuItemInfo_common:
if (lpmii->fMask & MIIM_TYPE ) { if (lpmii->fType & MFT_BITMAP) { if (lpmii->fType & (MFT_SEPARATOR | MFT_STRING)) return FALSE; } else if (lpmii->fType & MFT_SEPARATOR) { if (lpmii->fType & (MFT_BITMAP | MFT_STRING)) return FALSE; } else if (lpmii->fType & MFT_STRING) { if (lpmii->fType & (MFT_BITMAP | MFT_SEPARATOR)) return FALSE; } }
Mike, could you please try this approach and report whether it helps?