Questions about programming for tearout/tearin

[vefatica]

I've got the TCC shell, which does a number of GUI things, working pretty well as long as its CASCADIA_HOSTING_WINDOW_CLASS window doesn't change. Tearout/tearin poses new problems. The answer to one question might let me handle this. If not, I'll be back. So here's the question.

Upon tearout/tearin, does the shell get a new PseudoConsoleWindow or does the old PseudoConsoleWindow get a new parent?

Any other insight would be appreciated.

[vefatica]

OK, that was a bad question. I see now that, after tearout, neither the PseudoConsoleWindow nor its parent (the Cascadia window) changes. That's exactly my problem. I want the Cascadia window that my shell is actually in (after tearout), not the one it used to be in. How do I do that?

[lhecker]

The GA_ROOTWINDOW code that was suggested in the other discussion should theoretically work for this. If not, we have a bug in our code.

[vefatica]

I'm using that now. Inside my GetCascadiaWindow() I have HWND hWndCascadia = GetAncestor(GetConsoleWindow(), GA_ROOTOWNER);. And I use (my own) PrintWindowInfo(GetConsoleWindow()); and PrintWindowInfo(GetCascadiaWindow());

Here's what I see, first, before tearout.

Then after tearing out the 5948 tab; nothing has changed.

Are you supposed to be giving the PseudoConsoleWindow a new parent?

[vefatica]

OK, my fault (as is often the case). I was making the console window message-only (with SetParent). With that removed, I see the change of the root window.

Is that right ... SetParent(hWnd, HWND_MESSAGE) screws up future use of SetParent? Is there a way to undo message-only?

We discussed the pseudo console window becoming visible a long time ago. Have you taken steps to prevent that?

[DHowett]

Unfortunately, we never proved conclusively that it was actually the pseudoconsole window. The current theory is that it's the XAML input site or XAML CoreWindow (both of which are an implementation detail of the UI framework we are using in Terminal).

Leonard fixed a lot of Pseudoconsole hosting window issues in 1.21 and 1.22 regardless. It may be worth trying again to not reparent it.

[vefatica]

It may be worth trying again to not reparent it.

Yeah, I'm doing that now and, so far so good. I have an OpenConsole-specific EVENT_SYSTEM_FOREGROUND WinEvent hook that foregrounds the Cascadia window if anyone tries to foreground the console window (as TCC does). Maybe that's doing the job. Or maybe that's not necessary given Leonard's improvements.

I'm pretty sure it was the pseudoconsole window I was seeing. I make it follow the Cascadia window around in size and position and when it shows (or used to show, fingers crossed) it's pretty obvious that that's what it is.

[vefatica]

Leonard fixed a lot of Pseudoconsole hosting window issues in 1.21 and 1.22

I have an OpenConsole-specific EVENT_SYSTEM_FOREGROUND WinEvent hook that foregrounds the Cascadia window if anyone tries to foreground the console window (as TCC does)

When I remove that hook I see the same thing I'd see if it were still there. That is, in a situation where TCC tries to foreground the console window (when the user has dismissed a dialog), I see it become the foreground window only very momentarily (~ 2ms). Below, I'm monitoring as fast as I can with command line tools.

11:05:43.195023 : "#32770"
11:05:43.195359 : "#32770"
11:05:43.195923 : "PseudoConsoleWindow"
11:05:43.196412 : "PseudoConsoleWindow"
11:05:43.196810 : "PseudoConsoleWindow"
11:05:43.197088 : "PseudoConsoleWindow"
11:05:43.197393 : "CASCADIA_HOSTING_WINDOW_CLASS"
11:05:43.197773 : "CASCADIA_HOSTING_WINDOW_CLASS"

So I'm curious. How's that being done? Does it guarantee that the console window won't be seen?

[vefatica]

There's another artefact associated with the scenario of my last post. If I dismiss TCC's dialog with a mouse click (OK/Cancel) then the busy mouse pointer (spinning blue ring) starts immediately (before the dialog disappears) and continues indefinitely after dialog disappears and the Cascadia window regains the foreground. Even though it no longer seems necessary for my WinEvent hook to foreground the Cascadia window, I'm still using it to click (or wiggle) the mouse to get rid of the busy pointer. I don't know why this happens in this particular scenario but IMHO, Windows is, in general, all too eager to show the busy mouse pointer.