terminal: starting Terminal with wt no longer returns the main window handle of the resulting window

Environment

Windows build number: 10.0.20175.0
Windows Terminal version (if applicable): 1.2.2022

Any other software?
N/A

Steps to reproduce

Open Windows Terminal 1.2.2022 from code that supports returning the main window handle; for example in C# .NET

using System;
using System.Diagnostics;
using System.Threading;

namespace Test
{
    class Program
    {
        static void Main(string[] args)
        {
            Process p = Process.Start("wt"); // Start Windows Terminal
            Thread.Sleep(1000); // Wait a second to make sure it's open
            Console.WriteLine(p.MainWindowHandle.ToString()); // Print handle to console
            Console.ReadLine(); // Wait for user input before finishing
        }
    }
}

Expected behavior

The handle for the subsequently opened window is returned. In the example above, a numerical value representing the window handle is printed to the console (such as 856282)

Actual behavior

A handle of 0 is returned.

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 2
Comments: 45 (15 by maintainers)

Most upvoted comments

So, okay, this is really cool and I’m sorry we broke it. We’ve got some changes in store that are probably going to make this worse before it makes it better. Once #5000 lands, even WindowsTerminal.exe isn’t really going to have an HWND to hand out…

@zadjii-msft: gvim supports a --windowid parameter that allows for hosting. 1-10 how mad would it be if we … did something that … was horrible like that?

DHowett on Jul 27, 2020

@sylveon @zadjii-msft how usable is the WPF control at this point? @StefanKoell reported not so long ago having tried it without much success, as it wasn’t ready for prime-time yet. I know a WPF control is considered proper, but I would still very much like to do the simple window reparenting integration, because unlike the WPF control, it doesn’t require shipping a full copy of Windows Terminal. I think both are complementary, not mutually exclusive.

Control over the settings.json file to embed Windows Terminal inside a parent application is an issue that would affect both window reparenting and the WPF control integration, but I couldn’t find a corresponding feature request ticket for it. Even with a WPF control, it would be a whole lot better for the parent application to simply inject its own settings.json containing global configuration and preconfigured profiles. This would be the only way to handle storing profile configurations inside a password manager or any other type of application. It wouldn’t make sense to overwrite the existing settings.json with temporary configuration, so the most straightforward approach would be to find a way to override the location of settings.json with a command-line parameter or an environment variable.

Is there such a feature request already? This is beneficial to both approaches to embedding Windows Terminal inside a parent application. From a quick look at the code, it only looks for settings.json inside two predetermined paths: one when inside an MSIX package, and one when “unpacked” or outside an MSIX package. It looks for LocalAppData with the following call, and I am not aware of a trick to force it to return something else (changing $Env:LocalAppData didn’t work, but it was worth a shot):

SHGetKnownFolderPath(FOLDERID_LocalAppData, KF_FLAG_FORCE_APP_DATA_REDIRECTION, nullptr, &localAppDataFolder)

A simple environment variable to force WindowsTerminal.exe to use a given directory for its settings would be enough to solve this problem. All we’d need to do is generate the settings.json on-the-fly and tell WindowsTerminal.exe to use it.

awakecoding on Feb 9, 2021

It’s here: https://github.com/microsoft/terminal/tree/main/src/cascadia/WpfTerminalControl

sylveon on Feb 8, 2021