Can new windows/tabs in BC3 be made not to steal focus?

[alenl]

Thanks! I'm looking forward to it.

[Aaron]

Hello alenl,

This is still an open issue we are looking into. We have not had any additional reports since it was opened, but I will bump the issue entry as well.

[alenl]

Bump.... Just interested in the status of this. Noticed another version was released, but this bug is still here... Thanks.

[alenl]

I've created a tracker entry for this issue.

Thnaks!

How many tabs are you opening at once (30?)?

Yes, 30 is a good example, though if you are quick at the keyboard you can easily notice this as an annoyance even with as little as 5 files.

And is it only triggered when you then close one while it is still opening others?

Yes. If I close one while others are still opening, my focus changes two times. Once as expected, and once more briefly afterwards (when the next one opens). E.g. if I close #1 while #5 is pending to open. My focus will first be at #2 and then switch to #5 (as it finishes opening) without any input from my side.

Thanks for addressing this issue!

Alen

[Aaron]

Thanks for the additional information, Alenl. I've created a tracker entry for this issue.

How many tabs are you opening at once (30?)? And is it only triggered when you then close one while it is still opening others?

[alenl]

I have to correct myself. Latest updated versions, I guess since the fix that Craig mentioned was implemented, work ok if tabs are disabled (i.e. if each comparison starts as a separate app window). It is just the tabbed interface that doesn't behave correctly.

So it turns out it doesn't override the ForegroundLockTimeout any more, I was wrong on that remark. The assumption was based on earlier testing.

Can you fix the tabbed interface to behave correctly as well?

Thanks,
Alen

[alenl]

(Sorry for delay, somehow mail notification for this thread got turned off for me.)

Yes, I hit this frequently while working. Furthermore, this is a regression since BC2, as I had the same workflow before, and it worked correctly with BC2. I have elaborated this in more detail in post #6 (http://www.scootersoftware.com/vbull...19&postcount=6).

May I ask you kindly to check out the Microsoft documentation on ForegroundLockTimeout registry value? I would expect BC3's behaviour not to override or circumvent this system, and its tabbed UI to emulate the same behavior. Currently, it seems that tab-less UI seems to override this Window's default behaviour, and the tabbed interface uses a different paradigm.

I have checked this by putting Notepad.exe instead of BC3 in my SCM setup, and other Notepads correctly open in background if I start typing in the first one. BC3 somehow seems not to honour this setting.

Thank you very much in advance,
Alen

[Aaron]

Hello,

This would actually be a larger issue to address, and not a quick fix.

Do you find you hit this scenario often? Or have a common work method that hits it? If I understand correctly, to trigger it you would fire off multiple instances of BC from your source control, and then close one before they all finish opening.

Are there other users hitting this issue? With the above-described workflow?

[alenl]

Bump....

Are there any plans to fix this issue?

Thanks,
Alen

[alenl]

I've been testing it further over the last few days. Yes it behaves that way, and it is according to the implementation that you describe. If I close a tab (or just Ctrl+Tab to the next one) while some other tabs are still opening in the background, I am first briefly focused to the next tab in the list, but as soon as a new one opens, the focus jumps to the newly opened one. It really is confusing, and it kind of puts it back to the square one.

Btw, you mentioned the heuristic like: "viewers spawned by the command line would only gain focus if BC isn't the active application". Maybe that would be simpler and work better?

Btw, some interesting ravings on this topic in general can be found by searching http://www.google.com/search?q=don't+steal+my+focus

[Zoë]

Yes, the change made it in. It's in the changelog under "Command Line" as "Launching multiple instances of BC now gives focus to the first window opened instead of the last."

The flag for "launching from a background process" is cleared whenever you change or close tabs. If it's an issue I might be able to keep it going if you close the active tab and move to the next in the batch group, but I'd rather not keep that much state if it's not a significant issue.

[alenl]

I have checked this in the latest build (9740) and it seems to work that way (although I didn't see it mentioned in the changelog). This looks like a good approach.

There still appears to be some glitches there. If I just let it open them all, it does open in the background. But if I am working on the diffs while it opens in the background, sometimes it still pops up the new tab to foreground. I think it may be that if I close the first tab at the moment that it opens a new one, then the new one becomes current. But I will have to verify this. Will let you know if I can gather more info.

[Michael Bulgrien]

Thanks, Craig.

I agree that your most recent "alternative" sounds better than a "time-based heuristic".

I also maintain a similar option for GUI spawned sessions would be useful to me as well.

[Zoë]

Now that I've had time to think about it, another alternative would be that viewers spawned by the command line would only gain focus if BC isn't the active application. That would be less likely to guess incorrectly than a time-based heuristic and should give correct behavior.

[markf_2748]

I would think that allowing BC's response to depend on launch time interval introduces indeterminacy, given the vagaries of the operating system. Not a pretty picture.