{"id":107560,"date":"2022-12-07T07:00:00","date_gmt":"2022-12-07T15:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=107560"},"modified":"2022-12-06T13:02:35","modified_gmt":"2022-12-06T21:02:35","slug":"20221207-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20221207-00\/?p=107560","title":{"rendered":"Reminder: If you intend to use a C++\/WinRT namespace, you must include that namespace’s header file"},"content":{"rendered":"

A customer reported that they had a working C++\/WinRT XAML app, but when they changed a hard-coded AutomationProperty attached property, to a dynamic binding, the project failed to build.<\/p>\n

The working XAML fragment:<\/p>\n

<ListView x:Name=\"InstructionList\"\r\n    AutomationProperties.Name=\"Instructions\">\r\n<\/pre>\n
But this didn’t build:<\/p>\n
<ListView x:Name=\"InstructionList\"\r\n    AutomationProperties.Name=\"{x:Bind InstructionsName}\">\r\n<\/pre>\n
The second version encountered these compiler errors:<\/p>\n
TutorialPage.xaml.g.hpp(455): C2027: use of undefined type 'winrt::Windows::UI::Xaml::Automation::AutomationProperties'\r\nTutorialPage.xaml.g.hpp(454): C3861: 'SetName': identifier not found\r\n<\/pre>\n
I used my psychic powers to diagnose that in the second version, they forgot to #include <winrt\/Windows.UI.Xaml.Automation.h><\/code> in their precompiled header file. C++\/WinRT has the general rule that if you intend to use a type, you must include the corresponding header for the namespace that defines the type.<\/p>\n
What happened here is that the x:Bind<\/code> markup extension results in XAML compiler code generation that establishes the bindings programmatically. In this case, the AutomationProperties.Name=\"{x:Bind ...}\"<\/code> caused the XAML compiler to emit a call to winrt::Windows::UI::Xaml::Automation::AutomationProperties::SetName()<\/code>. Which means that the compiler needs to know how to call that SetName()<\/code> method, and the information the compiler needs is in the namespace header file winrt\/Windows.UI.Xaml.Automation.h<\/code>.<\/p>\n
Another customer ran into a related error message:<\/p>\n
error C2039: 'Xaml' is not a member of 'winrt::Windows::UI'\r\n<\/pre>\n
Again, the reason is that the customer forgot to include the header for the namespace they are trying to use. In this case, they were trying to call the winrt::Windows::UI::Xaml::Media::Imaging::BitmapImage::DecodePixelWidth()<\/code> method, so they header they needed to include was #include <winrt\/Windows.UI.Xaml.Media.Imaging.h><\/code>.<\/p>\n
Bonus chatter<\/b>: The customer who had a problem with AutomationProperties.Name<\/code> also tried this alternative:<\/p>\n
<ListView x:Name=\"InstructionList\"\r\n    AutomationProperties.Name=\"{Binding InstructionsName}\">\r\n<\/pre>\n
This third version built successfully, but the Name property was not set.<\/p>\n
The reason for this is that the {Binding ...}<\/code> markup extension uses runtime binding rather than compile-time binding. At runtime, the binding system verifies that the binding source is bindable, and if so, looks for the property in the binding source’s metadata. For people migrating from C#, a gotcha is that C# defaults to making all objects bindable, whereas C++\/CX and C++\/WinRT require you to mark the objects you intend to bind with the Windows.UI.Xaml.Data.Bindable<\/code> attribute.<\/p>\n
[Windows.UI.Xaml.Data.Bindable]\r\nruntimeclass DataSource\r\n{\r\n    ...\r\n}\r\n<\/pre>\n
If the data source is not bindable, or the property is not present, then the binding simply fails silently.<\/p>\n
Using {x:Bind}<\/code> results in better runtime performance because all the discovery happens at compile time, and the result is code that sets properties by calling the setters directly. And it means that any typos are caught at compile time, rather than failing silently at runtime.<\/p>\n
Exercise<\/b>: Why did the second customer get an error about the Xaml<\/code> namespace, when the real problem was that they forgot to include the header for the Imaging<\/code> nmamespace?<\/p>\n","protected":false},"excerpt":{"rendered":"
Various errors that can be traced back to breaking that one rule.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"class_list":["post-107560","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing"],"acf":[],"blog_post_summary":"
Various errors that can be traced back to breaking that one rule.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107560","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=107560"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/107560\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=107560"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=107560"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=107560"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}