Can anyone using Win 7 (32-bit) reproduce the following?
1. Start the xplorer2 process by opening an xplorer2 window. Window opens normally and focused.
2. Open another xplorer window by opening a folder from desktop or Start > Run. The new window (and all subsequent xplorer windows) open behind any other open window, including non-xplorer windows.
(Opening new windows from within xplorer2 seems to be fine.)
I skipped Vista and went straight to Windows 7 from XP, so I don't know if this is an issue specific to Win 7, my machine, or something else. Using 1.7.2.2 with folder associations enabled.
Win7 Issues with xplorer2 Window Focus
Moderators: fgagnon, nikos, Site Mods
Somehow I picture Nikos saying this with a sardonic malaised look in his eyes, as in "Don't tell me, tell Microsoft, it's their bloody beta."nikos wrote:it works fine for me on XP
Beta testing, at its essence, is only really useful if there is a cohesively understood logical base of assumptions on "how things work, and how they don't work." In this case, with Win 7 being an unknown prospect, and without full disclosure from MS to all developers, Nikos couldn't possibly be the slightest bit inspired to "somehow" make a programme compatible to an operating system which even its developers haven't certified.
Technically, I suppose reporting X2 "problems" under Win 7 could be seen as an exercise in collating "potential" issues to be looked at post hoc, but little beyond this for now.
Rather like what happens when you put the milk in the mug before the teabag and hot water. There's just something not quite right about it. But then, I'm a traditional fan of rolling my own cigarettes, so go figure.
Just an observation from the beta-jaded Smokers' Association of Spurious Human Expectations.
Nowhere did I ask a _developer_ to fix the issue, or even look into why it's happening. I'm well aware of what I got myself into when I installed a beta operating system. But is it that hard to see the point in asking for confirmation that there is, indeed, something that isn't working as expected, and that you're not alone in seeing it? What if someone had a workaround ready which didn't require developer intervention?Kilmatead wrote:Somehow I picture Nikos saying this with a sardonic malaised look in his eyes, as in "Don't tell me, tell Microsoft, it's their bloody beta."nikos wrote:it works fine for me on XP
I'd much prefer such a workaround, if it exists, being posted in this thread since we already have fgagnon confirming the issue (Thanks), but if you want to spend any more time waxing poetic about potential-issue-reporting-protocol, go ahead.
No offence was intended... mine was a more general (less tetchy) observation based upon the surprisingly wide-spread uptake of Win 7 in the ecosystem, and the general proliferation of what does/does-not work (here and other forums).
As, if I remember, one of MS's goals was to state simply "if it works on Vista, it'll work on Win 7", they've a ways to go just yet.
I'm simply surprised it's being treated as a release candidate so early, is all. Such as their proposed early end to the beta release. One suspects any work-arounds to be short-lived.
As aside from a few visual-thunks, X2 is clean and clear via Vista.
My comment really was geared towards Nikos, as when he resorts to stating the obvious, you can almost see the hackles rising, and I found that humorous. Unhelpful true, but humorous. And a potential year of it would drive anyone nuts.
I muse, it's what I do. Sorry. My days as a technocrat are long behind me.
As, if I remember, one of MS's goals was to state simply "if it works on Vista, it'll work on Win 7", they've a ways to go just yet.
I'm simply surprised it's being treated as a release candidate so early, is all. Such as their proposed early end to the beta release. One suspects any work-arounds to be short-lived.
As aside from a few visual-thunks, X2 is clean and clear via Vista.
My comment really was geared towards Nikos, as when he resorts to stating the obvious, you can almost see the hackles rising, and I found that humorous. Unhelpful true, but humorous. And a potential year of it would drive anyone nuts.
I muse, it's what I do. Sorry. My days as a technocrat are long behind me.
I only checked on win7 beta yesterday.
Today I checked and found the issue exists on Vista and XP, too.
With one instance of the corresponding version version of x2 open,
I checked and verified the behavior from Start | Run...
> with 32-bit x2 Pro v1.7.2.2 on Xp/sp3
> with x2 Lite v1.7.1.4 on Xp/sp3
> with 64-bit x2 Pro v1.7.2.2 on Vista(x64)/sp1
> with 32-bit x2 Pro v1.7.2.2 on Vista(x64)/sp1
> with x2 Lite v1.7.1.4 on Vista(x64)/sp1
In all of the above cases, the new x2 window opens at the bottom of the stack.
The above cases can be forced to always open x2 on top by adding the /P switch at the end of the command line
- - - - - - - - -
Next I checked the behavior with 32-bit x2 Pro v1.7.2.2 on Xp/sp3 with one instance of the corresponding version version of x2 open...
> from anyFolder on Desktop | open_x2
the new x2solo window opens at the bottom of the stack.
> from anyFolder in WE | open_x2
the new x2solo window opens immediately below the WE window
> from anyFolder in x2 | open_x2
the new x2solo window opens on top.
All 3 of these x2solo cases, can be forced to open on top by adding the /P switch to the x2solo command line in the registry
under HKCU\Directory\shell\open_x2\command
and under HKCU\Drive\shell\open_x2\command
Today I checked and found the issue exists on Vista and XP, too.
With one instance of the corresponding version version of x2 open,
I checked and verified the behavior from Start | Run...
> with 32-bit x2 Pro v1.7.2.2 on Xp/sp3
> with x2 Lite v1.7.1.4 on Xp/sp3
> with 64-bit x2 Pro v1.7.2.2 on Vista(x64)/sp1
> with 32-bit x2 Pro v1.7.2.2 on Vista(x64)/sp1
> with x2 Lite v1.7.1.4 on Vista(x64)/sp1
In all of the above cases, the new x2 window opens at the bottom of the stack.
The above cases can be forced to always open x2 on top by adding the /P switch at the end of the command line
- - - - - - - - -
Next I checked the behavior with 32-bit x2 Pro v1.7.2.2 on Xp/sp3 with one instance of the corresponding version version of x2 open...
> from anyFolder on Desktop | open_x2
the new x2solo window opens at the bottom of the stack.
> from anyFolder in WE | open_x2
the new x2solo window opens immediately below the WE window
> from anyFolder in x2 | open_x2
the new x2solo window opens on top.
All 3 of these x2solo cases, can be forced to open on top by adding the /P switch to the x2solo command line in the registry
under HKCU\Directory\shell\open_x2\command
and under HKCU\Drive\shell\open_x2\command
nikos,
so I wonder what might be the difference?
I am getting consistent behaviour across 3 platforms and Lite/Pro32/Pro64
I am not concerned about the starting from Start | run... case because that is not the usual way folks start x2.
But for folks who have opted for the tighter shell integration to open x2 by default for folders and the context menu, x2solo should pop to the top as you report, but which Zarkthos and I find does not happen.
Zarkthos,
so I wonder what might be the difference?
I am getting consistent behaviour across 3 platforms and Lite/Pro32/Pro64
I am not concerned about the starting from Start | run... case because that is not the usual way folks start x2.
But for folks who have opted for the tighter shell integration to open x2 by default for folders and the context menu, x2solo should pop to the top as you report, but which Zarkthos and I find does not happen.
Zarkthos,
That would be using the /P command line switch I mentioned earlier.earlier, you wrote:I'd much prefer such a workaround, if it exists, being posted in this thread
It is no x2 bug, it is no Windows bug, it is a setting.
For explaining I use XP 32 bit. You may download TweakUI 2.10. Here you will find in General -> Focus, that Windows (if left in default setting regarding this matter) has activated "Prevent applications from stealing focus"; instead the taskbar button flashes. Uncheck this and you will find, that x2 behaves as expected (without needing the /P parameter).
Starting a new instance of x2 (as done as described in OP) is an event and this setting is about how Windows reacts on events. As this setting is obviously valid for all applications this might have some site effect, if you change it durably.
TweakUI is more or less a frontend for some registry changes, similar to x2's settings editor. So there is no need having TweakUI for doing it's changes and it is absolutely imaginable, that on someones pc this setting has been changed on another way. I presume, that nikos' machine belongs to them. Because of this he does not see, what others see.
AFAIK there is no TweakUI for Vista or W7, so it is a matter for those using those Windows versions to find the relevant reg settings.
Personal site note: This again is a proof for me, that my attempt not using x2solo, but opening folders in the default layout window only in combination with bSingleWindow = 2 is the superior solution - or better said: would be, if it there would not exist the already reported bug, that bSingleWindow does not always get respected as set.
For explaining I use XP 32 bit. You may download TweakUI 2.10. Here you will find in General -> Focus, that Windows (if left in default setting regarding this matter) has activated "Prevent applications from stealing focus"; instead the taskbar button flashes. Uncheck this and you will find, that x2 behaves as expected (without needing the /P parameter).
Starting a new instance of x2 (as done as described in OP) is an event and this setting is about how Windows reacts on events. As this setting is obviously valid for all applications this might have some site effect, if you change it durably.
TweakUI is more or less a frontend for some registry changes, similar to x2's settings editor. So there is no need having TweakUI for doing it's changes and it is absolutely imaginable, that on someones pc this setting has been changed on another way. I presume, that nikos' machine belongs to them. Because of this he does not see, what others see.
AFAIK there is no TweakUI for Vista or W7, so it is a matter for those using those Windows versions to find the relevant reg settings.
Personal site note: This again is a proof for me, that my attempt not using x2solo, but opening folders in the default layout window only in combination with bSingleWindow = 2 is the superior solution - or better said: would be, if it there would not exist the already reported bug, that bSingleWindow does not always get respected as set.
Thanks for that discovery/explanation Cosmo 
I have verified that the same user-specific registry key controls this behaviour on: XP, Vista, and Windows 7.
The key is the DWORD value for
HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout
It controls whether applications not in 'focus' on the desktop can place a window on top of the desktop stack (i.e. 'in focus')
The prevent focus stealing (default) value is 30d40(hex), 200000(base10)
To permit focus-stealing, set it to zero.
Changes require a reboot to become effective for this key.
Myself, I would rather *not* permit global focus-stealing, so I will prefer the work-around to open a new process for x2solo by specifying the /P argument on the x2solo command lines invoked by the open_x2 verb.
I have verified that the same user-specific registry key controls this behaviour on: XP, Vista, and Windows 7.
The key is the DWORD value for
HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout
It controls whether applications not in 'focus' on the desktop can place a window on top of the desktop stack (i.e. 'in focus')
The prevent focus stealing (default) value is 30d40(hex), 200000(base10)
To permit focus-stealing, set it to zero.
Changes require a reboot to become effective for this key.
Myself, I would rather *not* permit global focus-stealing, so I will prefer the work-around to open a new process for x2solo by specifying the /P argument on the x2solo command lines invoked by the open_x2 verb.