Processing Ajax...

Title
Close Dialog

Message

Confirm
Close Dialog

Confirm
Close Dialog

Curious Anomaly with yet Another 3rd Party Application...

User Image
Kilmatead
44 discussion posts
This is rather inconsequential in the bigger picture, but having discovered it by accident I thought I'd report it anyway.

I use a free utility called http://classicshell.sourceforge.net/features.html which conveniently adds the old XP-style expanding Programs-menus to the Win7 start menu. (Well, ok, it replaces the whole of the start menu itself with a more configurable one, but you get the idea - more things running constantly in the background.)

As DF has the (endlessly useful) Middle-Mouse-Click on the title-bar to send that window to another monitor, it seems to interpret the small sub-windows from CS as "real" windows - even though they have no true title-bar (for once, the DF buttons don't "mysteriously" float or otherwise appear, as is proper).

However, if one happens to middle-click at the top of one of these child windows, it gets anomalously zipped off to the other LCD, as such:



...becomes...



Naturally the first port of call in DF is Compatibility settings, wherein one unchecks "Allow middle-click window moving with this application" - except that doesn't work. For some reason it continues to happen. So, just for sport, one unchecks all the compatibility options, "just in case". Nada.

What does work, however, is checking the "Pause Global Application Hooks" options. Except, as Classic Shell is always running in the background, that means DF's Application Hooks would be disabled all the time, which is impractical.

So, the simple question is, why doesn't disallowing "middle-click window moving" seem to apply?

To underscore just how meaningless this issue is (asteroids hitting the earth, famines, and chocolate ice-cream being obviously more important issues), there is no reason during normal use of CS to ever middle-click on one of its menus. No reason at all.

But, humans being humans, now that I discovered it happens, it's like instinctively reaching for a cigarette when you know you've just quit. My mouse just can't resist it. :-D

Like I said, dumb, but is does highlight a slight flaw in the compatibility routines...
Sep 3, 2010  • #1
User Image
Kevin F.
450 discussion posts
Betting its on the process. how do you know what subroutine to set the compatibility too? I an willing to bet that any program you run to get that feature isn't the process doing the menus themselves.
Sep 4, 2010  • #2
User Image
Kilmatead
44 discussion posts
True, but as DF is aware enough not to try to add the title-bar buttons, it's not a huge leap and bound to think it could ignore "the other". Of course one could assume it's not aware of said windows... except obviously it is, if the middle-click unexpectedly works.

CS is, at the end of the day, Open Source, so there's no devil in the details. Might be a hobgoblin or two, but no real devil. :-)
Sep 4, 2010  • #3
User Image
Kevin F.
450 discussion posts
I think your confusing DF seeing "not a window" with "no windows title bar buttons". MOST nonstandard titlebar setups do not get he DF buttons. lacking a title bar, is nonstandard :D
Sep 4, 2010  • #4
User Image
Kilmatead
44 discussion posts
Not using too many applications (any - aside from CS?) that regularly commit to use "non-standard" transient modal panels, I can't say I paid much attention to DF's handling of them. Do they regularly still answer to the middle-click relocation?
Sep 4, 2010  • #5
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
@Kilmatead: I have found the problem and corrected this in DisplayFusion. The reason the Compatibility option didn't work is that the classic start menu is actually hijacking and running under the "explorer.exe" process, not it's own. If you added a Compatibility option for "explorer.exe" it would have prevented this. What I did to fix this issue was just instruct DisplayFusion to ignore the classic start menu windows, even when running under different processes. Look for Beta 12 coming out later today. :)
Sep 6, 2010  • #6
User Image
Kilmatead
44 discussion posts
Quote:
What I did to fix this issue was just instruct DisplayFusion to ignore the classic start menu windows, even when running under different processes.


Cheers - wasn't really expecting a specific "fix" per se, as it was just a harmless quirk - however, I'm not complaining - so thanks!

In the wider scheme of things, wouldn't it have made (more logical) sense to tie the middle-click shunt to the same conditions wherein DF determines whether or not to grant title-bar buttons? Theoretically, if DF doesn't provide buttons for any given window (based on however this is already determined), one probably would expect DF to relinquish all controls, including shunting, under the same conditions - no?

That way instead of overpopulating the code with exceptions for every wacky 3rd party toy out there (ad infinitum so says the future), you get an overall consistency of (reasonable) behaviour that avoids future complaints from the great unwashed about application ?

Or am I just oversimplifying, and should rather just take my fix and shoot-up with the other junkies behind the old gunpowder-mill, leaving you to the serious business of conquering the multi-LCD market? :-)
Sep 6, 2010  • #7
Jon Tackabury (BFS)'s profile on WallpaperFusion.com
The TitleBar Buttons are much more restricted, but that's an excellent idea. :) The TitleBar Buttons can't be added to tool windows, or windows that are too narrow where they wouldn't fit, along with a couple of other scenarios where you would still want to be able to use the middle-click to move. Unfortunately for these one-off applications I just need to add a quick exception to the hard-coded list and voila, fixed. :)
Sep 6, 2010  • #8
Was this helpful?  Login to Vote(-)  Login to Vote(-)