On Thu, May 29, 2008 at 2:34 PM, Stefan Küng <tortoisesvn_at_gmail.com> wrote:
> 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... :)
I'm glad this problem is being looked at. Thanks to Stardock for looking
into it, and thanks to Stefan for helping them out.
I don't really remember giving too many details about my system or anything
like that. I was expecting an email back with a request for more detailed
information. I like to first email about an issue (basically a summary of
the symptoms I'm experiencing). Usually I get an email back asking for
specifics that they may want, such as operating system, hardware specs, etc.
I didn't see any FAQ on Stardock's website on "How to properly submit a bug
report". In any case, it seems things are on the right track now.
Received on 2008-05-29 21:51:50 CEST