WinRT - WinUI3

[WildByDesign]

20 minutes ago, MattyD said:

And resizing the window actually works remarkably well. I guess I was expecting some flicker or something- so that was a pleasant surprise! 

 

That's quite beautiful. You are making excellent progress so far. I haven't tested this in the last few days but I'm definitely more inspired now to try some things with it later today.

• How is the performance of the UI loading?

The reason why I ask is because a lot of Microsoft's own examples with WinUI3 are quite sluggish. Yet, I have also seen many examples from other developers which are fast and snappy.

• How do you handle applying DPI scaling?

I'm just not sure if the WinUI3 / WinRT stuff automatically applies DPI scaling by default or if we would specify the DPI scaling as we normally would in AutoIt.

[MattyD]

Thanks mate, we'll have to credit whoever came up with the design at Microsoft though!

18 minutes ago, WildByDesign said:

How is the performance of the UI loading?

This is honestly fine, but we're not exactly asking much of the runtime either at this point in time!   Au3check can grind a bit when you really start pushing the #include file count. But for what I'm doing at the moment its OK. 

25 minutes ago, WildByDesign said:

How do you handle applying DPI scaling?

I haven't looked at this at all sorry!

[MattyD]

This is the same example - but I'm playing around with adding another layer of functions on top of the interface libraries.   It should make building GUIs quite a bit simpler, and introduce some semblance of resource management.

At this stage its just a rough proof of concept, so I'm not worried about naming conventions etc, or any mistakes in these functions. They'll all probably be rewritten anyway!

So anyway, as an example: I'm now doing this to add rows and columns to the grid.

;Params - $pGrid, $fValue, $vUnit ("Auto", "Pixel" or "Star")
;$vUnit can also be the enum in its numeric form. (Microsoft.UI.Xaml.GridUnitType)

GridAddRow($pGrid, 2, "Star") 
GridAddRow($pGrid, 1, "Star")
GridAddColumn($pGrid, 3, "Star")
GridAddColumn($pGrid, 5, "Star")

And the underlying func.

Func GridAddColumn($pGrid, $fWidth = 1, $vUnit = "Star")
    _WinRT_SwitchInterface($pGrid, $sIID_IGrid)
    If @error Then Return SetError(@error, @extended, False)

    Local $tGridLen = DllStructCreate("align 4;double Value;ulong GridUnitType")
    $tGridLen.Value = $fWidth
    $tGridLen.GridUnitType = IsString($vUnit) ? $mGridUnitType[$vUnit] : $vUnit

    Local $pColDef, $pColDefs = IGrid_GetColumnDefinitions($pGrid)
    $pColDef = _WinRT_ActivateInstance("Microsoft.UI.Xaml.Controls.ColumnDefinition")
    _WinRT_SwitchInterface($pColDef, $sIID_IColumnDefinition)
    IRowDefinition_SetHeight($pColDef, $tGridLen)
    Local $iError = @error
    If Not $iError Then IVector_Append($pColDefs, $pColDef)
    IUnknown_Release($pColDef)
    IUnknown_Release($pColDefs)
    Return SetError($iError, 0, $iError = $S_OK)
EndFunc   ;==>GridAddColumn

Most funcs that accept an object will start with a  SwitchInterface() - this serves 2 purposes:

• in your main script you don't need to bother about setting the correct interface on the object.
• and also if you feed the func an invalid pointer (to the wrong object for eg.), it should gracefully fail. 

Factories and other supporting objects used in these funcs are all released before returning.  This is probably not be the most efficient thing to do if you're creating a bunch of instances of something - but it does mean you're cleaning up after yourself as you go.

I'm getting way ahead of myself - but this new layer wouldn't be a comprehensive wrapper. It'd probably just some basic/common functionality to improve quality of life. I figure people can always jump down to the interface libraries if need be.   Whether this will form part of an "official" release I don't know (if I ever get my act together!) - but I think building a full project without anything would just be downright tedious... And hey, if anyone else wants write/drive some of it I won't be complaining!!!

WindowTest Grid.zip

Edited September 3 by MattyD

[argumentum]

...
#AutoIt3Wrapper_UseX64=Y
#AutoIt3Wrapper_Au3Check_Parameters=-q -d -w 1 -w 2 -w 3 -w 4 -w 5 -w 6 -w 7
If Not @AutoItX64 And Not @Compiled Then
    ShellExecute(StringTrimRight(@AutoItExe, 4) & "_x64.exe", '"' & @ScriptFullPath & '"')
    Exit
EndIf
#include <GUIConstants.au3>
...

It asked me to GetRuntime() but I installed it yesterday so, the above is a good solution for those not in SciTE, just click-clicking the file from explorer   

Edited September 3 by argumentum

[WildByDesign]

@MattyD From your WindowTest Grid example from September 3rd, you have three sections of the weather GUI with background colored with the following:

Local $aiColours[3] = [0xFF2F5CB6, 0xFF1F3D7A, 0xFF152951]
    Local $apBorders[3], $pBrush
    For $i = 0 To 2
        $pBrush = CreateSolidBrush($aiColours[$i])
        $apBorders[$i] = CreateBorder()
        IBorder_SetBackground($apBorders[$i], $pBrush)
        IUnknown_Release($pBrush)
        PanelAddChild($pGrid, $apBorders[$i])
    Next

