The "Center the child window over the parent" feature currently moves all child windows. This is interfering with programs that calculate their own centered dialog positions, but come up with a different value than DisplayFusion.

DisplayFusion only moves windows after a slight delay, enough for the dialog “jump” to be visible. Unfortunately, this also means that a user with fast reflexes may click on the wrong dialog. This can have severe consequences.

For example, in Paint.NET, the dialog position is almost at the center, but slightly offset. When the "Unsaved Changes" dialog appears, then DisplayFusion moves it up by about 80 pixels. Unfortunately, this is a task dialog, in which the options are listed vertically. If you react too quickly, then you click on the original position of “Save”, except that it’s now over “Don’t Save.” You lose all your unsaved changes!

See attached screenshots showing the problem caused by the centering.

Desired behavior: Center the child window only if it is not over the parent window.

Alternative behavior: Center the child window if it does not overlap the calculated center position. This solves the problem for modal dialogs, but not for non-modal dialogs, because the click could go to the parent window.

But you know exactly where Paint.NET thinks the dialog should be. It's where the dialog was located on the screen before it got moved.

Monitors are so wide these days that centering is a useful feature, even if it's on the same monitor. You just don't want it to cause misclicks. The way to do that is to center only if there is no overlap -- i.e., if the user cannot click on the wrong option.

The idea is that if the program put a dialog over the main window, then it probably knows what it's doing. DisplayFusion shouldn't second-guess it and move it anyway. Before moving a child window, it should check its position, check for overlap, and then cancel.

--

Actually, there's another bug here. I have "Only move modal windows [...]" checked. And the Unsaved Changes dialog in Paint.NET is modal. So it shouldn't have been getting moved at all, even if Center was checked.

In fact, DisplayFusion is even moving the Unsaved Changes dialog in Notepad! This is not a custom dialog like the Paint.NET dialog -- it's a standard Windows dialog. If it's even happening to Notepad, then the whole thing is broken.

--

As for your suggested workaround:



If it works as you describe, then the text of the option is misleading.

"Center the child window [...]" is currently a suboption under "Move child windows to the same monitor [...]". Because it is a suboption, you expect it to control what happens when the parent option is activated, i.e., only when moving child windows to a different monitor.

If it works as you describe, then it's always centering child windows after moving them between monitors. (This makes sense since monitors can be different sizes.) The option is actually doing the reverse of what its position implies -- it's controlling the centering of child windows that are not moved to a new monitor.

The text of the option should be revised to say this.

Thanks, Keith. The help text would also need to be changed to indicate that child windows are always centered when moved between monitors: http://www.displayfusion.com/Help/?Version=6.0#settings-windowmanagement

Sorry, you're right about the modal windows. I was just getting hung about the case of moving modal windows to a different monitor, but not centering them. But windows are always centered if they are moved to a new monitor. Thus, it's behaving as expected.

The wording is confusing because it's really a two-step action: moving a child window to the same monitor as the parent, and centering it over the parent. But you could conceivably move without changing its position -- for example, the DisplayFusion command "Move Window to Next Monitor" preserves the position of windows. Or, you could center a child window that's already on the same monitor, even though this means it's not otherwise getting moved.

May I suggest the following text and defaults:



This would better capture DisplayFusion's actual behavior for these options. When you center over the parent, then by definition, you're also moving it to the same monitor as the parent. So that wording captures both aspects.

The beta works great in all three cases. Thanks!