Initializing New Application Window in WinUI Runtime Component #7383
-
When I instance a Runtime Class in a WinUI Runtime Component and try to winrt::make MyWindow or winrt::make MyFrame, initialization fails because the page resources can't be found: Exception thrown at 0x00007FFF15D8478C (KernelBase.dll) in DUALITY.exe: WinRT originate error - 0x80004005 : 'Cannot locate resource from 'ms-appx:///HV3DGUIWindow.xaml '.' . This happened whether I manually loaded the dll or if I used the Package.appxmanifest to resolve dependencies. Do I have to manually start another instance of Application in a dll to create a new Window or is there a simpler way to make this work? Aside from not opening Xaml Application Windows in dll's? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
My solution to the problem of late binding a UI in unpackaged desktop is to simply use CreateProcess to instantiate a WinUI executable that hosts Xaml UI, and to use pipes for IPC. This enables the instantiation of different suits together to act on shared data, with the added advantage of a calling process that handles shared memory management, threading, loading, failures, lifetimes, and health of different suits using scripts. I guess with the UI and the WinUI Framework, however deep this goes, you can't naturally instantiate any Xaml related content, because the load call fails to locate the resource by Uri (regardless of how you link the component), when calling from a WinUI 3.0 Windows Runtime Component. This makes sense I guess--though it should be made possible. Aside from the case given above, with its logical solution(s), when does one need to create a modular UI in a way different from the Frames and Pages navigation provided for use in the application project? UI drives logic. I guess you could implement UIElements without Xaml and construct components without a call to InitializeComponent. Sounds time consuming. |
Beta Was this translation helpful? Give feedback.
My solution to the problem of late binding a UI in unpackaged desktop is to simply use CreateProcess to instantiate a WinUI executable that hosts Xaml UI, and to use pipes for IPC. This enables the instantiation of different suits together to act on shared data, with the added advantage of a calling process that handles shared memory management, threading, loading, failures, lifetimes, and health of different suits using scripts. I guess with the UI and the WinUI Framework, however deep this goes, you can't naturally instantiate any Xaml related content, because the load call fails to locate the resource by Uri (regardless of how you link the component), when calling from a WinUI 3.0 Wind…