Detect Windows Terminal

[Charles Dye]

I was trying to work around this problem: when you open the OPTION dialog, then close it, you get the busy mouse pointer and WT no longer has focus.

Not just OPTION. This appears to be true of any dialog opened by TCC in Windows Terminal: the Open dialog, the Save As dialog, @COLOR[], @GETDATE[] and @GETDATETIME[], probably many others.

I believe Rex is automatically re-focusing the console window (or the Take Command window) whenever a TCC dialog closes. And I believe he's doing this because we requested it... many times.... Of course, under Windows Terminal, "the console window" is invisible and useless, and giving it the focus accomplishes nothing good.

I've just made some tweaks to my PopupFix plugin to better handle Windows Terminal.

 

[vefatica]

Do you ever see the PseudoConsole window? I used to see it ... small and near the upper-left of my primary monitor. Fix that by making it HWND_MESSAGE (with SetParent()). I've been doing that for about a year with no ill effects.

I've spent hours trying to get rid of the busy ponter (click/wiggle the mouse) and I'll probably spent more time on it. Clicking the mouse works but it can trigger WT's selection mechanism (which isn't pretty). Wiggling the mouse works but you have to wait until the popup had disappeared; I don't know an elegant way to do that.

FWIW, at the moment I'm using these WinEventHooks.

// hWndCascadia: EVENT_SYSTEM_MOVESIZEEND - WT process-specific hook
VOID CALLBACK hookproc(HWINEVENTHOOK hWinEventHook, DWORD event, HWND hwnd, LONG idObject, LONG idChild, DWORD dwEventThread, DWORD dwmsEventTime)
{
    if ( hwnd == g.hWndCascadia )
    {
        MoveSizePseudoConsoleWindow(); // to match Windows Terminal
    }
}

// hWndConsole: EVENT_SYSTEM_FOREGROUND - OpenConsole process-specific hook
VOID CALLBACK hookproc2(HWINEVENTHOOK hWinEventHook, DWORD event, HWND hwnd, LONG idObject, LONG idChild, DWORD dwEventThread, DWORD dwmsEventTime)
{
    if ( hwnd == g.hWndConsole )// PseudoConsoleWindow
        SetForegroundWindow(g.hWndCascadia);
    if ( MouseInWT )
        WiggleMouse();  // kludge: WiggleMouse waits 1 second
}

I'm curious about your other strategies. I'll share mine.

 

[Charles Dye]

Brute force. I scan for new TCC popups and dialogs eight times a second with EnumThreadWindows(). When a new one appears, force it to the front (dialogs sometimes appear under Take Command) and give it focus. If it's offscreen (Console2 does this sometimes), move it where it's visible.

When one of these windows closes, give the focus back to TCC's window -- which may or may not be the console window, depending.

 

[vefatica]

You could probably do the same with WinEventHooks (as opposed to scanning); ever use them? Theyr'e pretty easy and efficient.

I only do any of this in a 4WT plugin which refuses to load if it doesn't think TCC is in WT. It seems like quite a chore to do it more generically (handling WT, TakeCommand, Console2, ...). Don't you need a handle to the actual UI window?

I only test with the OPTION dialog (get the busy pointer) and the DirHistory popup (don't get the busy pointer). I don't know how other popups behave.

 

[Charles Dye]

You could probably do the same with WinEventHooks (as opposed to scanning); ever use them? Theyr'e pretty easy and efficient.

No, I've never tried those. They might be an idea for v2.0. Or then again maybe not, because....

It seems like quite a chore to do it more generically (handling WT, TakeCommand, Console2, ...). Don't you need a handle to the actual UI window?

Yes, and I make it available via a variable. Once in Windows Terminal, always in Windows Terminal, but: the handle can change. Tabs can be split off to a new window, or moved from one WT window to another. So there's one point in favor of periodic scanning.