Focus problem when opening dialog window


I want to write a Rhino 5 plugin, that opens a WPF window.

Most basically:

var window = new System.Windows.Window();
window.Title = "My Window";

I DON’T want to set the owner window like this:
new WindowInteropHelper(window).Owner = RhinoApp.MainWindowHandle();
instead I want the window to have no owner, it just works better for this kind of dialog.

The dialog opens in front, if I run the command via console, but it opens in the back, if I run it via a custom toolbar. And it is not possible to bring it to the front. When I try to (using the taskbar or ALT+TAB), it flickers shortly and Rhino steals the focus, moving the dialog behind the Rhino window again.

It’s not WPF related, happens with WinForms, too.

What can I do, except setting the owner window or using topmost?

Best regards

it just works better for this kind of dialog

Can you tell more about why it works better, why you prefer it without parent window?

The dialog shows some kind of library, with lots of thumbnails. It’s rather big and takes some time to load. So a user might want to load it, do some work in Rhino, and switch back to the library afterwards.

This workflow is not possible if the library has the owner window set to Rhino - this means it’s always in front of Rhino, which hinders work in single-screen environments. It should behave more like an independent application.

I see. An alternative is maybe to create it as a plug-in panel? It will dock in the same region as the Layer Manager and the user can, when they want to, undock the panel and make it as large as needed. We do this for a number of windows that are of the same nature as you describe: should always be visible, but you want the user to be able to continue working with Rhino.

The plug-in panel registration code only accepts Winforms though, so that may be less than ideal.

Another alternative is maybe to create the window small while it is still loading in the background and to re-paint the Rhino GUI on the main thread using RhinoApp.Wait(); Thread.Sleep(10); This way the user has a semi-modal window above the rhino window, but it is still small (maybe showing a “Loading, please wait” message). Because of the repainting of the Rhino GUI, the user can keep working in Rhino.

WinForms can host WPF if I’m right, but to be honest, I believe this creates more problems than it solves. Can you ensure a minimal size if you use a dockable panel? Small sizes will make my WPF window layout unusable.

The problem with the loading time is not, that the user can not continue work in Rhino (loading already happens in a background thread), but that he opened the dialog to use it, and it is not ready to be used until loaded.

I would prefer some solution that doesn’t involve rewriting the whole dialog, because most of the code is shared with plugins for other CAD software.

Can anyone at least reproduce the problem?


For this kind of thing, I would strongly recommend a panel. Setting no parent means you get all kinds of problems.

  • Andy

Note that the last thing you want to do with Rhino is “capture the focus” - because then users can’t type commands at the command line.

  • Andy

I’m not aware of any problems in usability if I don’t set the parent window. Works like a charm and simply feels like a separate application (at least if it would work like my Revit and SketchUp plugins).

I’m not capturing the focus. It’s window.Show(), not window.ShowDialog(). But I expect that if I ALT+TAB to a window or select it in the taskbar, that it has focus. Instead Rhino steals the focus.

Did you try to run my example? It is completely unusable.


Hi Simon,

I am having the same issues here. Did you find a solution?