On 11/15/05, Hendrik Wiese <mailinglist@syncro-community.de> wrote:
> I think, I have to start over from another direction... whoo... it's
> complicated... One step of our code tries to retrieve the text of the
> menu item by calling a function called "CMenu::GetMenuString". For all
> TortoiseSVN items but the one for the popup menu, the strings returned
> by this function are empty.
True, but only if ownerdrawn menus are active. You can disable that in
the TSVN settings dialog if you want to.
> Another step of our code tries to retrieve the menu state by a function
> called "CMenu::GetMenuState". The state returned is MF_OWNERDRAW
> (MF_APPEND) but we don't know how to draw this item. We would draw it by
> ourselves if we had got a valid item text from GetMenuString.
You can't draw it yourself! That's the whole idea of *owner*draw. For
example, there are shell extensions out there which provide a
thumbnail view of files instead of a menu text.
The IContextMenu3 interface contains the method HandleMenuMsg2 which
you have to use in that case. You must first call that method with
WM_MEASUREITEM to ask the shell extension how much space it needs to
draw itself, and then with WM_DRAWITEM to have the extension actually
draw itself.
> In just another step of our code we try to append the whole TortoiseSVN
> popup menu to our menu by calling "CMenu::AppendMenu" with the handle
> returned by an earlier call of "CMenu::Detach()". The handle returned by
> Detach seems to be valid, but it appears to be unknown by the system
> since trying to pop the menu up in the GUI results in an ASSERT_VALID
> forcing our software to exit. Maybe this is depending on the OWNERDRAW
> state.
Wrong! *You* must create the menu which then the shell extensions use
to add items there. The shell extensions don't create menus themselves
(apart from submenus of course, but those still need a valid top
menu).
> Please excuse my english, I hope you are able to understand what I'm
> talking about... The least we need is a valid menu text returned by
> CMenu::GetMenuString or by IContextMenu::GetCommandString that will be
> displayed to the user and valid handles for the popupmenuitems returned
> by CMenu::Detach().
As I said: you won't get any menu text returned by any shell extension
that uses ownerdrawn menu's. And don't use CMenu::GetMenuString(),
since it's undefined what you get there if the menu is ownerdrawn
(it's not necessarily an empty string, you could get any garbage
there!).
Shell extensions implement IContextMenu, those which can handle
ownerdraw menus implement IContextMenu3 (IContextMenu2 is also
defined, but *never* called by explorer, so most extensions either
ignore IContextMenu2 or simply pass it on to IContextMenu3).
Also, since you're dealing with extensions not necessarily written for
your program, *always* check for return values like E_NOTIMPLEMENTED!
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Nov 15 11:20:49 2005