XAML: Sidebar

[stanl]

Not wishing to stick this into Chuck's thread but

   
• Assuming WB can create a window from XAML [see code below]
• WB/CLR [right now] cannot control events, i.e. OnClick()[/r][/r][/r]
• Could adding UI.Automation code to the script permit handling a button and through Sendkeys or WB Mouse Click simulate the OnClick()

More a non-relevant question at this point. WB can build a better looking dialog w/out CLR and work with controls. And, seems UI. Automation is a lot of excessive code for a simple click..... However, I do see a future with windows.forms


NOTE: change &#39 back to ' if using code

Code (WINBATCH) Select Expand



;CLR  - test XAML Buttons
XAML = $"
<Window
        xmlns="http:://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns::x="http:://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="300" Width="300">
    <StackPanel>
        <Button x::Name="button0" Content="Main Menu"/>
        <Button x::Name="button1" Content="First App"/>
        <Button x::Name="button2" Content="Second App"/>
        <Button x::Name="button3" Content="Third App"/>
        <Button x::Name="button4" Content="Fourth App"/>
        <Button x::Name="button5" Content="Exit"/>
        <ScrollViewer x::Name="scrollViewer" Height="150">
            <TextBlock x::Name="msg" TextWrapping="Wrap"/>
        </ScrollViewer>
    </StackPanel>
</Window>
$"


Message("XAML",XAML)
_True = ObjectType('BOOL',1)
_False = ObjectType('BOOL',0)
ObjectClrOption('useany','System')
ObjectCLrOPtion('useany','PresentationFramework')
ObjectCLrOPtion('useany','PresentationCore')
ObjectClrOption('useany','System.Xml')
oDOc =  ObjectClrNew('System.Xml.XmlDocument')
oDoc.LoadXml(XAML)
oXML = ObjectClrNew('System.Xml.XmlNodeReader',oDoc)


;create list pair to identify Buttons
;====================================================================================================
blist =""
elements = oDoc.GetElementsByTagName("Button")
n = elements.Count
For i = 0 To n-1
   n1 = elements.Item(i).Attributes.Count
   att = ""
   For j=0 To n1-1
      att = att:elements.Item(i).Attributes.Item(j).Name:"="
      att = att:elements.Item(i).Attributes.Item(j).Value:","
   Next
   blist = blist:strsub(att,1,strlen(att)-1):@LF
Next
Message("XAML Buttons",blist)
;====================================================================================================


;Load Xaml
oXamlReader = ObjectClrNew('System.Windows.Markup.XamlReader')
oWin = oXamlReader.Load(oXML)
oWin = ObjectClrType( 'System.Windows.Window', oWin )
;Display Window for 5 seconds then close
;otherwise oWin.ShowDialog() will keep Window Open
oWin.Show()
TimeDelay(5)
oWin.Close()


Exit
;====================================================================================================




[ChuckC]

Take a look at this:

https://adamtheautomator.com/powershell-gui/

In PowerShell, it's possible to assign event handling code to a button control for its "OnClick" event.  I can think of a couple of possibly ways within WinBatch to use either dynamically compiled C# code as a button click handler or to keep a captive PowerShell session where the PowerShell script code does the XAML window handling including the button click.  In either of those cases, though, I'm not sure how the button click event handler in C# code or PowerShell code communicates back to a WinBatch script.

What isn't clear is if WB's CLR hosting would permit the assignment of some arbitrary unit of WIL code as a delegate to use as the button click event handler.

[stanl]

Thanks Chuck;


That is a good article as is most of what he writes. I have created PS GUI executables at work using winforms. You create a form in Visual Studio and then run a PS script that converts the .cs code to .ps1. Then of course you edit the .ps1 to fill in dropdowns, handle radio buttons, add onclick code... etc.  It has worked well, creating small .exe [there is a PS2EXE app... Powershell compiles Powershell]. Several work with WinSCP and are on a network drive which members of my team use.


I guess there is an advantage using XAML over windows.forms but I haven't found it.

[ChuckC]

