Ability to show a non-modal WPF window

[StevenRasmussen]

I recently updated an extension to use WPF instead of winforms for all things UI related. Previously if I needed to show a window I would simply call window.Show() or window.Showdialog() to open the window. However, when I open a non-modal window (window.Show()) then weird things start to happen... like the Backspace in a textbox causes the text in currently open file in Visual Studio to be edited instead of what's in the textbox. The same thing happens with the tab key.

After doing some searching it appears that there isn't really a supported way to get this to work as VS intercepts key strokes or something for non-modal windows. I found documentation regarding modal windows here.

I found this issue on StackOverflow that describes the exact same issue here.
This issue on VS Feedback site here.

The "supported" way seems to be to create a toolwindow or document window... but my window is short lived and shouldn't be dockable etc. It really just needs to be a regular WPF window.

Am I really out of luck or is there some way to work around this? For many of my windows I can make them modal but I have a window that pops up when a solution is opened and making it modal makes it blocking and sometimes causes issues with VS as it's still trying to load the solution in the background asynchronously.

On a side note, I'm thinking I'll open a PR with some extensions for opening a modal window to help with this as it's not as straight forward as simply calling window.ShowDialog().

[madskristensen]

I've seen similar behavior of a XAML control hosted in a tool window where focus backspace and other keys suddenly goes to the main editor instead of staying in the text field in my tool window. @AArnott @BertanAygun do you know how to send all keys to custom WPF controls? Is there a property to set on the Window object or...?

[AArnott]

I do not. @ryanmolden may know.

[StevenRasmussen]

@ryanmolden - Any thoughts around this would be much appreciated. Thanks

[reduckted]

A tool window seems like the easier way to go instead of fighting against Visual Studio. Apparently you can set a tool window to always float by setting the Style property in the ProvideToolWindowAttribute.

[Microsoft.VisualStudio.Package.ProvideToolWindowAttribute(typeof(MyToolWindow), Style= Microsoft.VisualStudio.Shell.VsDockStyle.AlwaysFloat)]

I tried it and I was still able to dock the window, but it did start out as a floating tool window. 🤷‍♂️

[yannduran]

@StevenRasmussen if you have a non-modal dialog, why would you want to intercept the keystrokes?

[StevenRasmussen]

@yannduran - It's not that I'm wanting to intercept key strokes... it's that the key strokes from my window are being intercepted by Visual Studio:

[yannduran]

I'm sure you have a good reason, but can I ask why you don't want it to be modal if it's short-lived? Also, are you inheriting from DialogWindow?

[StevenRasmussen]

I have one window in the 40+ windows in my extension where the need to show it in a non-modal fashion is the best choice... not necessarily because of the idea of it being modal is incorrect but because of the timing when it is shown. The window is the one shown in the animated GIF above and as you might be able to tell it's a form to login to something. I handle the SolutionOpened event which performs some logic to determine if the solution is "linked" with my extension. If so, then this window should be shown. The problem is that this event fires pretty early on in the whole "solution load" process and so if I show it as a modal window, VS appears to stop loading the projects in the background. I originally had it setup this way when I created the extension over 9 years ago but received quite a bit of feedback about how disrupting this was and that users would prefer it to be non-blocking. Since changing it probably 7 years ago I haven't had a single complaint ;)

I was thinking that if there was another event that was fired when the solution and each project was completely loaded in VS that might help... and I guess if this has to be a modal window then this might be the best solution, but I think then I'd get complaints that it takes too long to show the window. IDK... I get that the best practice fits the 95% of use cases... this particular window just happens to be in the 5% that it doesn't and so I'm really hoping that there's some way to make it work.

Also, I'm not inheriting from DialogWindow as I use some 3rd party controls that give me consistent theming (along with a lot of other benefits).

[yannduran]

Thanks for that explanation Steven

[reduckted]

@StevenRasmussen Have you tried creating and showing the modal in a separate thread? The code below seems to work for me, but I'm not sure if I'm doing something that I shouldn't. I seem to recall @AArnott saying not to use dispatchers in Visual Studio, but I can't remember where he said that. It may have been in this Remote Office Hours video.

private void ShowNonBlockingModal()
{
    var thread = new Thread(() =>
        {
            try
            {
                SynchronizationContext.SetSynchronizationContext(
                    new DispatcherSynchronizationContext(Dispatcher.CurrentDispatcher)
                );

                var dialog = new ThemeWindowDialog()
                {
                    DataContext = new ThemeWindowDialogViewModel()
                };

                dialog.Closed += (s, e) => Dispatcher.CurrentDispatcher.BeginInvokeShutdown(DispatcherPriority.Background);
                        
                dialog.Show();
                Dispatcher.Run();
            }
            catch (Exception ex)
            {
                ex.Log();
                Dispatcher.CurrentDispatcher.BeginInvokeShutdown(DispatcherPriority.Background);
            }
        }
    );

    thread.SetApartmentState(ApartmentState.STA);
    thread.Start();
}

[AArnott]

I discourage use of Dispatcher for scheduling because it can't mitigate deadlocks when the dispatcher thread blocks waiting for the work you schedule for it to run. But if deadlocks are already mitigated another way, that may be fine.

That said, creating another UI thread in VS isn't a technique I have any experience in, and I wonder what monsters may be unleashed thereby.

[StevenRasmussen]

@reduckted - Thanks! That's working for me now.