How to host an IContextMenu, part 1 - Initial foray

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

Moi — Mon, 20 Sep 2004 14:17:00 GMT

Nice article, but it shouldn't be needed. The MSDN documentation really shouldn't require people to "read the contract from the other side". I can only assume that the people who write the documentation think that everyone still uses RPN calculators.

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

Raymond Chen — Mon, 20 Sep 2004 15:19:00 GMT

All interfaces can be read from both sides. Most people focus on the implementation side, but there's also the consumer side.

How are you suggesting that the documentation should be changed? Should every interface say, "You can either implement or call this interface"?

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

Andy — Mon, 20 Sep 2004 16:33:00 GMT

MS programming docs are interesting. Some authors seem to write "cookbook" style. There is useful info in the remarks section and sometimes a link to sample code.

Others are far more dictionary style. A terse description of the function or API with almost no clue as to how to use it to get useful work done.

The latter requires reading between the lines and from the other side. Too much extrapolation in my opinion.

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

Raymond Chen — Mon, 20 Sep 2004 16:36:00 GMT

I prefer the dictionary style myself. I think it has to do with which half of the brain you think with.

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

Jeff Parker — Mon, 20 Sep 2004 17:00:00 GMT

A quick question in this 11 part series will you be demonstrating the .net implementations?

System.Windows.Forms.ContextMenu

Just curious, but don't let me disuade you from where you are going. I just haven't used C++ in at least 3 years since C# came out. And yeah I know there are other .net blogs but none of them compair to the Raymond and Larry Blogs for in depth detail and knowledge.

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

Simon Cooke [exMSFT] — Mon, 20 Sep 2004 17:03:00 GMT

Raymond: Dictionary style only works if you have extensive sample code, the source code of the API implementation, or a large number of reference books to work from.

That's the thing about Index knowledge; it lets you find what you're looking for. It doesn't, however, teach concepts or ideas.

For an example of an API which desperately needs better sample code and some extensive real-world examples, see Uniscribe. While Uniscribe straddles the line between cookbook and dictionary in its documentation, it still leaves lots of questions regarding best practices et al unanswered.

I guess what it all boils down to is this:
Dictionary-style doco is best when one already knows the subject at hand. Cookbook style is best when one needs to learn the subject. Good documentation includes both.

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

Raymond Chen — Mon, 20 Sep 2004 17:37:00 GMT

I know zero about Windows Forms.

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

mschaef — Mon, 20 Sep 2004 17:49:00 GMT

The thing that bothers me about reading the documentation "from the other side", is that that's basically what Microsoft has to do to implement the Windows API in the first place. Given all the trouble that Microsoft has had ensuring compatibility over the years, that doesn't give me much confidence in my own ability to produce a reasonable context menu host (or whatever). Obviously, ISV software doesn't have quite the same compatibility requirements as Windows itself, but given the lower resources most ISV's can bring to bear on the problem, implementing the API from the other side seems like it might be a fairly costly move.

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

Michel van Kessel — Mon, 20 Sep 2004 22:06:00 GMT

I know zero too about Windows Forms!

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

Wilfried Wieser — Mon, 20 Sep 2004 23:19:00 GMT

The MSDN documentation for most standard interfaces honors both sides by having "When to Implement", "When to Use", "Notes to Callers" and "Notes to Implementers" sections.

Most interfaces, however, either have just a few implementors or they have just a few callers. The one more exclusive side of an interface becomes "the other side" of that interface. This side is harder to join because everybody tests against the few well known instances of this side. If somebody implements IContextMenu, he or she will most likely only test against the Windows Shell, despite the fact that "Context Menu" is a quite general term. If the code runs successfully in the shell, it is considered correct.

This has been a major problem for unmanaged component software.

In [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ShellCompatibility\Objects] there are strange flags like "CTXMENU_LIMITEDQI", indicating that there are implementations of IContextMenu which may even get a menu host in trouble if he QI's the object differently than a previous version of the shell.

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.

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

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

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

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

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

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).

Shell Extensibility in Longhorn

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

IContextMenu のホスト方法 - Shell

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

IContextMenu のホスト方法 - Shell

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/

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/