PseudoConsoleWindow position after "Move Tab to New Window"?

[vefatica]

I have this simple plugin shell variable for TCC.

INT WINAPI _HWNDCON(LPWSTR psz)
{
	RECT r;
	HWND hWndCon = GetConsoleWindow();
	GetWindowRect(hWndCon, &r);
	wsprintf(psz, L"0x%08X %d %d %d %d", hWndCon, r.left, r.top, r.right, r.bottom);
	return 0;
}

When I start TCC in WindowsTerminal, I see this.

v:\> echo %_hwndcon
0x00590354 0 0 16 16

After "Move Tab to New Window" I see this.

v:\> echo %_hwndcon
0x00590354 2224 88 2240 104

I'm not moving it. Any idea what's happening? Thanks!

[lhecker]

I think this may just be a side-effect of how the fake PseudoConsoleWindow is basically just a 0*0 pixel sized WS_POPUP window, which is owned by Windows Terminal. It really exists as a proper window on the desktop, it simply just isn't visible. And so when you interact with Windows Terminal, maybe it just receives a message at some point from the parent window which relocates it on the desktop?

I expect this to be either resolved if we ever use HWND_MESSAGE (see here) or if we ever get to writing a conhost.lib which means that Windows Terminal will be a proper console server again, just like conhost used to be (#15976). To be absolutely clear, that last one is not yet planned or even guaranteed to even be planned to happen. It's just an idea as a very long term vision.

[vefatica]

Isn't the PseudoConsoleWindow ownwd by OpenConsole? That's what GetRealWindowOwner says (that might have come from you, Leonard). I have been making the PseudoConsoleWindow HWND_MESSAGE for a couple years because ill-behaved shells (like mine) cause it to be shown. And for equally long, with a WinEventHook, I also make it follow WT's cascadia window in size and position because ill-behaved shells use it to locate GUI things.

There has been no problem with those two strategies until I tried to handle "MoveTabToNewWindow" (an academic exercise because that's something I'll never do except in testing). As I said in my first post, "MoveTabToNewWindow" makes the PseudoConsoleWindow move (I'm not doing it) and after that, at least so far, I can't move it where I want it even though I can get a handle to the new cascadia window. Does "MoveTabToNewWindow" cause a change in the PseudoConsoleWindow's styles (from something I can move to something I can't move)?

[zadjii-msft]

I can't say we're intentionally doing something here. Sounds like a bug to me. You're also probably in the .1% of people in terms of their engagement with the pseudo console window, so you might have the most expertise to actually investigate how that's transpiring 😉

[vefatica]

I'm always glad to help but I don't have a plan. And there's much I don't understand. Apparently the PseudoConsoleWindow is really owned by the OpenConsole process and it's parent is the Cascadia window. Is there any need to do anything to the PseudoConsoleWindow (notably, set it's parent to the Cascadia window, though to me, making it message-only is a good idea)? Does making it a child of the Cascadia window accomplish anything?

I have noticed these things. If my shell is the only thing in WT, after MoveTabToNewWindow the old Cascadia window is not destroyed; it stays where it was, becomes invisible; if I show it, it has a transparent client (?) area. If I have made the PseudoConsoleWindow message-only then, upon MoveTabToNewWindow , WT cannot (does not) set the PseudoConsoleWindow's parent to the new Cascadia window.

I'd be glad to try things but I'm running out of ideas.