[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Context Menu icons do not display with WindowBlinds

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Thu, 29 May 2008 21:34:32 +0200

GreenReaper wrote:
> (Apologies for not replying earlier, I was away on holiday)
>
>> I'm not sure where you got that information from? In the original thread
>> there is no indication at all what information Robert sent to the
>> WindowBlinds guys, so how do you know they didn't get all the
>> information they need?
>
> I'm not the WindowBlinds developer, but I do work for Stardock. I've
> read the support ticket on our side. There was no indication that the
> user was using non-release versions, nor did the thread above give the
> suggestion that anything was different from 1.4.x which might have
> prompted them to tell us (ideally, they would have told us anyway, of
> course . . . but the world is not ideal).

Sorry about that. I thought the user who reported this to you would have
included that information.

>>> I notice your icon handling code has also been completely overhauled
>>> since 1.4.x:
>> yes, but what has a complete rewrite to do with this? The rewrite was
>> necessary because of Vista.
>
> Correct . . . but as we can see it also affected something on XP.

Well, it works properly on XP too, at least if Windows itself is
handling the menu :)

> My point was that the context menu handling code having changed
> recently was something that would have been useful to mention. We use
> TortoiseSVN ourselves and it was not showing up, exactly because it
> was not in "released" code. I had to guess that something had changed
> recently, and go and look at it.

Again, sorry about that. I would have reported it myself, but since I
have not bought WindowBlinds I figured that my report would not get
looked at - I have some bad experience with user support.

>> There's a difference between the 1.4.x code and the 1.5 code:
>> in 1.4.x, the *whole* menu item was ownerdrawn. That's why we had to do
>> a lot more calculations to get the required rectangle for our menu items
>> (fonts, string widths, icon sizes, ...).
>> In 1.5, only the *icon* is ownerdrawn. The rest of the menu item must be
>> drawn by the owner of the menu window. That's why we don't have to
>> calculate the rectangle size so complicated.
>
> OK. I did understand that the text was not meant to be drawn in this
> situation, I was just not sure that all of the cut measurements or DC
> handling were truly unnecessary (especially the assumption that adding
> 2 to the value currently in the structure was sufficient). If you have
> evaluated it and believe this to be OK, then that is fine.

As far as I understand the docs, the menu handler passes a minimum value
it reserves for the menu icons there. The extensions then can adjust
that values.
The explorer however passes 0 there because it ignores custom icon
sizes. All icons in an explorer menu have the same size (the system icon
size). We only add 2 pixels there for some other explorer extensions
which change the menus to have custom icon sizes to make sure that our
icons don't get resized to a smaller value.
Come to think of it, we should maybe not add 2 there but set the fixed
value of our icon size there...

>> Now, even though I was sure that this is a WindowBlinds problem, I've
>> tried to debug the problem. I wonder if I could charge them for my
>> work... ;)
>
> You could try, but would you really want to be paid in worthless
> American dollars? ;-)

I take what I can get :)

>> First some information you should know:
>> * on XP, the styling/theming is active as long as you don't have the
>> 'old' win2k look activated. So styling/theming was never the problem.
>> Otherwise the icons would have never shown up for the default XP theme
>> either.
>> * there are two different ownerdraw states of menu items: the whole menu
>> item or just the menu icon.
>>
>> What XP does (correctly):
>> * call the shell extension with WM_MEASUREITEM to get the required size
>> of the icon to draw
>> * WM_MEASUREITEM is *not* called for the whole menu item
>> * call the shell extension with WM_DRAWITEM to have the icon drawn
>> * shows the menu
>>
>> And here's what WindowBlinds does:
>> * call the shell extension with WM_MEASUREITEM, but it seems it calls to
>> get the required size for the whole menu item
>> * WM_MEASUREITEM is not called for just the icon
>> * it does *not* call the shell extension with WM_DRAWITEM to have the
>> icon drawn
>> * but it calls the shell extension with WM_DRAWITEM to redraw the whole
>> menu item when the menu state changes (active/mouse over, inactive),
>> which is just plain wrong!
>> * after calling WM_DRAWITEM, it actually *overwrites* the ownerdrawn
>> menu with its own drawing before showing the menu.
>>
>> The last point is only half wrong: it should do that because our menu
>> item is only 'icon ownerdrawn' so it *has* to overpaint our own drawing
>> with the menu text (which we don't draw ourselves). But apparently it
>> also overwrites the part where the icon is located, so even though we
>> draw our icon in that case, it never shows up because WindowBlinds
>> paints over it...
>
> Thank you for that detailed walkthrough. I will ask the WindowBlinds
> developer read your post and see if it is possible to improve our
> handling of this situation.

Feel free to contact me if you need more information.

If I had to guess what you're doing wrong I'd say that if the menu item
is not set as ownerdrawn, that you then assume that the icon is also not
ownerdrawn. But that assumption is wrong if the icon is set as
HBMMENU_CALLBACK. If the icon handle is set as HBMMENU_CALLBACK, then
the icon is ownerdrawn and the WM_DRAWITEM message must be sent to the
context menu handler to have it draw the icon.

One problem that WindowBlinds could have with this is that I'm sure that
some context menu handlers don't draw their icons 'transparent', i.e.
independent of the menu background color (TSVN draws them correct). And
that would then lead to very ugly menus (I noticed that WindowBlinds
also changes the menu background). I guess to avoid that you'd have to
do a lot more work (find pixels with the default menu color, then
'remove' those so the WindowBlinds background can shine through).
But I guess that's not something I have to think about... :)

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net

Received on 2008-05-29 21:34:52 CEST

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.