stefansundin / altdrag

:file_folder: Easily drag windows when pressing the alt key. (Windows)
https://stefansundin.github.io/altdrag/
GNU General Public License v3.0
1.44k stars 94 forks source link

AltDrag 1.1b1 conflict with 7+ Taskbar Tweaker #40

Open displayerror opened 9 years ago

displayerror commented 9 years ago

Hello, Just updated to the new 1.1b1 and it's now conflicting with 7+ Taskbar Tweaker v5.0's taskbar control. When middle clicking a taskbar item, 7+TT should close the application, instead it does nothing until AltDrag is disabled or closed. The previous version works correctly and this is on Win7 SP1 x64.

I've attached my settings/ini if it helps:

[General]
AutoFocus=0
Aero=1
InactiveScroll=0
AutoSnap=3
MDI=0
Language=en-US

[Input]
LMB=AlwaysOnTop
MMB=Move
RMB=Resize
MB4=Nothing
MB5=Nothing
Scroll=Volume
LowerWithMMB=1
Hotkeys=5B

[Blacklist]
ProcessBlacklist=DesignDoll.exe,modo.exe,BlackInk.exe
Blacklist=*|ZBrush,*|3DSMAX,*|Photoshop,*|OWL.DocumentWindow,*|illustrator,*|TaskSwitcherWnd,*|TaskSwitcherOverlayWnd,|#32770,*|TMainKeyboardForm
Snaplist=*|BaseWindow_RootWnd,*|SkinWnd,*|ChatSkinWnd,

[Advanced]
HookWindows=0
AutoRemaximize=1
FocusOnTyping=0
SnapThreshold=5
MultipleInstances=0
AlwaysElevate=1

[Performance]
Cursor=1
MoveRate=2
ResizeRate=5

[Update]
CheckOnStartup=1
Beta=1

2015-08-23_042513

Okay thank you and cheers for another release!

stefansundin commented 9 years ago

Hi.

I duplicated your settings in both AltDrag and 7+TT, but I couldn't reproduce the bug.

Can you try disabling LowerWithMMB? It's the only thing that I can think of that could change the behavior or the middle mouse button when you are not holding the hotkey.

If anyone else is encountering this, let me know.

displayerror commented 9 years ago

Setting LowerWithMMB=0 does indeed fix the problem, but I do really love sending windows to the back!

Interestingly, the checkbox in the GUI for "Lower windows by middle clicking on title bars" doesn't stick. Every time the GUI is closed it will uncheck itself (but the .ini still retains the previous enabled state).

Replacing the beta 1.1b1 hooks.dll with the old version seems to fix this, but I'm not sure how detrimental that is to the reliability of AltDrag 1.1b1 :)

stefansundin commented 9 years ago

Nice catch with the checkbox, I noticed it was behaving weird yesterday too, turns out I forgot to restore the checkbox state from the ini file. Fixed with https://github.com/stefansundin/altdrag/commit/3df50cfedb3e29b08207413ba77ecf802c0292c8.

Restoring hooks.dll will mostly restore your AltDrag to version 1.0. There was no interface change to the dll file, and basically the only thing the exe file does (besides the configuration window) is initialize the hooks inside the dll file.

I didn't change this behavior at all in the beta. The only thing I can think of now is that perhaps the order you start the two programs matter. But I just tested this and it didn't seem like it mattered.

¯_(ツ)_/¯

displayerror commented 9 years ago

Ahah, gotcha! Okay I've uninstalled 7+TT, Classic Shell Explorer, and just about everything from startup is disabled to prevent any additional hooks conflicting.

Windows 7's default middle click on a taskbar title should open a new instance of the program, but when AltDrag beta is running, it simple does nothing (the hover popup does appear though).

I'm completely baffled by this! I'm not even using fancy mouse drivers as it's just a basic USB HID device. I've tried it with various mice and a Wacom tablet, but the behavior is still the same. Short of a format, I'm not sure what else to try :)

stefansundin commented 9 years ago

So it should only matter what order the programs are started in, not what order they are installed in. But you are right that with 7+TT out of the way, the default behavior should work.

Do not format, please. :) Maybe you have another computer to test it on?

Let's try to fix this after v1.1.