#286 BUGGY 7zFM MENU: THE RETURN

[Anonymous]

Reviewing 4.10b sources, I noticed that my little tips
about using MIIM_STRING and MIIM_FTYPE were
considered (class CInit_fMask was introduced in
MyLoadMenu.cpp).

BUT THE 7zFM DOES NOT WORK AS EXPECTED ANYWAY
(that's why I asked about my mini-patches
somewhere)!!!

So, trying to build FileManager from sources, I
discovered the following:

1) when compiling MyLoadMenu.cpp (VC98, NT4 SP6,
Windows 2000 SDK), compiler stopped because
MIIM_STRING and MIIM_FTYPE weren't defined: so I
defined them myself in file MyLoadMenu.cpp. At this
point, compilation succeeded and resulting binary worked
fine!

2) I retried compilation removing my MIIM_* definitions
from MyLoadMenu.cpp and setting
_WIN32_WINNT=0x0500 and WINVER=0x0500 in
STDAFX.H (perhaps implicitly set by your compiler/SDK):
the module was built, but it didn't work right (the menu
language bug was there again). And this is the (last)
cause: all menu.GetItemInfo(i, true, &menuInfo) calls in
function MyChangeMenu ever return zero (failed
operation): so the if() test is ever false, and
menu.SetItemInfo() never reached.

Remembering warning emitted by Windows 2000 SDK
WINDOWS.H ("Caution: When building applications with
WINVER set to 0x0500 or greater, the resulting binary
may not run as expected on earlier platforms, such
Windows NT 4.0 or Windows 95 & Windows 98. -- See
the Platform SDK release notes for more information."),
the only way to make things work right seems to
explicitly set _WIN32_WINNT=0x0400 AND, MOREOVER,
WINVER=0x0400 in STDAFX.H. Obviously, manually
defining new MIIM_* stuff in MyLoadMenu.cpp AFTER all
#include lines.

Deeply analyzing the problem, I found that
GetMenuItemInfoW returns 1 in the "good" module, 0 in
the bad one: it should mean a difference (an error) in
the structure passed as input, since the same API on
the same OS can't produce different results!

In fact, the reason should be that MENUITEMINFO
contains HBITMAP hbmpItem member only if WINVER >=
0x0500 (perhaps implicitly set by your compiler/SDK)...
but, this way, cbSize contains a structure length gretaer
than the one known by previuos Windows versions!!!

...is it really necessary use of MIIM_STRING and
MIIM_FTYPE on newer Windows versions???

[Igor Pavlov]

Logged In: YES
user_id=65083

> explicitly set _WIN32_WINNT=0x0400 AND, MOREOVER,
WINVER=0x0400 in STDAFX.H.

I'll try it.

[Nobody/Anonymous]

Logged In: NO

It IS confirmed by Visual Studio debugger that WinNT 4.0
(and, probably, at least Win95) expects a
MENUITEMINFO.cbSize 4 bytes (1 DWORD) shorter.