Floating Windows

[JohnF38]

Hello !

It would be nice to have windows that could freely float and move (I don't mean dock) within a parent one. This is extremely useful, for example, when several representations (2D, 3D, histogram,...) of the same data set are needed.

Are floating windows planned for WinUI 3.0 ?

John

[mdtauk]

There are new Windowing APIs in development. Not sure if they will make it for WinUI 3.0, or even if they are part of it, and not part of the OS.

Maybe someone can provide more info.

[Felix-Dev]

@JohnF38 @mdtauk See the Build 2019 Windows Presentation Platform session:

As you can see "windowing" is mentioned for WinUI 3.x. In the session (starting at roughly 56:00) it is said that shipping the new 1903 Window APIs in the initial WinUI 3.0 release (likely) will not happen as "it will take a little longer to get [them into WinUI]".

[YuliKl]

@JohnF38, are you looking for child windows with caption controls (minimize, maximize, close)? Or movable panels within a parent app window? What capabilities would you expect these floating windows to have? For example, in addition to moving them, should users be able to close or resize them? Would you want the floating windows to be movable outside the parent window?

[JohnF38]

Thanks everybody for your answers !

Please take a look at the screenshot below, there is a main window that is parent of several floating windows used for various representation of the dataset.

Floating window have their own menu bar for features adjustments. Each floating window is moveable, resizable and closable. Floating windows do NOT need to be moved outside their parent main window.

Thanks!

[verelpode]

My understanding is that overlapping/floating windows were deliberately excluded from UWP because they are considered to be an obsolete GUI design, and they are incompatible with the "U" in UWP. "U" for "Universal" meaning all computing devices including tablets, smartphones, desktop computers, notebooks. Floating windows are practically incompatible with touch-based devices that don't have a mouse. However, even in the case of a desktop computer with a mouse, floating windows are often NOT the best solution.

Do you want a direct honest explanation of the problem? If yes, then continue reading. If no, then stop reading here :-) Making a bunch of floating or overlapping windows is tempting for software engineers because it fits well with the important concept of components in programming. From a programming point of view, multiple windows are good, but from a user point of view, it's bad GUI. Take a good hard look at your screenshot and it can be seen that the windows neatly correspond with programming components/modules, and that is indeed neat and convenient for programming purposes, and less work to write the code, but unfortunately your screenshot is a screenshot of a bad GUI design from the point of view of users.

I once made the same mistake as you. I made an app with a GUI quite similar to your screenshot. At some point, I said to the users: "Tell me honestly, what's wrong with the app? I want to hear the bad news." I accepted the criticism from the users and I had to throw out the whole GUI design and redesign it without floating/overlapping windows. The new version was more work but the users found it much better and in the end, I liked it better as well. The users were right: The new GUI based on a single large window was indeed a superior GUI design.

The topic of overlapping windows is a historical issue. This issue is also one of the 20+ reasons why Microsoft Windows ended up gaining much more PC marketshare than Apple's MacOS. Although both Windows and MacOS supported overlapping windows, traditionally Mac apps tended to use overlapping windows much more than Windows apps. Mac apps frequently overused overlapping windows. This GUI design defect bothered a very large number of users and contributed to Windows gaining much more marketshare (among a bunch of other reasons). Apple could have responded by fixing the defects in their GUI, but instead responded with: "That's not a defect; that's a feature, but Windows users aren't intelligent enough to understand that our GUI is superior."

"Drag & Drop" was another problem associated with overlapping Windows. Apple touted "Drag & Drop" as a superior GUI, but many users found the drag & drop maneuver awkward to use when trying to drag from one window to some other overlapping/floating window, especially because it frequently required rearranging and/or resizing one or more windows before commencing the drag & drop maneuver. Cut/copy/paste often works better than drag & drop. If drag & drop is limited to use within a single window, then it can be a good solution. An app with a bunch of floating windows does not match the definition of a modern UWP app.

Again Apple could have fixed the mistake, but instead responded with: "That's not a maneuver; that's a ..... wait... is that a French word? That sounds kind of hip and difficult. Yes, drag & drop is a maneuver, but Windows users don't have sufficient dexterity to use a mouse to perform such an advanced and superior maneuver. That's why they have to resort to using copy & paste to copy files, and cut to move files."

However, to Apple's credit, when they designed the iPhone OS, they finally acknowledged that it shouldn't be based on a bunch of floating/overlapping windows. The result was that the iPhone GUI became much more popular than the MacOS GUI.

