Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

Loss of Focus After Operations (e.g., with XDIR)

Jay Sage

Jay Sage

Jun
1,092
48
I was just testing XDIR. When I was on a directory and pressed Shift-Enter, TCC (in a ConPTY tab in TCMD) changed to the directory, but it would not accept input. I had to click the mouse in the tab window before it got focus. It does not happen in anon-ConPTY session.

I know that I've had this happen in other cases, but I thought it was just a temporary glitch. With XDIR just now it was completely repeatable.

Ah, it happens whenever I exit from XDIR (e.g., using ESC).
 
rconn said:
Anyone else seeing this?
Click to expand...

Yes. I'm seeing this focus issue with XDir, @GetDate, and any command dialogs.

Curiously, I'm not seeing the issue with "Everything /e", nor with FSearch (gui dialog).

Also, no issue with focus returning when I open/close TCEdit.
 
Yes. I see the same.

This does not happen when TCC is running in conhost!

Additional note: It seems that the focus is returning to the console anytime an external (EXE) is started and immediately terminated. I tested Notepad++ and WinWord in addition to the above. Any internal dialog sends the focus into "Nirvana", that is, no running process has the focus after closing the dialog. Might be easily repaired by adding a SetFocus WinApi call at a strategic place.

While testing a bit I ran into another bug (ConPTY).
  1. Add an additional Tab: Tabs -> New Tab
  2. Tear if off, i.e., drag it to the Windows desktop with the mouse.
  3. Run *xdir
  4. Console hangs!
Hope this helps.
 
DieterKoessl said:
Additional note: It seems that the focus is returning to the console anytime an external (EXE) is started and immediately terminated. I tested Notepad++ and WinWord in addition to the above. Any internal dialog sends the focus into "Nirvana", that is, no running process has the focus after closing the dialog. Might be easily repaired by adding a SetFocus WinApi call at a strategic place.
Click to expand...

Well - no. TCMD is already doing a SetFocus & SetForegroundWindow at the strategic place; this problem is because the TCC child process (the one running the dialog) is being (sometimes on some systems - it's timing issue in a very short span) given the keyboard focus by Windows before TCMD knows the dialog is closed. And then Windows won't allow TCMD to take the keyboard focus back.

I have added a more complicated workaround for this in build 34. TCMD is now using AttachThreadInput to club TCC over the head & grab the focus back).
 
After returning from XDIR, TCC in a TCMD tab still does not have focus for me even with build 34. And I'm now running on my desktop, so it's happening on both laptop and desktop.
 
rconn said:
I have added a more complicated workaround for this in build 34. TCMD is now using AttachThreadInput to club TCC over the head & grab the focus back).
Click to expand...

Also not working in build 34 for my use cases (XDir, @GetDate, and any command dialogs).
 
At least with XDIR it seems to matter where the XDIR window is. If it's on top of TCMD, TCMD has input focus when I'm done with XDIR. If I move XDIR to the other monitor, TCMD does not have input focus when I'm done with XDIR.
 
As I have in other situations, I see the foreground window going from class "XDirListBox" to class "PseudoConsoleWindow" (and staying there).
 
vefatica said:
As I have in other situations, I see the foreground window going from class "XDirListBox" to class "PseudoConsoleWindow" (and staying there).
Click to expand...
That happens when I "X" the XDIR window, not when I Esc out of it.
 
It's a bit iffy but I often see the likes of this when I dismiss the XDIR window.

Code: 
d:\tc36> do forever ( delay 1 & echo %@fgwin[cm] )
"XTPMainFrame" "D:\tc36\TCMD.exe"
"XTPMainFrame" "D:\tc36\TCMD.exe"
"XDirListBox" "D:\tc36\tcc.exe"
"XDirListBox" "D:\tc36\tcc.exe"
"XDirListBox" "D:\tc36\tcc.exe"
"XDirListBox" "D:\tc36\tcc.exe"
"XDirListBox" "D:\tc36\tcc.exe"
"XDirListBox" "D:\tc36\tcc.exe"
"PseudoConsoleWindow" "D:\tc36\tcc.exe"
"PseudoConsoleWindow" "D:\tc36\tcc.exe"
"PseudoConsoleWindow" "D:\tc36\tcc.exe"
"PseudoConsoleWindow" "D:\tc36\tcc.exe"
"PseudoConsoleWindow" "D:\tc36\tcc.exe"
 
