DisplayFusion RSS: Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/RSS/?TopicID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f DisplayFusion RSS: Curious Anomaly with yet Another 3rd Party Application... Mon, 13 Apr 2026 05:38:40 GMT en hourly 1 https://www.displayfusion.com/Discussions/RSS/?TopicID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f RE: Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#8 Mon, 06 Sep 2010 16:22:39 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#8 DisplayFusion 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. :) ]]> RE: Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#7 Mon, 06 Sep 2010 16:09:17 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#7 DisplayFusion
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? :-) ]]> RE: Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#6 Mon, 06 Sep 2010 15:21:40 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#6 DisplayFusion @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. :) ]]> RE: Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#5 Sat, 04 Sep 2010 15:56:40 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#5 DisplayFusion 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? ]]> RE: Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#4 Sat, 04 Sep 2010 15:33:59 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#4 DisplayFusion 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 ]]> RE: Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#3 Sat, 04 Sep 2010 07:37:57 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#3 DisplayFusion 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. :-) ]]> RE: Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#2 Sat, 04 Sep 2010 00:46:49 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f#2 DisplayFusion 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. ]]> Curious Anomaly with yet Another 3rd Party Application... https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f Fri, 03 Sep 2010 17:43:05 GMT Binary Fortress Software https://www.displayfusion.com/Discussions/View/curious-anomaly-with-yet-another-3rd-party-application/?ID=285ea4d5-cf61-4653-9deb-ba1d0de0d17f DisplayFusion 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:

http://a.imageshack.us/img838/6312/screen1a.jpg


...becomes...

http://a.imageshack.us/img838/4049/screen2jf.jpg


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... ]]>