Win7 Issues with xplorer2 Window Focus

Discussion & Support for xplorer² professional

Moderators: fgagnon, nikos, Site Mods

Zarkthos
New Member
Posts: 4
Joined: 2009 Feb 01, 03:49

Win7 Issues with xplorer2 Window Focus

Post by Zarkthos » 2009 Feb 01, 04:20

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.

User avatar
fgagnon
Site Admin
Site Admin
Posts: 3737
Joined: 2003 Sep 08, 19:56
Location: Springfield

Post by fgagnon » 2009 Feb 01, 14:04

confirmed.

[64-bit x2 v1.7.2.1 on 64-bit win7 beta build 7000]

User avatar
nikos
Site Admin
Site Admin
Posts: 14705
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Post by nikos » 2009 Feb 02, 06:21

it works fine for me on XP

Zarkthos
New Member
Posts: 4
Joined: 2009 Feb 01, 03:49

Post by Zarkthos » 2009 Feb 02, 10:43

It worked fine for me when I used XP too, which is why I decided to post. I'm forcing myself to use tabbed view for now.

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Post by Kilmatead » 2009 Feb 02, 12:01

nikos wrote:it works fine for me on XP
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."

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.

Zarkthos
New Member
Posts: 4
Joined: 2009 Feb 01, 03:49

Post by Zarkthos » 2009 Feb 02, 13:08

Kilmatead wrote:
nikos wrote:it works fine for me on XP
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."
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?

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.

Kilmatead
Platinum Member
Platinum Member
Posts: 4569
Joined: 2008 Sep 30, 06:52
Location: Dublin

Post by Kilmatead » 2009 Feb 02, 15:43

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.

User avatar
fgagnon
Site Admin
Site Admin
Posts: 3737
Joined: 2003 Sep 08, 19:56
Location: Springfield

Post by fgagnon » 2009 Feb 02, 16:00

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

User avatar
nikos
Site Admin
Site Admin
Posts: 14705
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Post by nikos » 2009 Feb 02, 16:57

for me whether i click on the desktop, an explorer window or using the context menu, the new x2 instance (thread) comes on top!?

User avatar
fgagnon
Site Admin
Site Admin
Posts: 3737
Joined: 2003 Sep 08, 19:56
Location: Springfield

Post by fgagnon » 2009 Feb 02, 17:23

The point of my post is that, whatever the difference may be, it does *not* seem to be specific to Windows 7 beta.

Perhaps you already have the /P switch on your x2solo command lines?

Try opening xplorer2_UC.exe from Start | Run ... when you already have a single instance of x2 open.

User avatar
nikos
Site Admin
Site Admin
Posts: 14705
Joined: 2002 Feb 07, 15:57
Location: UK
Contact:

Post by nikos » 2009 Feb 02, 17:38

no i don't have /P i have the "normal" x2 window open and then the "x2solo" opens on top of it

User avatar
fgagnon
Site Admin
Site Admin
Posts: 3737
Joined: 2003 Sep 08, 19:56
Location: Springfield

Post by fgagnon » 2009 Feb 02, 20:32

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,
earlier, you wrote:I'd much prefer such a workaround, if it exists, being posted in this thread
That would be using the /P command line switch I mentioned earlier.

Zarkthos
New Member
Posts: 4
Joined: 2009 Feb 01, 03:49

Post by Zarkthos » 2009 Feb 02, 21:48

fgagnon wrote: Zarkthos,
earlier, you wrote:I'd much prefer such a workaround, if it exists, being posted in this thread
That would be using the /P command line switch I mentioned earlier.
Indeed! Clever workaround, I appreciate you looking into it.

Cosmo
Gold Member
Gold Member
Posts: 465
Joined: 2007 Apr 17, 11:09

Post by Cosmo » 2009 Feb 03, 13:05

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.

User avatar
fgagnon
Site Admin
Site Admin
Posts: 3737
Joined: 2003 Sep 08, 19:56
Location: Springfield

Post by fgagnon » 2009 Feb 03, 15:04

Thanks for that discovery/explanation Cosmo :thumbup:

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. ;)

Post Reply