[JohnF38]

@ verelpode, thanks for such a detailed answer ! You're definitely right when you state that my GUI reflects the software insights. I have to say I'm impressed by your analysis.

Since you're obviously an expert (and I'm not ;) ) , I have to agree with your point of view. But practically speaking, how to get several data representations side by side without floating/overlapping windows ?

It would be great if you could point me toward some samples, it would help to refresh my outdated GUI. Thanks Verelpode !

[verelpode]

@JohnF38 -- I'm glad to hear that you found my analysis helpful.

Since you're obviously an expert (and I'm not ;) ) , I have to agree with your point of view.

Thanks, but actually user-friendly GUI design is not my strong suit. I'm not an expert in that department, rather I'm a software engineer who accepted critique from users and then implemented improvements, and this ended up making everyone happier including myself. Now I recognize this problem quickly and I have a good understanding of this problem, but I'm not an expert in solving this problem.

But practically speaking, how to get several data representations side by side without floating/overlapping windows ?

That's practically the same question I asked when I responded to the feedback from users. Now you've arrived at the point that I described in my previous message as "more work". There is no easy answer, and no single answer that suits all apps. I think you'll have to do the same as I did, that is bang your head against the wall repeatedly and become frustrated by the difficulty of designing the solution, but persist with it, don't give up, and after a while, crack it successfully.

It would be great if you could point me toward some samples

This week I don't have the time for samples, but I'll try to return to this issue later and post more info. You can also find helpful samples in various GUI design books in Amazon -- some books are packed with examples in the form of color screenshots and/or mockups. In my experience, GUI design books really helped me to produce better GUI.

As a starting point towards finding the solution, it'd probably be helpful to answer this question: Why did you say "I don't mean dock"? For what reasons do you reject docked windows similar to the Visual Studio IDE?

See also Show multiple views for an app and then decide whether or not it is suitable for your particular kind of app, while keeping in mind that UWP ApplicationView's can be either a full solution OR a partial solution in combination another technique.

[verelpode]

Questions for Microsoft staff in relation to alternatives to floating/overlapping windows:

ApplicationView: Why do ApplicationView's force the use of a separate Dispatcher/thread? Creating a second or third Dispatcher only makes sense in some apps, not all. When an app has multiple Dispatchers, this causes substantial extra programming work and the risk of concurrency bugs, therefore it should only be done when the circumstances justify it, but ApplicationView's force the creation of new Dispatchers. Shouldn't the creation of new Dispatchers be optional? Shouldn't ApplicationView's have the option to create multiple ApplicationView's in the one same Dispatcher?

Split panels:
WPF had System.Windows.Controls.GridSplitter, which was a very useful technique for avoiding the use of overlapping windows. Why doesn't UWP/WinUI have an equivalent of GridSplitter? This is a big problem, isn't it? Or am I missing something? For what reasons is the lack of a GridSplitter replacement not viewed as a high priority to fix?

I can certainly understand if GridSplitter should be modified or redesigned before being created in WinUI, but so far WinUI doesn't have any new version nor official replacement for GridSplitter. In my experience, although GridSplitter is good for users, the programming design/API of GridSplitter is problematic and I'd agree with anyone who says it needs changes, but is a GridSplitter replacement in WinUI even planned at all? What's the progress or priority of this?

I understand why traditional overlapping windows were excluded from UWP/WinUI, but this decision is sometimes very difficult to deal with when a GridSplitter equivalent doesn't exist. I ended up writing a custom control that operates like GridSplitter from the user's point of view, but with a very different API because of the problems with GridSplitter's API.

I should be able to reply to @JohnF38 by saying: Have you considered using GridSplitter instead of floating windows? But I cannot answer like that because GridSplitter doesn't exist in UWP/WinUI! So what should I say instead? I know that NavigationView is a good thing but it's only an applicable solution for some kinds of apps. NavigationView and SplitView replace some-but-not-all usages of GridSplitter.

At least in some apps, if you cannot use floating windows AND you cannot use GridSplitter, then no reasonable solution exists, as far as I can determine.

[jevansaks]

Shouldn't ApplicationView's have the option to create multiple ApplicationView's in the one same Dispatcher?

Starting in 19H1 you can use the AppWindow API to create multiple windows on the same thread.