So what I am curious about is how would we go about changing some of those background colors after the GUI is already showing?

I'm trying to understand the WinUI 3 stuff now. I'm not even sure that each part of the GUI even has a window handle. The whole WinRT/WinUI 3 stuff kind of boggles my mind as to how to change this stuff after the fact.

[MattyD]

sure thing. - yeah, there are no window handles per se - apart from the WinID of the main window.  Everything is done on objects. 

so that colour change would be something like:

$pBrush = CreateSolidBrush("Red")
IBorder_SetBackground($apBorders[0], $pBrush)
IUnknown_Release($pBrush)

In the Sept 3rd. example, to keep things tidy I release the border objects once they're created. So you'd need either need to change the background before releasing, or get the border object back by some other means. Via its parent for example - in this case the grid object (before it too is released!).

As for triggering the color change - In this example,  once we get into the main loop everything is event based. When we hit the following line the script won't continue until the dispatch loop is broken with _WinUI3_PostQuitMessage. 

IDispatcherQueue3_RunEventLoop($pDispatchQ)

The general idea is to create a bunch of handlers with _WinRT_CreateDelegate(). But if you'd rather work within a while loop, it is possible to create your own dispatcher with _WinUI3_GetMsg / _WinUI3_DispatchMessage.  I think there are probably examples of this early in the thread!

Edited November 11 by MattyD
typo

[MattyD]

Hi all,

Updated libraries based on the new Version 1.8 of WindowsAppSDK are here. Until now we've been on 1.7.x

The v1.8 runtime can be installed from here: (Remembering that we require the x64 version.)

A copy of the latest bootstrapper dll is included in the zip - but  if you need to manually update it later for whatever reason, it has moved.

So you'll now find it here: https://www.nuget.org/packages/Microsoft.WindowsAppSdk.Foundation/
download package (on the right) >  extract contents > then you'll find it under .\runtimes\win-x64\native

[MattyD]

Just having a bit more of a play with this.

I've found we can avoid the creating that custom window proc... this is good, as it seems breaking the dispatcher loop is done in part by posting a WM_QUIT message. I hadn't noticed it at first, but I think AutoIt was seeing this and exiting automatically once it found that message.  So now our script goes through all the way to the end.

Also the demo shows how we can constrain the max/min window size, and automatically grow and shrink the xaml content with the window.. (we were previously doing the latter via that window proc)

Example

Edited Friday at 04:07 AM by MattyD

[argumentum]

33 minutes ago, MattyD said:

Just having a bit more of a play with this.

(9,0) [0x00000000] The operation completed successfully.
>
!>23:39:47 AutoIt3 ended. rc:-1073741819

🤷‍♂️
On 23H2,  #AutoIt3Wrapper_UseX64=y

[MattyD]

ah ok thanks, I've updated _WinUI3_Startup() to target v1.8 of the WindowsApp SDK.. I think its not throwing a soft error f there's a version mismatch with the runtime... I'll see if I can fix that for next time...

Can you try doing a _WinUI3_Startup(1, 7) to target v1.7 and see if that works?  (assuming that you still have it installed) . Otherwise v1.8 can be installed from here...

1 hour ago, argumentum said:

 #AutoIt3Wrapper_UseX64=y

And yep I forgot this at the top, it should definitely be there  too.

Edited Friday at 06:28 AM by MattyD

[argumentum]

8 hours ago, MattyD said:

try doing a _WinUI3_Startup(1, 7) to target v1.7 and see if that works?

(10,0) [0x00000000] The operation completed successfully.
>
+>09:57:56 AutoIt3 ended. rc:0

That did it. Thanks

[argumentum]

...
Func _WinRT_Startup()
    If Not @AutoItX64 Then Return SetError(1, 0, 1)
...
Func _WinUI3_Startup($iMajorVers = Default, $iMinorVers = Default, $sVersionTag = Default, $iMinVers = Default, $iOptions = Default)
    If Not @AutoItX64 Then Return SetError(1, 0, False)
...

#include "WinUIBase.au3"
If Not @AutoItX64 Then Exit ConsoleWrite(@CRLF & '@@(' & @ScriptLineNumber & ') : Needs to run x64.' & @CRLF)
_WinRT_Startup()
If @error Then Exit ConsoleWrite(@CRLF & '@@(' & @ScriptLineNumber & ') : Error=' & @error & @CRLF)
_WinUI3_Startup()
If @error Then Exit ConsoleWrite(@CRLF & '@@(' & @ScriptLineNumber & ') : Error=' & @error & @CRLF)
...

..something to let the user know that is not running x64. And since the default install runs x86 for compatibility, when click-click from Explorer, the "#AutoIt3Wrapper_UseX64=y" is not going to do it's thing.

[MattyD]

Good idea around checking for x64 in the init funcs.
I've updated things on my end, so they should throw ERROR_EXE_MACHINE_TYPE_MISMATCH in future releases.