I forgot exactly where, but passing a string as the first parameter is
permitted. That's why it's declared INT_PTR instead of INT. Tracing through
the machine code shows the high-word is checked and it is interpreted as a
string if non-zero. You can also trace through as the shell compares this
string against "pastelink", "paste", etc. And this all works fine if you
haven't called QCM. Once QCM is called, it compares the passed in verb
string to a few others before loosing your string pointer and comparing to
0xffffffff. So it sure looks like a Microsoft bug to me.
For call context, this is what I'm doing:
struct _CmdInfo
{
int nID; // Our menu ID
OLECMDID nOLE; // Standard OLECMDID (if any)
LPCTSTR pszVerb; // Standard canonical command name
bool isEnabled(IContextMenu* pCM)
{
HRESULT hr = S_FALSE;
TCHAR szHelp[128] = {0};
if(this->pszVerb && pCM){
hr =
pCM->GetCommandString(reinterpret_cast<UINT_PTR>(this->pszVerb),
GCS_HELPTEXT, NULL, reinterpret_cast<LPSTR>(szHelp),
_countof(szHelp));
}
ATLTRACE2(atlTraceUser, 0, TEXT("Cmd=%d, Name='%s', Help='%s'
(hr=%#x)\n"),
this->nID, this->pszVerb, szHelp, hr);
return (hr == S_OK);
}
};
static _CmdInfo _ItemCmds[] =
{
{ SFVIDM_FILE_DELETE, OLECMDID_DELETE,
TOCMDSTR_DELETE },
{ SFVIDM_FILE_PROPERTIES, OLECMDID_PROPERTIES, TOCMDSTR_PROPERTIES },
{ SFVIDM_EDIT_CUT, OLECMDID_CUT, TOCMDSTR_CUT },
{ SFVIDM_EDIT_COPY, OLECMDID_COPY, TOCMDSTR_COPY },
{ SFVIDM_FILE_RENAME, OLECMDID(-1), TOCMDSTR_RENAME },
{ FCIDM_PRINT, OLECMDID_PRINT, TOCMDSTR_PRINT }
};
Where TOCMDSTR_XXX are "delete", "properties", "cut", "copy", "rename" and
"print", respectively.
Ciao,
Dee
P.S. Was first attempting to use GCS_VALIDATE but that appears to be pretty
much completely broken. [surprise!]
P.P.S. The other email regarding a crash in "CTXMENU.dll" turned out to be
some sample code written in VB that nukes. The samples had installed
themselves without my knowledge and now no longer exist on my box.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Ehsan Akhgari
Sent: Wednesday, December 24, 2003 8:56 AM
To: [EMAIL PROTECTED]
Subject: RE: [msvc] CompareString nuking
duringIContextMenu::GetCommandStringcall
> I'm experiencing a very odd crash occuring deep within the
> SHELL32 code during a call to IContextMenu::GetCommandString.
> I'm calling it during handling of
> ICommDlgBrowser::OnStateChange for CDBOSC_SELCHANGE. The IContextMenu
> is for the Desktop folder with My Computer selected and the call is
> GetCommandString("delete", GCS_HELPTEXT, 0, szHelp, _countof(szHelp)).
> Tracing into the call shows that lstrcmpiW is called with ("Manage",
> "delete"); then ("find", "delete"); then ("Manage",
> 0xffffffff) [boom!].
If I'm reading the docs correctly, the first param must be a numerical menu
identifier, not a string. Also, if you're building a Unicode build, you
seem
to need to case szHelp (which should be whcar_t*) to LPSTR to make the code
compile.
Can you show a vaster call context?
-------------
Ehsan Akhgari
List Owner: [EMAIL PROTECTED]
[ Email: [EMAIL PROTECTED] ]
[ WWW: http://www.beginthread.com/Ehsan ]
It is dreadful to die of thirst in the sea. Do you have to salt your truth
so
much that it can no longer even - quench thirst?
-Beyond Good And Evil, F. W. Nietzsche