Why doesn't UWP/WinUI have an equivalent of GridSplitter? This is a big problem, isn't it?

190 has some discussion of these proposals. The UWP community toolkit has a GridSplitter and we've discussed bringing that into WinUI as well, we just haven't had the time.

[verelpode]

@JohnF38 Consider also BladeView. Even if you end up deciding that BladeView doesn't suit your particular app, you'll still get a benefit anyway, because thinking about BladeView will expand your GUI perspectives and it may also serve as inspiration. Solutions are sometimes found via an indirect path or researching around the issue instead of directly.

[JohnF38]

@ verelpode 👍 Thanks so much for all your advices !

[verelpode]

@JohnF38 To clarify, even though I find the current design of GridSplitter problematic, and the unofficial GridSplitter in Community Toolkit has the same problematic design, you could still use it anyway. It's still usable, and the problems mainly impact us programmers rather than the end-users. It has unexpected quirks, such as when trying to limit the user to a minimum pane size without breaking compatibility with a small app window size, etc. But in general it's a good idea from the user's point of view.

[mdtauk]

Many applications have pull out panels that dock to the sides of the app window, but also can be pulled out into floating Windows

[michael-hawker]

@verelpode would you mind summarizing the problems you have with GridSplitter as a new issue for the toolkit?

I've been wanting to make some improvements along with an alternate type of splitter I created for XAML Studio, but I haven't had a chance to work on them.

@jevansaks should there also be an issue here in WinUI about GridSplitter being part of WinUI?

[MarkIngramUK]

@verelpode The "Universal" part of UWP is now dead. It was a grand idea, allowing any application to run on Desktop, or Tablet, or HoloLens, but in reality - what applications would that actually work for? The huge compromises that would be required make it unfeasible to work with. We make professional desktop applications, and our users demand floating windows (and documents) and support for multiple monitors so they can be productive. We can't compromise the power of our applications on the off chance someone would want to run it on HoloLens.

I appreciate that for some applications, there are better approaches than floating windows, but the API shouldn't restrict for that, and instead the developers should be given the tools and allowed to decide what is best for their customers.

Anyway, I don't want to bring this discussion off-topic, so I'll re-link to @jevansaks answer: https://github.com/microsoft/microsoft-ui-xaml/issues/1080#issuecomment-514700655

[verelpode]

@jordui

Floating/Docked windows are a must-have and can be achieved with XamlIslands.

I'm confused by your comment. Did you accidentally say XamlIslands instead of some other tech? XAML Islands are not for the purpose of creating floating nor docked windows. XAML Islands are for the purpose of using UWP Controls (especially WebView and InkCanvas) in older WPF apps. XAML Islands are very helpful for migrating large WPF apps to UWP. We're using XAML Islands in the migration of our apps. It's not a feature intended for creating floating windows.

@MarkIngramUK

The "Universal" part of UWP is now dead. It was a grand idea, allowing any application to run on Desktop, or Tablet, or HoloLens, but in reality - what applications would that actually work for?

Again I'm confused and so I wonder if you mean something else when you say "UWP", because it seems like you and I are talking about different things when we say "UWP". Click the Start menu in Windows 10, then click the icon labelled "Microsoft Store", and you'll see thousands of apps. Most of those are UWP apps, and they run on Desktop, Tablet, etc. The UWP version of Microsoft OneNote is yet another example of a Universal Windows app that runs on Desktop, Tablet, etc. You ask, "What applications?" and the answer is "thousands". Back in September 2015, Microsoft wrote:

"There are 669,000 apps for phones, desktops, and tablets in the Windows Store. Hundreds more are added every day."

We make professional desktop applications, and our users demand floating windows (and documents) and support for multiple monitors so they can be productive. We can't compromise the power of our applications

Oh I believe I understand now. You're actually talking about Windows Phone 8, aren't you? UWP is not WP8, but the point of confusion is that UWP was originally derived from WP8, but nowadays there is a large difference between WP8 and UWP. I understand your complaints in regards to WP8 -- yes, understandably, you can't compromise the power of your applications by accepting the limitations of WP8, but that's now irrelevant because WP8 is gone, and today's UWP doesn't have the limitations of WP8. Your comment "We can't compromise the power of our applications" was applicable in the past but that was WP8 not UWP. I hope this helps clear up the confusion.

[MarkIngramUK]

@verelpode,

XAML Islands are not for the purpose of creating floating nor docked windows

