How to host an IContextMenu, part 1 - Initial foray

BlogWell » Implementing “Sent To Mail Recipient”; in your Application

BlogWell » Implementing “Sent To Mail Recipient”; in your Application — Wed, 09 Jan 2008 00:11:22 GMT

PingBack from http://blog-well.com/2007/06/05/implementing-sent-to-mail-recipient-in-your-application/

Implementing "Sent To Mail Recipient" in your Application « BlogWell

Implementing "Sent To Mail Recipient" in your Application « BlogWell — Wed, 06 Jun 2007 09:46:06 GMT

PingBack from http://blogwell.wordpress.com/2007/06/05/implementing-sent-to-mail-recipient-in-your-application/

IContextMenu のホスト方法 - Shell

社本＠ワック Blog — Wed, 22 Mar 2006 20:33:17 GMT

IContextMenu のホスト方法 - Shell

Shell Extensibility in Longhorn

notgartner.com: Mitch Denny's Blog — Wed, 13 Oct 2004 16:29:00 GMT

re: How to host an IContextMenu, part 1 - Initial foray

Mike Dunn — Tue, 21 Sep 2004 18:36:00 GMT

>Is the strategy of reading a contract from the other side successfully used on a variety of specs in real applications?

I imagine that reading the context menu shell extension spec from the other side is done often, since there are many Explorer shell replacements out there, and a file/dir context menu is a pretty big part of the shell.
Other apps like WndTabs for VC 6 do it as well (r-click a tab and you can get the Explorer context menu for a source file).

re: How to host an IContextMenu, part 1 - Initial foray

Cooney — Tue, 21 Sep 2004 13:53:00 GMT

> Is the strategy of reading a contract from the other side successfully used on a variety of specs in real applications? If not, why not? If so, does it cause the implementors endless grief, or what?

Probably not. If it were, it'd be more akin to a standard - implementations are judged by their compliance to a standard, and variations are treated as bugs in the code.

Windows is different - it is the defacto standard, and is authoritative, more so than any written spec. Variations between the code and the spec are treated as bugs in the spec (provided that someone somewhere depends on the behavior).

I think the best way to view this is to look at the docs as a starting point, and then resolve any questions by testing the code to see what it does (which is how we get bug-dependency in the first place).

re: How to host an IContextMenu, part 1 - Initial foray

name — Tue, 21 Sep 2004 03:18:00 GMT

The thing that still bugs me about reading specs from the other side is that it won't always work.

Windows's implementation has to be compatible with buggy applications, and may contain workarounds you won't think of. Or Windows may have bugs or quirks that applications depend on. Or it may handle details of a correct implementation that aren't obvious in the spec (e.g., ShellExecute expands environment strings). And when specs change, you may have to track them.

Is the strategy of reading a contract from the other side successfully used on a variety of specs in real applications? If not, why not? If so, does it cause the implementors endless grief, or what?

re: How to host an IContextMenu, part 1 - Initial foray

Raymond Chen — Tue, 21 Sep 2004 00:20:00 GMT

Um, that's what the category feeds are for.

Too much code and not enough history?

Eric TF Bat — Tue, 21 Sep 2004 00:13:00 GMT

For the benefit of the people who just want the history and the anecdotes, why not mark your articles with categories and make it possible to view entries by categories? Does the blogging software have that kind of capability?

re: How to host an IContextMenu, part 1 - Initial foray

asdf — Mon, 20 Sep 2004 23:51:00 GMT

For some more sample source code, I love ContextMenu:

http://www.maddogsw.com/cmdutils/

It even has code to parse the menu to output text instead of displaying a GUI menu.