Processing Ajax...

Title

Message

Confirm

Confirm

Confirm

Confirm

Are you sure you want to delete this item?

Confirm

Are you sure you want to delete this item?

Confirm

Are you sure?
Save up to 50% on our desktop apps during our Year End Sale!Save up to 50% on our desktop apps during our Year End Sale, including DisplayFusion, ClipboardFusion, FileSeek, LogFusion, TrayStatus, and VoiceBot!Save up to 50% on our desktop apps during our Year End Sale!

User Image
thedailycommute
8 discussion posts
Hi, I installed Beta15 this morning without any problem, however there still seems to be an issue with the Taskbar Window Option "All taskbars show relevant windows".

Upto and including Beta 8 (v2.2.108) the "relevant windows" option would correctly remove from the standard taskbar, all icons for those windows being displayed on the second monitor (i.e. on the DF taskbar). See images DFv2.2.108 (Left).png and DFv2.2.108 (Right).png. Note that the group (automatically created by Windows) shows only the windows on the first monitor.

Somewhere between v2.2.108 and v2.2.113 this behaviour changed. When the icons on the Windows taskbar are NOT grouped, DF correctly adds/removes them as applications are switched between the different monitors. However when Windows creates a group (see images DFv2.2.115 (Left).png and DFv2.2.108 (Right).png) DF no longer removes the icon(s) of those windows on the second monitor.

While capturing the images for this post I also discovered that the old DisplayFusionHookx64.dll bug also seems to have crept back. When I tried to manually uninstall v2.2.115 in order to capture the images with v2.2.108 I was immediately informed that the DLL could not be removed, obliging me to restart before I could install the older version.

Thanks!

John
• Attachment: DFv2.2.108 (Left).png [19,430 bytes]
DFv2.2.108 (Left).png
DFv2.2.108 (Left).png
• Attachment: DFv2.2.108 (Right).png [16,967 bytes]
DFv2.2.108 (Right).png
DFv2.2.108 (Right).png
• Attachment: DFv2.2.115 (Left).png [25,632 bytes]
DFv2.2.115 (Left).png
DFv2.2.115 (Left).png
• Attachment: DFv2.2.115 (Right).png [22,304 bytes]
DFv2.2.115 (Right).png
DFv2.2.115 (Right).png
Jan 26, 2009  • #1
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
It's all very true. :) This isn't so much as a regression bug as it was a decision. In the old betas (up to Beta 8 I believe) the Windows taskbar buttons were deleted when they were shown on the DF taskbar. This hid the taskbar buttons from the grouped lists, but produced the nasty side effect that when you minimized/maximized a window the taskbar button would appear briefly back on the Windows taskbar. With Beta 15 the taskbar buttons are marked as hidden and not deleted. That way Windows doesn't try to constantly "fix" the problem by adding the buttons back again. However, it means that the buttons show up in the grouped lists. After v2.3 goes final I will be playing around with better ways to accomplish this without either side effect, but for now I thought this was the lesser of 2 evils and didn't produce the strange side effects of buttons appears and disappearing.
Jan 26, 2009  • #2
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
I should also add, that starting with DisplayFusion Beta 9 or so DisplayFusion started using a different method of polling the Windows taskbar buttons. DF started "asking" windows to enumerate all the buttons on the taskbar and send back a list of all buttons. However, this didn't work well when I was deleting the buttons, as Windows would stop reporting that button and DisplayFusion would think the application was closed. Like I said in my previous post, I'm going to be re-thinking this approached for DisplayFusion v2.4, but for now it provides good stability and only duplicated taskbar buttons in grouped lists.
Jan 26, 2009  • #3
User Image
thedailycommute
8 discussion posts
Many thanks for clearing that up!!

John
Jan 26, 2009  • #4
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
No problem. Thanks for catching that - it's great to see people scrutinizing every part of the application so closely. :)
Jan 26, 2009  • #5
John L. Galt's profile on WallpaperFusion.com
The greater the app, the greater the scrutiny, it would seem.

Next we'll all be asking for source code :lol:
I am I.
Jan 28, 2009  • #6
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
I'm always happy to share how things work behind the scenes, and my reasoning behind technical decisions. I'll stop short of posting the source code though. :)
Jan 28, 2009  • #7
Subscribe to this discussion topic using RSS
Was this helpful?  Login to Vote(-)  Login to Vote(-)