No, but with Win32 (or WinForms / WPF) and XamlIslands you can achieve modern UI and floating Windows, prior to the AppWindow API in UWP.

then click the icon labelled "Microsoft Store"

Thanks - our 3 apps are already in the store, so I'm pretty familiar with it :-)

You're actually talking about Windows Phone 8, aren't you?

No :-)

The point I was trying to make is: If your customers want floating windows, use them, if they don't, don't use them. But that decision shouldn't be dictated by the availability of the APIs. Anyway, this is all a bit off-topic now, considering that floating Windows are now available in UWP.

[verelpode]

@MarkIngramUK -- UWP's ability for multiple windows is not new. I mentioned ApplicationView in a previous message. ApplicationView was introduced in Windows v10.0.10240, released during 2015. To me, your description sounded like an understandable complaint about WP8 (2014) but not UWP.

Check out this screenshot of the UWP version of Microsoft OneNote -- notice the "New Window" button in the "View" tab. UWP OneNote runs on desktop, tablet, smartphone.

[MarkIngramUK]

@verelpode, yes, it will launch a new window attached to a different UI thread (and on the desktop, with a new app icon in the Taskbar).

[verelpode]

@MarkIngramUK -- and you dislike the different thread? I agree with you. I complained about this threading issue already in my previous message. Thankfully jevansaks then pointed out that this issue is solved starting in version 19H1.

However, I wouldn't recommend that @JohnF38 solve his particular issue by using the new AppWindow API. My suggestion is that he can consider upgrading to one of the new/modern GUI design techniques and avoid excessive use of multiple windows. The issue of multiple windows is not a yes/no or black/white issue, rather it's a matter of finding a reasonable balance in the use of multiple windows -- use them where appropriate but avoid overuse, and think about compatibillity with modern touchscreen-based tablets and smartphones.

[JohnF38]

Hi everybody, I wasn't expecting my question would trigger such an avalanche ! :)

@MarkIngramUK : Ok understood, it's not a black/white issue.

So, let's consider a "careful" use of floating windows:

• Do you think WinUI is actually an appropriate choice for a new 100% desktop application ?

I'm not an expert in GUI design. Just a guy that comes from the wxWidgets world and who's wondering what would be the best.

Thanks to all of you. John

[verelpode]

@JohnF38

Do you think WinUI is actually an appropriate choice for a new 100% desktop application ?

Definitely (except in very special cases). When you make a new project in Visual Studio 2019, you have the choice between these project templates:

• "Blank App (Universal Windows)"
• "WPF App (.NET Framework)"

For a new app, I would definitely choose the Universal Windows template, because if you choose WPF, then you'll suffer the burden of having to migrate your WPF app to Universal Windows, either now or later; eventually unavoidable at some point. Depending on the size of the app, this migration/upgrade can be a big time-consuming job. Even if you end up deciding to create lots of windows, you still don't require WPF because new AppWindow class, version 19H1, as people said.

In very special cases, if you absolutely must have a special feature that is only available via WPF app, then you could choose the WPF project template but still mostly write the app as a Universal Windows app by using the new "XAML Islands" feature to mix WPF and Universal in the one app, but that's undesirable extra complexity/burden. XAML Islands is mainly for the purpose of progressively migrating preexisting large WPF apps to UWP, not intended for new apps. In my personal opinion, I certainly would NOT use/abuse XAML Islands as a contorted way of creating multiple windows in a UWP app.

[verelpode]

@michael-hawker

would you mind summarizing the problems you have with GridSplitter as a new issue for the toolkit?

OK, I've opened issue #2976.

[mdtauk]

Have you taken a look at the Windows.UI.WindowManagement.AppWindow API, it creates a window, I believe on the same thread.

Building powerful desktop and MR applications with new windowing apis

---

Not sure if this remains part of the OS or WinUI or bits in both, but that will be how it is handled going forward.

[verelpode]

Re the comments about docked windows, note that AppWindow is unnecessary for creating a so-called "window" in a docked state.

Dock + Auto Hide:

If the "docked window" should be temporarily shown when a "docking tab" is clicked, meaning like the "Dock" + "Auto Hide" options in Visual Studio, then this effect can be achieved by using Flyout. See also the behavior options available via FlyoutBase.ShowMode.

Dock:

If the "docked window" should be constantly visible (if it should not auto-hide), meaning like Visual Studio's "Dock" option without enabling "Auto Hide", then this effect can be achieved by creating a resizable pane with the help of GridSplitter.

