Latest test case: Selecting "My Network Places", CompareStringW ends up being called twice:
CompareStringW(0x409, 1, "find", -1, "delete", -1) CompareStringW(0x409, 1, "find", -1, -1, -1) Note that "delete" is the string I passed as the first parameter to GetCommandString. Using the ANSI version causes an internal call to MultiByteToWideChar(). In this case the "delete" string above is NOT the pointer I passed in but a temporary. Both cases otherwise exhibit the same behavior. Looks like I'm going to need to trace through the QCM call after all (yech!) Ciao, Dee -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Dee Holtsclaw Sent: Monday, December 29, 2003 4:40 PM To: [EMAIL PROTECTED] Subject: RE: [msvc] CompareStringnukingduringIContextMenu::GetCommandStringcall I haven't had the time to trace the QCM call, don't know when I will get it either. Right now I've just commented out the QCM and the project doesn't nuke but I sacrifice the status of some of the target-specific verbs. As for the comparison procedure, the first parameter is it's own verb string being tested and the second is the string pointer I pass in. In all tests I've run, the shell compares some number of verb strings then recycles back to the first yet the second parameter ceases to be my string pointer and instead is -1 (0xffffffff). This, obviously, causes CompareStringW to toss it's cookies. The environment is Win2K SP3 and I'm building a UNICODE/MSLU version using VC6/SP5. Seems like a straight ANSI build didn't have this problem but I haven't checked that again yet. Will most likely do this within a day or two though. My goal is to use MSLU so I can have only a single build for all platforms (which isn't looking too good right now). Ciao, Dee P.S. The project has multiple interrelated DLLs. All told, it's about .5 million lines at the moment. Having 28K max baud here and at home, transmitting it wouldn't be my first choice... I'm going to try to build a small test case in a few days and I'll send that. P.P.S. About MS "bugs" -- I've filed 4 incidents myself. None have made it into MSDN (at least so far and they've had 3 years now) but, I'm told, they *are* in TechNet. All but one I had to pay for (said they were bugs and I'd get the incidents back but never did). Seems like you have to pay and pay to get any info anymore. OTOH, if Office is going down the tubes like has been reported lately, I guess they have to get income from somewhere... Also, if you have a MSDN subscription, your latest PSDK is current but if you download CD images, it's from Feburary. Had to hack the MS-download site just to get 'em too since I wasn't using IE (was at a friend's who has DSL and he won't use IE at all or let me install it myself -- beggars can't be choosers I suppose). [Anything but IE tells you to go take a hike -- didn't the DoJ tell 'em not to do that anymore?] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ehsan Akhgari Sent: Saturday, December 27, 2003 12:39 PM To: [EMAIL PROTECTED] Subject: RE: [msvc] CompareStringnukingduringIContextMenu::GetCommandStringcall > 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. OK. > 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. Now that you're already into the dirty world of assembly, how about checking out what exactly QCM( ) is doing to 'add' the new items? It must add them to a list or an array of some sort if it's going to impact the later GCS( ) calls. Maybe it's trying to interpret a param you pass into it as a string, but that seems to be just a 0xffffffff pointer? > 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. I also suggest you test it on other platforms as well. You don't mention what platform you're on, but I will be happy to test the project if you can ZIP it up in a reasonably small package for 56K dial-up. :-) If you seriously think it's an M$ bug (it's *not* likely, since they don't write any bugs - all they write are features, some way or another!), I suggest you asking this on an M$ newsgroup. The internal M$ folks read those newsgroups, and in the past I have seen numerous replies from developers working inside the VC++ compiler team or different parts of the OS. ------------- Ehsan Akhgari List Owner: [EMAIL PROTECTED] [ Email: [EMAIL PROTECTED] ] [ WWW: http://www.beginthread.com/Ehsan ] And when I saw my devil, I found him serious, thorough, profound, solemn: he was the spirit of gravity- through him all things fall. -Thus Spoke Zarathustra, F. W. Nietzsche _______________________________________________ msvc mailing list [EMAIL PROTECTED] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive. _______________________________________________ msvc mailing list [EMAIL PROTECTED] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
