GreenReaper wrote:
>> Q: context menu icons don't show up if Windowblinds is installed
>> A: that's a bug in WindowBlinds which the company is unable to fix due
>> to lack of experienced developers and crappy support people. Even though
>> the fix would be easy and we told them how to do it, they're still not
>> able (or willing) to fix this. Please complain to their support, not
>> ours as we have done everything we could.
>>
>> :)
>
> With all due respect to the original poster, they did not state the
> operating system they were using (XP), nor that they were using the
> unreleased RC 1.5 version of TortoiseSVN. Due to the way in which
> TortoiseSVN's code is structured, the bug is not evident on Vista, and
> the code concerned is not in 1.4.8. I am not the WindowBlinds
> developer and I do not know exactly how far they went in trying to
> debug this problem, but if they had tried it with the information they
> were given, it is unlikely that they would have seen it.
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 notice your icon handling code has also been completely overhauled
> since 1.4.x:
> http://tortoisesvn.tigris.org/svn/tortoisesvn/branches/1.4.x/src/TortoiseShell/ContextMenu.cpp
> http://tortoisesvn.tigris.org/svn/tortoisesvn/trunk/src/TortoiseShell/ContextMenu.cpp
> I understand patches were contributed by Adam Strzelecki.
yes, but what has a complete rewrite to do with this? The rewrite was
necessary because of Vista.
> Have you tried stepping through CShellExt::HandleMenuMsg2 with
> WindowBlinds loaded to see that the expectations of the code are being
> met - or that this code is being called at all? It seems like that
> would be a reasonable step to take on your end, rather than guessing
> about whether it does. It would also be possible for you to see if
> different figures are passed for the fields of MEASUREITEMSTRUCT/
> DRAWITEMSTRUCT in the skinned and unskinned cases.
>
> The TortoiseSVN handlers for WM_MEASUREITEM and WM_DRAWITEM are much
> shorter than they used to be, and I wonder if they have all that is
> required. For example, WM_MEASUREITEM seems to be assuming that
> increasing the current width of the item by two is sufficient.
> Conversely, in 1.4.x code, it is set to "width of string + height of
> string (~ width of icon) + space between".
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.
> As stated in http://www.nanoant.com/programming/themed-menus-icons-a-complete-vista-xp-solution
> the HBMMENU_CALLBACK path for the code now in 1.5 does not work all
> that well on 2000, cutting off all the text (hence it is only used for
> XP). I have to wonder whether this is, as he states, "obviously a bug
> of Windows 2000 shell.dll". If the width of the item is not explicitly
> set but assumed to be "some value + 2", it seems like that would
> naturally remove most or all of the text if 0 is passed.
>
> Now, the problem may well still be in WindowBlinds. The above is just
> an example of an assumption that would be worth checking before
> blaming us. We have seen a lot of situations where code simply "happen
> to work" - perhaps a return parameter is not checked, or a complete
> drawing area is used rather than the one specified. Naturally, if it
> fails to happen to work when WindowBlinds is loaded, the fault is then
> seen as ours . . .
>
> A skin that demonstrates this problem is Vector-Cell, which can be
> downloaded at http://www.wincustomize.com/skins.aspx?skinid=4350&libid=1
Since I really don't want to install WindowBlinds on my dev machine,
I've set up a virtual machine to test this (took me several hours,
because I also had to install the whole dev stuff).
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... ;)
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...
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
Received on 2008-05-24 17:48:50 CEST