search

maul-esel / COM-Classes

AHK classes that implement COM interfaces
39 stars 10 forks source link

TaskbarList3 example does not work correctly on Win7 64bit. #27

Closed hoppfrosch closed 12 years ago

hoppfrosch commented 12 years ago

Hello maul.esel

your latest change on TaskbarList3 (https://github.com/maul-esel/COM-Classes/commit/c3517c82512148f550260bc6f3f5c457854754d2) breaks example2 (at least on my machine):

(used for test: pre-change AHK_L 1.1 version <-> post change AHK2 version. Therefore I'm not quite sure which of the described problems already occur with pre-change AHK_2 version ...)

Can't figure it out how to fix it myself - else I did it already ....

EDIT: Initial assumption that bug was introduced with latest version seems not to be correct. The bug seems to exist since ever (using AHK2 variant on Win7 64bit OS)

hoppfrosch commented 12 years ago

As far as I can see the described bugs occur with pre-change AHK2 Version as well (reported bugs seem not to be correlated with latest changes ...)

maul-esel commented 12 years ago

v2, _L Unicode and ANSI all work well for me...

Only the first thumbbar-button contains an icon - all others are shown as borders only (i.e. no icon is shown, only border)

The first icon is from the image list, others are icons... However, I'm not sure how this could cause that problem.

Unless there should be 6 icons actually are only 5 drawn (1 real icon - and four border-only icons (it seems one border-only icon is missing))

msdn wrote:

Because there is a limited amount of space in which to display thumbnails, as well as a constantly changing number of thumbnails to display, applications are not guaranteed a specific toolbar size. If display space is low, buttons in the toolbar are truncated from right to left as needed. Therefore, an application should prioritize the commands associated with its buttons to ensure that those of highest priority are to the left and are therefore least likely to be truncated.

So this may be the reason - however I'd be strange if a change in CCF would have introduced that...

you wrote:

  • Hovering over the first (correct rendered) button almost shows up the expected tooltip (expected: "This is button #1" - actually shown: "is button #1") All other (border-only) icons do NOT show any tooltip
  • Clicking on the first icon brings up the following msgbox as expected: "The ThumbBar button with the id "1" was clicked!". Clicking on the other items also pop up a msgbox - but the shown ID is wrong: 2nd button shows id 47, 3rd button shows id 84 ...

There seem to be some strange things in memory... Are you on 64bit?

Could you be so kind and track down what specific commit has introduced this? (as far as I understood you, it appeared in v2 also before the commit you linked). You could use git bisect to find it... (some instructions)

I'll have a closer look on THUMBBUTTON.ToStructPtr() and related and report you back if I find something.

maul-esel commented 12 years ago

Tested on Win7 HP 64bit: I can confirm all 64bit-versions of AHK show the described problem.

However, I have only very limited access to that 64bit computer. Would still be good if you could check what version introduces this bug.

Edit: or _maybe_ a change in AHK was the reason.... ?

hoppfrosch commented 12 years ago

I just started using AHK2 - so I can Not say yet in which Version the described misbehaviour was introduced. I have to evaluate whether it worked with AHK2 on 64bit at all....

One remark on the fact that only 5 of 6 buttons are displayed: with AHK1.1 all 6 buttons are shown (also with 64bit OS) -therefore I dont think its a place problem...

maul-esel commented 12 years ago

with AHK1.1 all 6 buttons are shown (also with 64bit OS)

Sure? I thought it was 5, too. But this may be some more garbage in memory...

I just started using AHK2 - so I can Not say yet in which Version the described misbehaviour was introduced. I have to evaluate whether it worked with AHK2 on 64bit at all....

Could you please do a git bisect (as linked above) ? This would save us a lot of time.

hoppfrosch commented 12 years ago

Sure? I thought it was 5, too. But this may be some more garbage in memory...

Yes - I am sure. See following screenshots: Compare

Could you please do a git bisect (as linked above) ? This would save us a lot of time.

I will give it a try as soon as I have some spare time (hopefully today or tomorrow). Those bugs aren't currently a big issue for me (and apparently not for the community - since I'm the first to report it) - but I think they have to be fixed nevertheless ...

Have to learn more about git bisect first ...

hoppfrosch commented 12 years ago

Hello maul.esel

I tested on my Win764bit - using AHK 2.0-a029-6c61919 (64bit, UNICODE). I found NO version of COM-classes where the issues above do NOT occur.

The first commitid where the Taskbarlist3/example2.ahk works at all was (roughly) 2aaab9db51d7c51cf7853c044dc19a0dc8da0d6e. Even at this early stage the (2) icons show up without image (BTW: at this time the icons do not show up also with AHK 1.1 (after merging on branch AHK 1.1)) ... Older versions of example do show up syntactical errors in submodules ...

The first commitid which 6 icons to be shown is (roughly) 8f04889b6dbd8f032f5356de1750393f3526b983. This version already results in showing only 5 of 6 icons, whereupon only the first icon from imagelist is shown correctly and the remaining 4 are shown as frame only ...

CONCLUSION: I think it did'nt work ever on Win7 64bit - using AHK 2.0-a029-6c61919 (64bit, UNICODE).

maul-esel commented 12 years ago

See following screenshots: ...

Are you sure you're using AHK_L 64bit? For me, it looks like this for AHK_L 64bit: AHK_L 64bit and on AHK 2 64bit: on AHK 2 64bit - the same.

I investigated but didn't find a solution. However, I could imagine 2 possible problems:

hoppfrosch commented 12 years ago

Are you sure you're using AHK_L 64bit? For me, it looks like this for AHK_L 64bit:

AHK2 64bit - and you're right: AHK 1.1 32bit. Have to test it with AHK 1.1 64 bit as well I think. (the image I linked uses AHK2-64bit <-> AHK 1.1-32bit)

I have to more precise when describing my test environment - and sytematically test it for the most common derivates of AHK_L - unless I'm still mostly interested in AHK 1.1 32bit (as 3rd party dlls I use are mostly still 32bit ...)

BTW: How did you create inlined images in previous post? EDIT: Got it ....

maul-esel commented 12 years ago

One strange thing I noticed is that the (wrong) button IDs are always the same - 1 (correct) - 45 - 84 - 98 - 111. Is this the same for you?

hoppfrosch commented 12 years ago

As far as I remember I also saw this sequence ... I have to verify this! (I'm currently at a friend using my 32bit Windows - so I cannot test now)

maul-esel commented 12 years ago

Could you please test the newest AHK v2 version on your system? It works for me now on both 32bit and 64bit-version of AHK v2.

hoppfrosch commented 12 years ago

Latest version fixes the issue. (verified on Win7 64bit - AHK2.0-a029 64bit)

Issue closed