microsoft-ui-xaml
microsoft-ui-xaml copied to clipboard
microsoft
Unable to set Window Title in XAML
Describe the bug
In WinUI3preview3, unable to build a project if set the Window Title in XAML.
Steps to reproduce the bug
- Create a new
Blank App, Packaged (WinUI in Desktop) - Change the content of
MainWindow.xamlto add the following on line 8
<Window
x:Class="App68.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="using:App68"
xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
Title="my app"
mc:Ignorable="d">
- Build the solution
- See an exception:
MainWindow.xaml(8,5): XamlCompiler error WMC0612: The XAML Binary Format (XBF) generator reported syntax error '0x09C4' : Property Not Found
- Remove the change in the XAML file and set the window Title in the constructor. e.g.:
public MainWindow()
{
this.InitializeComponent();
this.Title = "my app";
}
- Run the app and see the title displayed correctly.
Expected behavior
It should be possible to set the Window Title in XAML.
Screenshots
Version Info
NuGet package version: Microsoft.WinUI 3.0.0-preview3.201113.0
Windows app type:
| UWP | Win32 |
|---|---|
| Yes |
| Windows 10 version | Saw the problem? |
|---|---|
| Insider Build (xxxxx) | |
| May 2020 Update (19041) | Yes |
| November 2019 Update (18363) | |
| May 2019 Update (18362) | |
| October 2018 Update (17763) | |
| April 2018 Update (17134) | |
| Fall Creators Update (16299) | |
| Creators Update (15063) |
| Device form factor | Saw the problem? |
|---|---|
| Desktop | Yes |
| Xbox | |
| Surface Hub | |
| IoT |
Additional context
@ocalvo FYI, who was it that finished up the title bar work in winui3?
Still broken in 1.0-experimental1. @marb2000 We're not going to ship 1.0 with the inability to set the window title right? RIGHT? 😂
There is an (ugly) workaround though. In your Window sub class add this:
/// <summary>
/// Gets or sets the window title.
/// </summary>
public new string Title
{
get => base.Title;
set => base.Title = value;
}
I had to apply that workaround to WinUIEx well: https://github.com/dotMorten/WinUIEx/blob/86c86233512565873ffc413342dd88ed04dbca14/src/WinUIEx/WindowEx.cs#L81-L88
However I'm worried that the lack of window management APIs and Title can't even be set from XAML as we're used to is going to be extremely off-putting to users. Is the amount of code you need to write acceptable, just to do basic management of your window, in a v1.0 release? (hint: I don't think the answer isn't yes).
I'm worried people will take one look at WinUI and see that basic window management APIs are more or less non-existent (or as shown above overly complicated to use), and write off WinUI before it even had a chance.
@dotMorten 🤠 It's pretty ridiculous that this still blows up XAML with an obscure error. But agreed. 👍
I had started writing WinUIEx as a temporary stop-gap to the lack of Windowing APIs, but hadn't bothered completely finishing it up or publishing a nuget, because I naturally assumed basic Windowing APIs would be in 1.0, and I was also reluctant because the entire implementation just feels like one giant band-aid. It seems like I need to do bring this all the way to at least close some of these obvious gaps for 1.0.
Still... present in Preview 1. They got less than two months to fix this.
Don't think this is getting fixed any time soon, now that there's a workaround. 😞
It's still broken. I'm currently using the constructor method for temporary fix.
this.Title = "App Title";
Unfortunately, per the latest engineering plan, the bug fix won't make the v1.0 Stable release (GA) and was moved to v1.1
This is ridiculous as a so basic function doesn't work on the official version 1.0.
Yep, just decided to try UWP and WinUI but this thing is just horrible to work with. Back to good ole win32 it is
Not sure if directly related but when using MAUI blazor app template targeting Windows, title doesnt seem to work either from setting in xaml or ctor of mainpage.
Similar to what olabacker found, when using a .NET MAUI App template targeted on Windows the title won't appear when defined either in MainPage.xaml or in MainPage.xaml.cs.
I tried adding dotMorten's snippet to MainPage.xaml.cs and setting the property in the constructor, but still no title appeared. As this template produces a WinUI app, presumably it's the same problem.
Apps for scientific data processing can use upwards of 50 forms and dialogs in old Windows Forms app speak, having a form or window title is essential otherwise the user won't know where they are or how what they are seeing relates to documentation..
Are you serious? You can't even set title in WinUI3 app?
EDIT:
I have set it programatically in App.xaml.cpp and it worked. Seems like an XAML only issue.
window = make<MainWindow>();
window.Title(L"My title");
window.Activate();
I have set it programatically in App.xaml.cpp and it worked. Seems like a XAML only issue.
Which is exactly what the first post says. But yeah, that's just one of the wonderful experience developers get when they try out WinUI.
Just tried with the latest v1.1.0-preview1 and still doesn't work. And to make matters worse, the error message is extremely unhelpful with no indication about what property or where:
1>MainWindow.xaml(8,22): XamlCompiler error WMC0612: The XAML Binary Format (XBF) generator reported syntax error '0x09C4' : Property Not Found
If you can't fix it, at least fix the error message.
Perhaps MainWindow Title was purposefully left out for a while so engineers would have practice implementing WinUI3 properties. Is it a coincidence that the main C++ bind example is a Title property? :-) https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/binding-property
I use C++ coming from C# XAML, so I'm finding this to be a great exercise. :-)
Welp still not fixed. I think we'll have to wait about at least 5 more years for this issue to be fixed cause apparently there are other 2.7k current open issues.
@soobakjonmat I agree this is annoying. But it is by no means a showstopper like many other issues. You can still set it in code behind or use something like WinUIEx’s WindowEx to do it.
@soobakjonmat I agree this is annoying. But it is by no means a showstopper like many other issues. You can still set it in code behind or use something like WinUIEx’s WindowEx to do it.
Yeah I'm just saying that it's probably gonna take a while to get it fixed. I'm using this.Title = so no problem there.
And while reading my own comment again, it does sound sarcastic and apologies for that. I guess I was a bit grumpy while I was writing that comment cause I haven't slept all night on that day.
Maybe it's worth mentioning that the workaround for C++ looks like this:
MainWindow::MainWindow()
{
InitializeComponent();
this->Title(L"Your Window Title");
}
I think we have been making a XAML Title assumption for WinUI based on WPF experience. Code samples here imply that Title in XAML is not intended, and by leaving it out of XAML, we are led to discover the Title Bar capabilities: https://learn.microsoft.com/en-us/windows/apps/develop/title-bar?tabs=wasdk
I.e.: I think that we have a "Works as intended" status here.
I think it’s a reasonable assumption. What I think went wrong here is the window is a non-WinUI window without the WinUI stuff in it (like inheriting from Dependency Object, understand styling etc). WinUI should make its own Window type that wraps the underlying Windows App SDK window and provide a proper developer experience that’s expected in 2022. I don’t buy the argument that it is as designed and existing expectations aren’t valid - if you want people to move over you need to provide an experience at least on par. The entire Window class is a mess to work with and needs something designed properly for the xaml developer.