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. There's script in the zip which will copy AutoIt.exe (or AutoIt_x64.exe if you're using it) and update its manifest. If you replace the original file with the modified one, you should be able to successfully run the example with the F5 key.

 Or here's a screenshot 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 11 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 yesterday at 10:24 AM 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

[MattyD]

Hi all, just a quick one

I've updated the zip in post #1 - its the same thing, but I've included a tool so you can easily update that application manifest.

[Gianni]

Hi @MattyD

I replaced the original autoit3.exe file with the modified version generated by your script (..?! you know things that I obviously don't know) and in this way MediaPlayer.au3 works.
Then I tried to compile MediaPlayer.au3 but the generated executable does not work (the autoit3.exe file after compilation is still the modified one). Is there any trick to be able to compile MediaPlayer.au3 into a working executable and then restore the original autoit3.exe file in the AutoIt folder?
Bye and thanks

Edited 10 hours ago by Gianni

[MattyD]

 Yeah, there's a couple of options really,

You could just modify that "update manifest.au3" so it replaces the resource in your compiled script (rather than @autoitexe).

But my original approach was to modify AutoItWrapper.au3.  On line 2670 I inserted this.

FileWriteLine($hTempFile2, '            <maxversiontested Id="10.0.18362.1" />')

Then in your script, you need the following directive to trigger that bit of code:

#Autoit3Wrapper_Res_Compatibility=Win10

I don't think the actual build number is critical - I'd imagine things should be OK so long as the build is after win10 1903. Win10 22H2 is 10.0.19045.0 if you wanted to specify something more current!

[Gianni]

I applied the patch to the compiled executable file instead of AutoIt3.exe and that worked. Thanks

[argumentum]

1 hour ago, MattyD said:

But my original approach was to modify AutoItWrapper.au3.  On line 2670 I inserted this.

In my version of it does not fall under that line.

... ...
                    If StringInStr($INP_Res_Compatibility, "Win10") Then
                        FileWriteLine($hTempFile2, '            <maxversiontested Id="10.0.18362.1" />') ; insert here
                        FileWriteLine($hTempFile2, '            <!--The ID below indicates application support for Windows Vista -->')
... ...

This will be easier to find as beta versions come out.
Thank you for the food code