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.

Like I said, dumb, but is does highlight a slight flaw in the compatibility routines...

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.

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.

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

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?

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?