Welcome!

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

SignUp Now!

Version 36: Focus is not returned to the TCC window after displaying a pop-up dialog

Jun
149
13
I'm not sure if this is by design, but it's definitely different than how Version 35 behaves.

I first noticed this when testing @GetDate from the command line. Once the calendar dialog is closed, I needed to select the TCMD/TCC window in order to type another command.

I also see this issue when opening an internal command dialog. e.g. try entering Dir /= <Enter> at the command line and then just hit Escape to exit.
 
From a stand-alone TCC, and from a TCC tab in Windows Terminal;
Code:
E:\Utils>ver

TCC  36.00.17 x64   Windows 10 [Version 10.0.19045.7058]

E:\Utils>echo %@getdate[]
2026-04-05

Both returned to the TCC window,
and I was able to type in another command,
without first having to select the TCC window first.

Any others with this issue?

Joe
 
I can reproduce this one. While running this command (@FGWIN is a plugin) in another TCC, outside TCMD, ...

Code:
do forever ( delay 1 & echo %@fgwin[c] )

... and trying the @GETDATE test in TCMD36/TCC36, I see this.

Code:
"XTPMainFrame"
"XTPMainFrame"
"XTPMainFrame"
"#32770"
"#32770"
"#32770"
"#32770"
"PseudoConsoleWindow"
"PseudoConsoleWindow"
"PseudoConsoleWindow"

I had foreground window problems through much of the private beta testing. It has been somewhat better, though not perfect, lately.
 
Still seeing an issue with this in Build 18.

Entering Dir /= <Enter> at the command line and then just hit Escape to exit.
Cursor now displays in the TCC window, but you can't type anything until you select the TCC window.

Then entering echo %@GetDate[] <Enter> and then hitting Escape to exit.
"Echo is off" message displays (as expected), but no cursor is displayed and you still can't type at the command line.
 
I can't reproduce this with DIR /= bit I still can with @GETDIR using the same test as above. Foreground is going to the "PseudoConsoleWindow" class window.
 
I can't reproduce this with DIR /= bit I still can with @GETDIR using the same test as above. Foreground is going to the "PseudoConsoleWindow" class window.

Just to be clear Vince, after you hit Escape from the command dialog, you can type your next command in TCC without having to select the TCC window?

I'm running TCC as a ConPTY tab within TCMD. Is that how you are running too?

-Michael
 
Yes, I'm in TCMD with ConPTY tabs.

In the case of DIR /= I can type my next command, with @GETDATE I can't.
 
Seems like we are getting different results. Not sure what could be causing that. I just posted a step-by-step description in another post of another issue I am seeing with cursor positioning which may or may not be related to this issue (for me).

When you have a minute, can you take a look and see if following those steps results in any issues for you?
 
I'm not sure what else I can do to help troubleshoot this issue.

I see the same result with all of these commands

Code:
Dir /=

Beep /=

echo %@GetDate[]

echo %@GetFile[C:\batfile]

Whenever I exit the pop-up dialog I am unable to type anything at the TCC command line until I first select the TCC window.

I would record a video, but I don't think it would be helpful because it wouldn't show me trying to type characters and them not appearing in the TCC window. I guess I could record a video to show that after closing the pop-up dialog there is no blinking cursor in the TCC tab until I click on the window. Let me know if that would be helpful.

I'm open to other ideas on how to troubleshoot. I know Vince has said he is not having any issues with the command dialogs, but he is with @GetDate.

Again, I'm left wondering if it's something specific with my configuration.
 
Try it with build 19. I couldn't reproduce your issue but I added some code to check for unlikely issues.
I'm still seeing the same issue with focus not returning to TCC after executing any of the following 4 commands which display pop-up dialogs.

Code:
Dir /=
Beep /=
echo %@GetDate[]
echo %@GetFile[C:\batfile]

I did see something I hadn't noticed before. After the pop-up dialog is closed, the TCMD icon in the taskbar starts to blink slowly. When I click on the TCMD window to restore focus, after a short delay, the icon stops blinking. Not sure if that is helpful to diagnose my issue, but I'm attaching a video to show you what I'm seeing.
 

Attachments

It's OK for me with build 19. After echo %@getdate[] foreground/focus goes back to TCMD.
 
It's OK for me with build 19. After echo %@getdate[] foreground/focus goes back to TCMD.

And so that apparently leaves me standing all alone with my issue :)

I don't even know where else to look. I can't imagine how anything outside of my TCMD/TCC config (or even inside) would induce the behavior I am seeing.
 
I opened a second tab with the legacy console and all my test cases worked fine, returning focus to TCC command line after displaying the pop-up dialog.

I also re-tested in the ConPTY tab, changing most of the TCMD and TCC options one at a time. That exercise led nowhere. I tried disabling anti-virus and firewalls...also to no avail.

Rex - is there any way to determine what is causing the TCMD icon to flash in the taskbar after I close a dialog? Would knowing why it was flashing be useful to troubleshooting?
 
The flashing on the toolbar is not being done by TCMD.

When you close the dialog, TCMD detects that, and if TCMD is the foreground app, TCMD sets the focus to the current tab window. Something in your setup is intercepting that SetFocus call and flashing the toolbar (but not allowing the focus change). I have no idea what could be doing that, unless you're running a screen manager.
 
The flashing on the toolbar is not being done by TCMD.

When you close the dialog, TCMD detects that, and if TCMD is the foreground app, TCMD sets the focus to the current tab window. Something in your setup is intercepting that SetFocus call and flashing the toolbar (but not allowing the focus change). I have no idea what could be doing that, unless you're running a screen manager.

I will continue to look at everything running on my machine to try to track down the issue.

In the meantime, one additional (maybe dumb) question...you said TCMD is doing the work to detect that the dialog was closed and that it was the foreground app (to then set the focus to the current tab window).

If I have some external thing intercepting the SetFocus call - does it make sense to you that TCMD could successfully set the focus for a legacy TCC tab, but not be successful doing the same for the ConPTY tab?
 
If I have some external thing intercepting the SetFocus call - does it make sense to you that TCMD could successfully set the focus for a legacy TCC tab, but not be successful doing the same for the ConPTY tab?

TCMD is using the same code in pseudoconsoles and hidden consoles to set the focus back to the tab window when the dialog exits. Which is not to say that Windows couldn't be doing something in pseudoconsoles to break it -- but so far you're the only one reporting the problem.
 
Back
Top