I think the advantage of using XAML in place of WinForms is that the output from the UI designer in Visual Studio is just a single .XAML file per window/form/dialog that you design.  When it comes to utilizing the UI you created in a PowerShell script or in WIL via CLR hosting, there's no specific need to do any dynamic C# compilation just for the display of the UI.  With what was demonstrated with XAML and PowerShell, event handling "plumbing" is very straight forward to hookup to have a fully functional UI.

The question to get an answer for from Tony would be whether there are any plans for the WIL CLR hosting functionality to support similar usage in the future.  Being able to declare a UDF that interacts with elements of a global map/dictionary variable and assign that UDF as an event handler would permit full usage of XAML-base UIs from within WinBatch scripts.

[td]

There are approximately 1000 lines of if-defined-out source code inside the WIL DLL to support dotWhatever events. It has been in the DLL since around 2013. The only problem is that it didn't and doesn't work because MSFT never fully implemented the interfaces needed to make it work. But of course, we are always planning something or the other...

[stanl]

I think the advantage of using XAML in place of WinForms is that the output from the UI designer in Visual Studio is just a single .XAML file per window/form/dialog that you design. 

So is a .cs file.... but of course has to be retro-set as .ps1 and you seem to imply an XAML would not require any fiddling-around. All I know is my winform PS exes are not failing and keeping me employed. [really wish company would authorize WB].


Not wishing this thread to deteriorate...

[ChuckC]

End of last year, I got into some hybrid development where a .NET executable written in C# was having to PInvoke into a native code DLL I wrote in C++.  There's nothing really special about that, per-se, except that there was async communication in both directions, so the C# code had to do some custom marshaling to permit a class instance method in C# to be used as a function pointer by the C++ code.  Likewise, the C++ code returned some static class method function pointers back to C# where they had to be wrapped up in a delegate that could be invoked as part of an event handler for a timer event.

Is what WIL would have to do similar in nature to that?  I understand that with WIL, the environment is inverted in that it's a native code executable that's having to load the CLR, and that additional complications may ensue.

[td]

We are very familiar with the many "interop" techniques in the .Net Framework.  What WinBatch is doing is not something that MSFT even fully publishes. There a multiple reasons why WinBatch needs to do things the way it does. And the intent is not for WinBatch to be PowerShell light or something like it. Powershell is a "managed" application that does what managed applications do. WinBatch is compiled directly to machine instructions application that does what "native" - as MSFT calls them - applications do. But as mentioned previously, we are always planning something.

-- Edited this post because the original conveyed the wrong tone. 

[ChuckC]

I wasn't implying that you weren't aware of the various interop features used for cross-talk between managed & native code.  Your description of managed & native code being better at different things relates directly to why I was having to have such close integration between them within a single process due to the fact that the program in question absolutely needed highest possible performance and some part of what it was doing could only be done in a highly performant manner with native code.  The remainder of the program's functionality was such that it would be burdensome to rewrite all of it in C++, so the the main body of the program remained in C# and the bidirectional callbacks using interop functionality was adopted.

You did answer my question, though, in that there are limitations between what a process running managed code making calls to unmanaged code can achieve vs. what a process running native code making calls to managed code can achieve.  It somewhat reminds me of the crud we had to deal with under Windows 95 with mixtures of 16-bit and 32-bit code and how "thunking" was achieved.  Thunking support for 32-bit => 16-bit vs. 16-bit => 32-bit was very different.

[td]

As fate would have it, we are currently working on a project that requires the use of .Burgerflipper .net5/core3.1 interop. It's a bit irritating because of all the mindless magic involved but I guess that is the state of software development in the 2020s...

[ChuckC]

Would that project work involve updating the CLR hosting to work with .NET v5 & newer as opposed to legacy .NET Framework v4.8 & older?

[td]

It is a bit of an unusual project for WinBatch but it has been the policy since the WindowWare days to not pre-announce new work. Also, there is no way of knowing if the project will amount to anything useful to anyone. That is about all there is to say about the topic for now.