Discussion: Should ContentDialog in a Desktop WinUI 3 app create a modal top-level window?

[marb2000]

Today, the ContentDialog is just XAML content placed on the top of the visual tree. In WPF, ContentDialog is like a MessageBox, which is a modal top-level child window.

Discussion: Should the ContentDialog pivot towards a modal top-level child window?

In this way, ContentDialog won't need XamlRoot anymore. There are several customer complains that the need of XamlRoot is unintuitive for WPF/Win32 developers (e.g. #2504)

There are several questions that need to be answer:

1. What parent XAML Window will host the ContentDialog top-level child window. Desktop WinUI 3 apps can have multiple Window objects in the same thread. So, do we need new APIs? For example:

   contentdialog.ShowAsync(mywindow); 

2. How will the new top-level child ContentDialog work with the RequestedTheme feature?

3. Will the new ContentDialog work in XAML Islands scenarios? Will be still needed XamlRoot for Islands?

[sylveon]

Would that allow hosting multiple ContentDialogs in the same thread in Xaml Islands?

[mdtauk]

There was a topic about looking at Content Dialog dismissal behaviour #2122 which perhaps could be a behaviour property of the ContentDialog.

That way it could render within the window with Light Dismiss. Include as default, the current behaviour, and add a ModalWindow option, which will create a movable window with only a Close button, or Close and Minimise.

ContentDialog.Behaviour - LightDismiss
                        - Overlay
                        - Modal

[dotMorten]

I like where @mdtauk is headed here. I was thinking the same thing except for light dismiss but that's also an awesome idea and something I've implemented many times manually

[ShankarBUS]

But if it is modified as a modal window would it still have rounded corners, shadows, overlay?

My guess is the modal window will still look like the old HWnd, having a rectangular border 🤦‍♂️. So it will be similar to a normal modal dialog with xaml content in it.

If a user wants ContentDialog as a modal window, they can create a modal window with xaml content (maybe in the future?)

Just keep ContentDialog the way it is. Or may be create a new ModalDialog control just for WinUI desktop for that scenario

[jtbrower]

@marb2000

contentdialog.ShowAsync(mywindow);

In a more ideal situation we could associate the dialog with its Window using the Parent property, but I see that's not an option because a WinUI Window is not a FrameworkElement like a WPF Window is. It would almost seem to be inverting responsibility to have the Window passed to the ContentDialog, but not knowing the implementation details sometimes you have to do things like that to avoid other challenges.

ContentDialog.Behaviour - LightDismiss
                        - Overlay
                        - Modal

The one other important dialog window is the non-modal dialog that is neither an overlay nor light dismiss. It gives the user the option to keep the contents of the dialog open so they can refer to the message contents while they continue working in the parent window that raised the dialog. What I am describing is pretty much another independent Window but it might be important to differentiate for other related calls, like maybe CloseAllDialogs() (as a random example).

[marb2000]

@sylveon Q: Would that allow hosting multiple ContentDialogs in the same thread in Xaml Islands? The simple fact of allowing multiple modal Windows at the same time in an app blows up my mind. Can you describe the scenario where this is needed? I am adding @stmoyes, who is taking care of this control.

@mdtauk Thanks for the link to the design topic. I'm not evaluating to change the behavior but the underneath implementation and have a much initiative API surface. If you don't mind, I would love to scope this discussion to the modal-top child Window topic and the consequences of making this decision. About adding new behaviors to the ContentDialog, @stmoy should sponsor it.

@ShankarBUS Q: But if it is modified as a model window, would it still have rounded corners, shadows, overlay? Yes. You can do the rounded corners and overlay today with the Win32 APIs. Shadows are a little more controversial, possible, but we have some challenges today.

Having two controls is another path, but honestly, I'm not too fond of it. If WinUI already has a Control for content dialogs, we should extend it or readjust it. Having two controls is adding more confusion to the developers and creates additional maintenance costs.

[ShankarBUS]

Hey @marb2000,

I understand the complexity of maintaining multiple controls with similar features.

But....