Getting the focus back doesn't work for me either. But I made an interesting observation while reading this thread and playing around somewhat.

  1. Two open windows "Firefox" and "TCMD"
  2. Firefox has focus (caret in this very message)
  3. Set focus into TCMD (mouse-click) and *XDir
  4. Ctrl-E on some (arbitrary) text file
  5. TCEdit opens and gets closed immediately via Alt-F4
  6. XDir now has focus and gets closed via ESC
  7. TCMD drops to the background and...
  8. Firefox comes to the foreground, but does not have the focus (no caret)
As you might have gathered, I do have some experience programming Windows, but none whatsoever in clubbing consoles over the head :-). So here are some wild guesses:
  • Order of SetFocus & SetForegroundWindow? (most probably not)
  • PostMessage to own HWin and grab focus when that message comes back (I found this helpful in many cases, especially with timing problems, since things tend to settle down somewhat while Windows goes through the message queue)
  • Using a small Delay before grabbing back the focus (as a last resort, since this would be inherent machine dependent, but could be timed with a small loop and counting clock ticks, say 50 ms, i.e., long enough for Windows but imperceptible for the user)
I am just trying to be helpful, but don't really know if those ideas pertain to what's happening.

PS: the other fix is working.
 
JFI: I have this too with XDIR ... after closing TCMD has no focus.
 
In build 35, for my use cases with focus issues:
XDir: works perfectly!!!
@GetDate: still does not work (cursor blinks but TCC doesn't have focus)
command dialogs: still do not work (cursor blinks but TCC doesn't have focus)
 
Same here. On exit from XDIR, I can type at the command prompt. After echo %@getdate[] the date is echoed to the screen but nothing appears when I type until I click with the mouse. Same with @getdatetime
 
Same behavior.

On an additional note: The history dialogs, i.e., command and directory, also work fine. Do these use the same code as XDir?

Edit: some time later after more random tests with command dialogs.

1st test
  • in TCMD enter DIR and press Alt-F2
  • command dialog opens
  • click on Firefox
  • click on command dialog
  • result: Z Order of windows is unexpected (screenshot)
2nd test
  • first two items as before
  • click on TCMD window
  • command dialog blinks "in and out of existence"
Most probable explanation for 2nd test : TCMD grabs focus, command dialog goes to the background and finally grabs the focus and comes to the foreground again.

This also happens when TCC v36 is running in conhost and in TCMD v35. I never managed to see this before.

Question: are those "dialogs" non-modal windows which do not disable their parent, i.e., the TCMD main window? If true, I somewhat understand the comment about "timing problem". This might then be something which is inherently machine dependent, e.g. processor speed, performance of graphics card, driver of graphics card, etc.

One more thing about the 1st test: when clicking on Firefox and the command dialog repeatedly to switch the focus back and forth I manged to get the command dialog blinking in the background on some occasions. It seems the command dialog is trying to grab the focus and cannot get it. Unfortunately, this is not consistent and I cannot reproduce it myself reliably, that is, I cannot give a clear indication when and how that happens.

I hope this provides some pointers on what is happening. The odd Z order is not much of an obstacle, but losing the focus is somewhat annoying.
 

Attachments

  • Screenshot.webp
    Screenshot.webp
    36.3 KB · Views: 33
Last edited:
DieterKoessl said:
Question: are those "dialogs" non-modal windows which do not disable their parent, i.e., the TCMD main window? If true, I somewhat understand the comment about "timing problem". This might then be something which is inherently machine dependent, e.g. processor speed, performance of graphics card, driver of graphics card, etc.
Click to expand...

The dialog windows are not children of TCMD, they belong to the TCC process (either running in ConPTY or a hidden console). TCC sends their handles to TCMD so that TCMD can make them visible and give them the keyboard focus when the tab hosting their TCC session is visible.

And some of the dialogs are modal and some not.
 
Please try this build and let me know if TCMD gets the keyboard focus after a dialog exits.
Click to expand...

No! Same outcome as before:
  • XDir and history windows work
  • command dialogs and function dialogs don't
And, just for the record, it doesn't matter how the command dialogs are closed: ENTER, ESC or a mouse click at any button.

A work around of sorts, which I am slowly getting used to, is to hit Alt-Tab once. This puts the focus back into TCMD. This might indicate, that something which is not visible is trying to get the focus.
 
rconn said:
And then Windows won't allow TCMD to take the keyboard focus back.
Click to expand...
What if TCC did

Code: 
AllowSetForegroundWindow(dwTCMDpid);

That's a shot in the dark. I'm experimenting; more later.

I've played with this a lot and I can't reproduce a problem (I could in the past).
 
You must log in or register to reply here.
Back
Top