MediaPlayerElement - WinRT Xaml Island

[MattyD]

Hi all, I'll try to keep this succinct...

Since windows 10 1903 it has been possible to embed UWP controls (i.e. XAML controls) in win32 apps. The container that holds a XAML control is a XAML Island.

For non-legacy media playback, Microsoft tells us to use the WinRT MediaPlayer object with the MediaPlayerElement control. MediaPlayerElement is the UI & video rendering component of the player (the XAML control). The other MediaPlayer object is the bones of the player which you attach to the control.

To get this working you annoyingly need to add the maxversiontested element to the application manifest. I used mt.exe from the Windows SDK to patch a copy of AutoIt3.exe & AutoIt3_x64.exe. So this lets you run things as normal from scite with the F5 key.  The "win10.manifest" file that I used is included in the zip. 

.\mt.exe -manifest "C:\Program Files (x86)\AutoIt3\Win10.manifest" -outputresource:"C:\Program Files (x86)\AutoIt3\AutoIt3_x64-Mod.exe;#1"

Edit: Or if you just want to see the result!

 

PS. As an aside, Another way of approaching modern playback is via MediaEngine which we've recently attempted to get going.  This approach doesn't play well with autoit though, and you need to do ungodly things to prevent callbacks from crashing your script!

MediaPlayer.zip

 

Edited 4 hours ago by MattyD

[SOLVE-SMART]

Well done @MattyD, thank you 👍 . Oberviously you had to generate (write) many code.

What bothers me a little bit are the many dependencies that you have to include in the projects, "just" to use WinRT MediaPlayer object or XAML controls.
I know there are not much alternatives, but this is the point why I would not use it 😔 .

Spoiler

Don't get me wrong, I appreciate the work and the solution for the use case, but I don't really like it.

Best regards
Sven

[MattyD]

yeah fair enough, totally get where you're coming from.

Just to explain though - this uses libraries from the WinRT project which literally has thousands of objects wrapped.
The folder structure is a way for me to drop objects in and out of a project without definitions getting in the way of each other. So we could probably boil all this down to a single header - but it will only be useful for this implementation.   So the setup is more for me I guess!

There are Interface tags in all the interface libraries. So for a more traditional approach with ObjCreateInterface()  I'd probably extract all those and dump them into its own include file.  You'd would also lose the benefits of things like calltips, and a few other perks but you gain a bit more simplicity with the file structure.

Edited 2 hours ago by MattyD

[SOLVE-SMART]

Thanks for the explanation - understood. Sound reasonably.

57 minutes ago, MattyD said:

There are Interface tags in all the interface libraries. So for a more traditional approach with ObjCreateInterface()  I'd probably extract all those and dump them into its own include file.  You'd would also lose the benefits of things like calltips, and a few other perks but you gain a bit more simplicity with the file structure.

You're right.

On a second thought, I personally have no use case for it at all, but it's still useful, no question 👍 .

Off-topic:

Spoiler

In the nearly past we (as community) tried to enhance AutoIt GUIs by several things (WebViews, WinRT, embedding web code and others). It's nice to have possibilites and showcases of how such things can be achieved, but for me AutoIt isn't the right approach for such problems/challenges. But this is of course just me. For private projects it's nice and I do often tryouts for such scenarios, but in my profession I (hopefully) choose the right tooling/framework for the goal/problem/challange.

Personally I really would love to see AutoIt enhancing by cross platform functionality and some other features or beeing open source, but this will not happen. So more and more people will leave AutoIt behind in the future.

Anyway, just few thoughts.

Again: Thanks for the showcase and the effort @MattyD 👌 .

Best regards
Sven