1. If the modal-ContentDialog would look exactly the same (with rounded corners, shadows. I know its possible I mostly work with WPF and I'm aware of borderless transparent windows but will be exhausting to new users) but above the window it will be okay, since the UI would look the same and Devs don't need to adjust anything. I support this with my whole heart. Also adding a Owner property will be a good idea. It can also automatically choose the active window in the application and use it as owner

2. If the modal-ContentDialog would look like a traditional MessageBox (Win32) with title bar, caption buttons and old look but with xaml content, isn't it an ordinary xaml window parented to a requested window (in WPF ShowDialog API is used for a normal window to function as a modal window). Win32 Devs can just use any window as a modal window today. They can just use any xaml window as a modal window (maybe if WinUI would allow multiple xaml windows). Why would they need a modal-ContentDialog? Any users can do this kinda task, this is easy as hell in WPF. Adjusting ContentDialog will require more work than what I proposed a separate ModalDialog control (just normal xaml window with a ShowDialog[Async?] method and a Owner property, see not so hard, even new users can do this if the hWnd is known).

[ShankarBUS]

Hey @marb2000,

Ignore what I said above

# 1. Is not possible since WinUi doesn't yet support transparent borderless window

# 2. Adjusting ContentDialog is a more viable option since it has Primary, Secondary buttons and many API which can't be reproduced easily while creating a new ModalDialog control.

The modal-ContentDialog will look same UI wise but will be a top-level child window parented to a requested Owner window instead of overlay the xaml content like now, is this your proposal? I am okay with it since it will require less work 😅.

But how will the users decide if it should be top-level child window or a xaml content overlay?

What you proposed is good in a proper perspective 👏👏👏. Go for it.

May be if WinUI support custom window styles, title bars and window chromes in the future, modal-ContentDialog can be modified to look exactly like how it is now with rounded corners and shadows

[Poopooracoocoo]

@ShankarBUS (in response to your first comment) It's really up to the Windows shell team to implement rounded corners and to modify the shadows of windows. They should do that but they unfortunately rejected that. Microsoft doesn't want consistency lmfao

[ShankarBUS]

So here are my ideas

What @mdtauk, proposed is genius but it wouldn't allow a top-level non-modal dialog like @jtbrower said

So may be do it like this :

ViewMode

ContentDialog.ViewMode = Overlay (or) TopLevelChild?

• The Overlay option would allow users to host the dialog inside the window and above all xaml contents just like now

• The TopLevelChild option would allow users to host the dialog in a top-level child window

Behavior

ContentDialog.Behavior= Modal (or) NonModal? (or) LightDismiss?

• The Modal option would allow users to disable user inputs to just the window (if ViewMode is Overlay) or all windows in the Application (if ViewMode is TopLevelChild)

• The NonModal option would allow users to keep doing things while the dialog is still showing (Only for TopLevelChild mode. This won't be a good idea in Overlay mode and can dismiss the dialog when lost focus or clicked outside)

• The LightDismiss option would allow users to dismiss the dialog if lost focus/clicked outside the dialog/the dialog window is deactivated (Will work for both Overlay & TopLevelChild mode)

Important Notes :

Make the ViewMode & Behavior property not changeable once the dialog has been shown and it can throw some exception if tried to do so. This will ensure a proper UX

---

@marb2000 Q: What parent XAML Window will host the ContentDialog top-level child window. Desktop WinUI 3 apps can have multiple Window objects in the same thread. So, do we need new APIs?

A: A new Owner property which will have a Window as value (instead of a FrameworkElement as in the Parent property) can be introduced, this should solve what @jtbrower said. It can also automatically use the active window or the find window it finds in the Application as the Owner if not specified. Also, it can be passed like @marb2000 proposed contentdialog.ShowAsync(mywindow);

[ShankarBUS]

@ShankarBUS (in response to your first comment) It's really up to the Windows shell team to implement rounded corners and to modify the shadows of windows. They should do that but they unfortunately rejected that. Microsoft doesn't want consistency lmfao

Hey @poopooracoocoo, come on man as a developer we know how hard it is to have consistency it may be code or UI. I do agree with you because even the shell and inbox apps are so inconsistent 😅😂🤣. They are not a small organization but a multi-billion dollar company. They are internally segmented and are busy doing their tasks. They do what they can. What change would it make if Windows 10 becomes consistent the next moment. Everyone will be happy for an instant and move on with their lives. You want them to work their asses off just for a consistent UI which may evolve individually over time and will still be inconsistent. 😂😂😂 Huh? Just for an instantaneous happiness?

[mdtauk]

@ShankarBUS (in response to your first comment) It's really up to the Windows shell team to implement rounded corners and to modify the shadows of windows. They should do that but they unfortunately rejected that. Microsoft doesn't want consistency lmfao

What you are asking for requires a lot of underlying changes to the shell. Windows 10X is doing a lot of that, but Microsoft is reluctant to do anything that breaks compatibility, and so much Windows software handles their own window chrome, that making a wholesale change becomes very difficult.

Until then minor changes can only happen to apps that don't modify their windows, for new apps that can be built with WinUI 3 as it's an opt in, or apps that are rewritten.

[robloo]

I've always considered it an improvement to have ContentDialog just overlay on top of the underlying window. It seems a lot simpler to handle as well. Seems like the correct solution would involve setting XamlRoot automatically. It should be behaving just like UWP. If that's not possible, better error messages as people learn are key.

[robloo]

@marb2000

Q: Would that allow hosting multiple ContentDialogs in the same thread in Xaml Islands? The simple fact of allowing multiple modal Windows at the same time in an app blows up my mind. Can you describe the scenario where this is needed? I am adding @stmoyes, who is taking care of this control.

Also see this discussion: https://github.com/microsoft/microsoft-ui-xaml/issues/1679

[Poopooracoocoo]

@mdtauk

Microsoft is reluctant to do anything that breaks compatibility

but they won't even update the style of the radio buttons. Microsoft updated many controls for Windows 8 and updated them again for Windows 10. They introduced a new style for radio buttons in WinUI but didn't restyle it in other frameworks.

and so much Windows software handles their own window chrome, that making a wholesale change becomes very difficult.

as for the rounded corners, I was thinking of Windows 7. Microsoft also has control over Electron now and quite a bit of control over Chromium's integration with Windows. They could do a lot for consistency if they tried. Microsoft isn't going to use WinUI 3 for File Explorer. please let me be wrong

@ShankarBUS yeah I do want instantaneous happiness. I'm very unhappy in my life for various reasons. Oops. ahem. Anyway, it'd be great for Microsoft's own products like Office. Apple has gotten their inbox apps to use native system controls (except the App Store I guess) and with Big Sur, their Catalyst apps now fit right in. Microsoft's rounded corners thing is half-arsed and I honestly completely doubt that they've committed (like any company nowadays smh). Maybe consistency doesn't matter as you said. idk

[sylveon]

@marb2000 my app lives in the tray, and through the tray icon the user can open multiple dialogs to alter various settings. Consider the scenario where:

• User opens window A and alters some settings in that window
• User opens window B and alters some settings in that window
• User presses close button in window A, triggering a ContentDialog asking if changes wants to be saved
• Without interacting with the ContentDialog, user presses close button in window B

If both windows are hosted in the same thread, the app will crash at the last point because there can only be 1 opened ContentDialog per thread (at least in Xaml islands).

So now, I am forced to host windows in 1 thread per window, which involves some costly (in performance, correctness, and maintainability) thread synchronization/switching to implement the same features that would have been trivial if all windows where in the same thread.

[mdtauk]

@mdtauk

Microsoft is reluctant to do anything that breaks compatibility

but they won't even update the style of the radio buttons. Microsoft updated many controls for Windows 8 and updated them again for Windows 10. They introduced a new style for radio buttons in WinUI but didn't restyle it in other frameworks.

and so much Windows software handles their own window chrome, that making a wholesale change becomes very difficult.

as for the rounded corners, I was thinking of Windows 7. Microsoft also has control over Electron now and quite a bit of control over Chromium's integration with Windows. They could do a lot for consistency if they tried. Microsoft isn't going to use WinUI 3 for File Explorer. please let me be wrong

Add me to the list that would like to see all common controls given a WinUI do-over | as well as altering the WinUI windowing model to allow for rounded corners, transparency and other customisations.

Changing the current window chrome for rounded corners, will mean enabling it for coloured titlebars, as well as Acrylic and whatever future materials get added to the Fluent design repertoire.

[michael-hawker]

🦙 based on the Win32 dialog guidelines here:

Modal dialog boxes require users to complete and close before continuing with the owner window. These dialog boxes are best used for critical or infrequent, one-off tasks that require completion before continuing.

I don't think the default should be a 'modal' option for a dialog. Definitely like @mdtauk's suggestion of having different modes like overlay, light dismiss, and modal for how it should behave, but think the existing UWP behavior of an overlay should remain the default.

[robloo]

Add me to the list that would like to see all common controls given a WinUI do-over | as well as altering the WinUI windowing model to allow for rounded corners, transparency and other customisations.

Yes, I've been disappointing as well with what I've seen with windowing in WinUI 3.0. It seems like it's hacked together on top of Win32 and instead it should be a re-designed API that supports all features moderns apps require. This is all just my impression without having tried it out yet.

[mdtauk]

Add me to the list that would like to see all common controls given a WinUI do-over | as well as altering the WinUI windowing model to allow for rounded corners, transparency and other customisations.

Yes, I've been disappointing as well with what I've seen with windowing in WinUI 3.0. It seems like it's hacked together on top of Win32 and instead it should be a re-designed API that supports all features moderns apps require. This is all just my impression without having tried it out yet.

I am presuming the current UWP windowing is also built on top of Win32 - but that is likely closed source in the OS - and this new API is open, using public Win32 access, and needs to work for both UWP and WinUI Desktop scenarios.

The fact it is open, means it can be improved. A custom Titlebar should be job one, so UWP's customisation of the Titlebar is possible for Win32 - then WPF's windowing capabilities ported.

After that, its about supporting modal windows, tool windows, and all those modern windowing features teased back at Build 2018

[mdtauk]

Not directly related, but perhaps relevant for the future... #885 #2313 (My own Task Dialog proposal)

Whatever modal top-level window is coded/designated for this - could it be extended to other future modal control proposals?

[eugenegff]

@marb2000 Q: Would that allow hosting multiple ContentDialogs in the same thread in Xaml Islands? The simple fact of allowing multiple modal Windows at the same time in an app blows up my mind. Can you describe the scenario where this is needed? I am adding @stmoyes, who is taking care of this control.

MacOS and iOS have this feature in their windowing model, and heavily utilize it in their document-based applications.

Scenario is simple and very common. Suppose you have multi-window document based application, like Pages or Word or similar. Suppose that you want to implement asynchronous non-blocking document saving in background thread. All problems from filesystem would then be reported asynchronously, when user quite possible already works in another window. Original window need the ability to show the problem via ContentDialog, modally for originating window, but not modally for all other windows

That is a highly valuable feature - "Window modal dialog", in addition to the usual "Application modal dialog" and "Non modal dialog". Note, that "Window modal dialog" could be emulated on Win32 and WinRT if windows are running on separate threads, but not when the application is single-threaded.

This feature is implemented by AppKit on macOS https://developer.apple.com/design/human-interface-guidelines/macos/windows-and-views/dialogs/ and by UIKit on iOS, and is used by Pages and Word on those platforms. Even FileSavePicker dialog is shown as document-modal dialog, not as an application modal

We at BeLight Software needs exactly this to make our Live Home 3D application multi-document on Windows (it is already multi-document on iOS and macOS)

[michael-hawker]

Original window need the ability to show the problem via ContentDialog, modally for originating window, but not modally for all other windows.

@eugenegff this is what ContentDialog does today, show a dialog in the original window where you open it. Are you just saying you want to keep that original behavior in addition to options for more application modal dialogs? (Which in that scenario would confuse a user even more as they try to edit something in another window but are blocked from a dialog elsewhere?)

[spydacarnage]

Doesn't ContentDialog have a maximum width issue that a new window wouldn't have?

On Wed, 8 Jul 2020 at 17:31, Michael Hawker MSFT (XAML Llama) < notifications@github.com> wrote:

Original window need the ability to show the problem via ContentDialog, modally for originating window, but not modally for all other windows.

@eugenegff https://github.com/eugenegff this is what ContentDialog does today, show a dialog in the original window where you open it. Are you just saying you want to keep that original behavior in addition to options for more application modal dialogs? (Which in that scenario would confuse a user even more as they try to edit something in another window but are blocked from a dialog elsewhere?)

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/microsoft/microsoft-ui-xaml/issues/2848#issuecomment-655625456, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADIEDQMB7XCXI2BAAYIC6F3R2SNOFANCNFSM4OSFRW6Q .

[eugenegff]

Original window need the ability to show the problem via ContentDialog, modally for originating window, but not modally for all other windows.

@eugenegff this is what ContentDialog does today, show a dialog in the original window where you open it. Are you just saying you want to keep that original behavior in addition to options for more application modal dialogs? (Which in that scenario would confuse a user even more as they try to edit something in another window but are blocked from a dialog elsewhere?)

@michael-hawker Not exactly. Today you can not show second ContentDialog in second AppWindow while first is still shown - that is the main limitation.

https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.contentdialog?view=winrt-19041

Warning There can only be one ContentDialog open per thread at a time. Attempting to open two ContentDialogs will throw an exception, even if they are attempting to open in separate AppWindows.

The main purpose of window modal dialogs is to split windows into independently functioning entities, so that each can show them regardless of the state of other windows - that is how it function in other OSes.

[michael-hawker]

Thanks @eugenegff, I forgot about that limitation; Yeah, I agree being able to show a ContentDialog per window would be a key requirement.

[sylveon]

Without a thread per window.

[akash07k]

Any update on this guys? Actually I'm developing such a WinUI app which won't have a running window. It will run in background via App class only (app.xaml.cs) However, I'm hooking the keyboard and as per that functionality user will press a shortcut key and the dialog will launch. Any way to acomplish that? Obviously since there's no window for my app, I can't set the xamlroot property.

[michael-hawker]

@akash07k wouldn't you just create a window directly vs. a dialog if there's no other UI for your app?

I also want to link out to an article I found on usability as modal dialogs are generally an anti-pattern. So, want to make sure we're guiding developers to create the best experiences possible for their users.

The number of times Outlook has popped up one that has prevented me from doing something in another window and confused me as a user is countless...

[akash07k]

@michael-hawker If this is the case then why "Run" (Windows+R) opens like a dialogbox? Dialogs are more suited for some scenarios many times and rendering the dialogs oppose to the windo is much faster and quicker in my opinion. Also, I didn't find anything in the mentioned article which says that modal dialogs are anti usability pattern.

[michael-hawker]

From the article (emphasis added):

only to be promptly scolded by a modal dialog that further interrupts their workflow.

I mean the difference between a dialog and a window are pretty minute from a user perspective, so I think terms and mechanics are getting conflated with the end result for your scenario.

Currently the ContentDialog class is not a top-level window concept, it is a helper for a window. That's what this issue is about.

Yes, you want to open something that looks like a dialog for your specific app scenario, but since your app is running in the background, what you really need to do is just create a window. It'll just look like a dialog, but it doesn't have to be inheriting or using ContentDialog to do that. Users don't know/care what classes the UX they're seeing are created by.

[akash07k]

From the article (emphasis added):

only to be promptly scolded by a modal dialog that further interrupts their workflow.

I mean the difference between a dialog and a window are pretty minute from a user perspective, so I think terms and mechanics are getting conflated with the end result for your scenario.

Currently the ContentDialog class is not a top-level window concept, it is a helper for a window. That's what this issue is about.

Yes, you want to open something that looks like a dialog for your specific app scenario, but since your app is running in the background, what you really need to do is just create a window. It'll just look like a dialog, but it doesn't have to be inheriting or using ContentDialog to do that. Users don't know/care what classes the UX they're seeing are created by.

Hmm, I understand you. I'll try implementing the window. However I'm concerned about the speed. The thing which I want is that as soon as user presses the shortcut key, the Window/dialog should get displaied without further delay. (Just like run dialog) @michael-hawker

[sylveon]

Instead of creating a new window each time you could merely hide an existing one, that way showing it is instant since it's already loaded in background.

[akash07k]

Ya, I too was thinking about it

[JaiganeshKumaran]

In my opinion, no ContentDialog shouldn't be a top-level modal because of the following UX issues:

• Depending on how it's implemented, they may look like an ordinary fixed-size window but won't act like one.
• They enable more than one being shown at once, instead of one navigating to another, which gets messy very quickly.
• They can have more than one exit point (x button on the title bar) vs dialogue actions, enabling malicious behaviour.
• Not sure if this is really a problem but I personally don't like how Windows handles modal windows that are attached to a parent, unlike a ContentDialog which blurs/dims the background to let you know, there's no visual clue apart from being on top but that's inconsistent since wizards and fixed windows from other apps (or even the same app) look similar to a modal window but is not attached to the parent and is independent (you can still interact with the parent separately). The sound that Windows plays when you click on the parent window while you're inside a modal window is annoying as well.