[C#] shell extension : IContextMenu.GetCommandString
i am looking into the SDK\v1.1\Technologies\Interop\Applications\ShellCmd which come with VS.Net 2003 (guess, me copy it somewhere from internet)
the sample work well except the IContextMenu.GetCommandString,
it should show the description on the Explorer statusbar, but it not.
me have try to add MessageBox.Show() to check whether it have fired or not, and it fire when me rollover the menuitem.
me running Windows XP SP2
is there any idea to make it work?
:: code copy from the sample ::
void IContextMenu.GetCommandString(int idCmd, uint uFlags, int pwReserved, StringBuilder commandString, int cchMax) {
switch(uFlags) {
case (uint)GCS.VERB:
commandString = new StringBuilder(m_items[idCmd - 1].command.Substring(1, cchMax - 1));
break;
case (uint)GCS.HELPTEXT:
commandString = new StringBuilder(m_items[idCmd - 1].command.Substring(1, cchMax));
break;
case (uint)GCS.VALIDATE:
break;
}
}
[1014 byte] By [
tlc660] at [2007-12-27]
 tlc660 wrote: |
- me thought the framework are previous version compatibled?
- if only one framework can be loaded, that also mean me cant use difference version of .Net application at same time?like Paint.Net build with 1.1 and Note.Net build with 2.0, thay cannot run at same time?
- when we install .Net Framework 2.0, it will installed 1.1 as well?
- just wonder why this serious problem exist and the SDK still included the shell extensions sample?
- will .Net 3.0 fixed this problem?
|
|
1: They mostly are, but they can't be forwards compatible. If Explorer happens to load the v1.0 CLR first, any extension that depends on v2.0 would fail to load.
2: No, the restriction is just one version of the CLR per process. Different applications can use different versions.
3: No
4: Don't know, good question.
5: No it doesn't.
1: Probably, but if you're an extension or add-in, you're not in control of which runtime version gets loaded.
2: You can configure Explorer to run as a single or as multiple processes. That doesn't really matter though. Each process loads its own version of the CLR. And separate copies of any shell extensions get loaded into each process.
3: If you're in control of the machines the software it will run on, that may work. But in general you're just postponing the problem. The same issue will occur again when the next version of the CLR is released and you try to load any components compiled with that.
5: I'm not sure this is something that can be fixed. It's an architectural decision made early in the design of the CLR.
2. you mean by modify the register setting [DesktopProcess]? when this options are on, so the problem will gone?
3. yes, just postponing. but me guess there will not be a problem, because in future Vista are included the .Net 3.0 right? so there are no need v1/v2
2: I mean the "Launch folder windows in a separate process" option you can set in Explorer's Folder Option dialog. That may correspond to the registry key you mentioned, I don't know. Bu no, that doesn't fix the problem.
3: Until .NET 4.0 or whatever comes along.
2. i see, then the only option are going to C++
.
3. hope it not come so soon
me have an idea:
if me create a COM with unmanaged c++ which just handle the shell extension command
like IShellExtInit, IContextMenu
and then pass the parameters receive to managed COM and let the managed COM to process, will it work?
me dont know c++, but me saw an article that mention c++ and ATL and the ATL can auto generated the SimpleExt class, so it might help.