Float:

If you insist that it's really necessary for your app to have functionality similar to Visual Studio's "Float" option, and if (as @JohnF38 said) floating windows do NOT need to be moved outside their parent main window, then this effect could be created with the help of Windows.UI.Xaml.Controls.Primitives.Popup but I wouldn't recommend it.

[contextfree]

The point I was trying to make is: If your customers want floating windows, use them, if they don't, don't use them. But that decision shouldn't be dictated by the availability of the APIs. Anyway, this is all a bit off-topic now, considering that floating Windows are now available in UWP.

Just to note, multiple floating windows have always been available in UWP for as long as it's been called UWP (i.e., since launch Windows 10), though the APIs and support has gotten more flexible over time. Even back in Windows 8.1 when they were still called Metro-style apps they supported multiple windows in splitscreen (which is how UWP windows still work in tablet mode).

[michael-hawker]

@JohnF38, @verelpode

@JohnF38

Do you think WinUI is actually an appropriate choice for a new 100% desktop application ?

Definitely (except in very special cases). When you make a new project in Visual Studio 2019, you have the choice between these project templates:

• "Blank App (Universal Windows)"
• "WPF App (.NET Framework)"

If you do create a new WPF app, pick the .NET Core option over the .NET Framework one!

[verelpode]

@michael-hawker -- Although I can think of reasons to choose the .NET Core option over Framework, I don't know the best reason. What's the best or most important reason? Earlier access to improvements?

[michael-hawker]

@verelpode the OSS version of WPF is the .NET Core one; so yup, you'll get better access to improvements.

Also, next year when .NET 5 releases, it'll be mainly converging from the .NET Core side, so you'll have an easier time upgrading from a .NET Core project base than a .NET Framework one.

.NET Core, in general, also has improvements for packaging and performance. @azchohfi is there a good link you have to a talk or paper on these topics?

[azchohfi]

I recommend this presentation on Channel 9: https://channel9.msdn.com/Shows/On-NET/Supporting-Windows-Forms-and-WPF-in-NET-Core-3

[verelpode]

@michael-hawker @azchohfi Thanks for the helpful video! Re the project templates, I just checked and VS 2019 (16.2.0) does not have any project template named "WPF App (.NET Core)".

• Exists: "Console App (.NET Core)"
• Exists: "WPF App (.NET Framework)"
• Does not exist: "WPF App (.NET Core)"

Maybe I need to tick something in VS Installer, but I looked through the list and everything seems to be already ticked correctly. Maybe I missed ticking something or maybe the template truly doesn't exist?

EDIT: I found this answer:

Visual Studio 2019 supports .NET Core 3.0 projects but has limited support for the .NET Core WPF visual designer. To use a fully-supported visual designer, you must have a .NET Framework WPF project in your solution that shares its files with the .NET Core project.

@JohnF38 -- see the difficulties? So if I was you, I would select the Universal Windows template, not WPF, in the case of a new app. However, in my job, different situation, I must deal with WPF and the helpful XAML Islands because of preexisting enterprise apps and special requirements.

[michael-hawker]

@verelpode they're still rolling in support as .NET Core 3 isn't set to release until the end of September. I think the project templates show up once you install the .NET Core 3 SDK that or it requires the VS 2019 Preview.

@azchohfi isn't the WPF designer supported now for .NET Core? I feel like that note is out-of-date?

[azchohfi]

It's on preview versions of VS, yes. But for a fully supported with stable version of VS, you need the hack with the .net framework proj. You need to enable preview versions of .net core on the preview tab on VS settings.

[verelpode]

@JohnF38 -- By coincidence, today I happened to have the chance to see an app in a medical practice, and it reminded me of your screenshot, except that it didn't use multiple windows. It had multiple charts like your screenshot. Instead of making 18 separate windows, they used a TabControl/TabView (for example look at TabView in the Community Toolkit). All of the 18 tabs were pre-created and pre-named and the user could not create any new tabs, rather the purpose was to allow users to click any tab to view the charts in that tab, instead of using 18 separate windows.

On one of the tabs, 4 charts were displayed simultaneously. Interestingly, there was a simple button that you could click to swap the chart on the left with the chart on the right. Simply clicking this button was much easier and faster than if the software was written with many separate windows. If the charts were in separate windows, you'd have to do the following to swap the left and right charts:

1. Drag the right-hand window to the left.
2. Drag the left-hand window to the right. But this is awkward to do because in the previous step, you covered up the left-hand window.
3. The previous 2 steps didn't really work because one window landed on top of the other window, so in this step, try again -- shuffle the windows around multiple times until you achieve the goal of swapping the left window with the right window.
4. It might now be necessary to resize the left window.
5. It might also be necessary to resize the right window.

Wow those steps are really awkward. In contrast, the medical practice app had the button that you could simply click and BAM! the left and right charts were instantly swapped -- much quicker and easier than dealing with separate windows.

Unfortunately I don't have photos for you, but hopefully the above description will give you good ideas.

[EasifyDev]

As usual true MDI (floating child windows) gets flamed as old fashioned and a poor choice of GUI by people that have no idea as to when it is appropriate to use it.

There are many use cases where MDI is the perfect choice (take a look at FL Studio Digital Audio Workstation). Complex application such as this are very well served by the concept of floating windows, as you often need to run many tools simultaneously, all of which are different and could not be displayed in docked panes or tabs without becoming extremely clunky.

Have a look at Photoshop. The lack of MDI has really ballsed up that UI. Now if you have 15 open images they aren't all contrained within the parent window, and if you also removed drag and drop it'd just make the experience more clunky.

For anything you use a finger for (tablets, touch screens, phones etc...) tabbed and docked windows and a lack of drag and drop make sense.

However there are still desktop power user applications that benefit from floating windows (MDI) design.

Really the designer should have a choice as to whether to be able to use MDI, simply removing the choice and branding it "old" or "poor design" is a misguided, unhelpful and dogmatic view.

[MarkIngramUK]

MDI is useless in multi-monitor scenarios. I was using Spy++ today, which is MDI and I forgot how irritating it is to be constrained like that.

[EasifyDev]

MDI is useless in multi-monitor scenarios. I was using Spy++ today, which is MDI and I forgot how irritating it is to be constrained like that.

A decent MDI implementation (e.g. FL Studio) allows for any MDI child to be detached and dragged to any monitor. It's easy in code to allow MDI children to exist outside of the parent.

[hhoefle1]

Since 2011 I use the MDI (Floating Window) from Jjevgenij Pankov for my Silverlight-Framework and also for my own WPF .Net Core 3.1 Framework right now. The MDI (Floating Window) for WPF and Silverlight is available at https://github.com/Zoomicon/ZUI I will reuse the MDI (Floating Window) in WinUI 3.0 by migrating the SilverFlow.Controls-Project from my WPF Core 3.1 Framework to my new WinUI 3.0 Framework by the end of this year.

My WPF .Net Core 3.1 Framework with the MDI (Floating Window) support through the SilverFlow.Controls-Project:

[mdtauk]

This could work with the TabView when tearing and recombining tabs and Windows

[ccarlo88]

@verelpode I hate getting into endless discussion in GitHub because it is very likely that I won't get what I need. 😄 I agree with you on the point that it is an old design but I have a similar issue as @JohnF38 has and the users wants to have multiple floating windows and (unfortunately) I have to agree with them. I like "modern next century" designs but in some cases usability is really much more important.

People nowadays tend to think everything is being done in a Mobile device, people are confusing the meaning of "productivity" (desktop) with "convenience" (mobile).

Imagine Windows right now that the user cannot have floating windows anymore and instead it has just a tab and you cannot put it side-by-side in a way that it suits you.

[Shadowblitz16]

I would like to see support for hosting a window in a scrollable panel. mainly because its good for single small/single monitors but also because it can be used with other gui patterns like docking.

[JohnF38]

Hi everybody !

I definitely agree with @EasifyDev ,
Floating Windows provide invaluable flexibility when it comes to reorder windows or put several alongside for comparison.

Although I've tried the 'Tab Option' , usability was really poor. It would be great not to forget traditional Desktop applications developers ... ;-)

Regards, John

Oh yes, pleeeease : release decent control use examples for C++/WinRT !

[MaximMikhisor]

+1

[gautambjain]

I just want to re-initiate this and as if WinUI 3 will allow me to create sticky notes kind of app. Meaning several popup windows on the desktop irrespective of whether the main app window hidden or visible?

Can someone throw light on this please?

[codendone]

@gautambjain Yes, if you want separate windows which can be placed on separate monitors, you can just new up a separate Window for each.