XED - a Xaml EDitor [Contribution]

[PGilbert]

There are many XAML editor available to the APLer, the must popular is probably Kaxaml with its 'scrubber' feature that will align the xaml code. None of those editors can work with a text variable in the APL WS and assign automatically the events beginning with ∇. I have been working on an XAML editor that will be usefull to the APLer that I named XED. Find it in the attached WS

XED_1.zip

(120.97 KiB) Downloaded 779 times

in the namespace XED, the main function is 'Run'. The user interface looks like this:

You will need to add a third party dll

ICSharpCode.AvalonEdit.zip

(184.36 KiB) Downloaded 788 times

that you need to place next to the dyalog.exe file. You need to be setup for .Net 4.0 with the proper 'dyalog.exe.config' file. This is an ongoing project but should be usefull as an example of a function written using XAML and APL for those interested in learning it.

I was not successfull in making it as a user command. If someone could show me how, it will be appreciated.

Enjoy and Vive APL !

[Dick Bowman]

Disappointment is my middle name (or I should get a job as a code-breaker?).

Here's my sorry story...

Environment is Windows 7 64-bit, Dyalog 12.1 (patched up to date). Using .NET 4.0 (this is working, I have some little applications).

Downloaded and unzipped, icsharpcode.avalonedit.dll is in the same folder as dyalog.exe.

)load ...xed_1
"GUI objects could not be recreated; the file is from an incompatible architecture"
OK, I can live with that, ws is probably from 32-bit APL/W.

#.XED.Run
Window starts "Exception: Request for permission of type 'System.Security.Permissions..." (full transcript should be in the attached file - if I've managed to achieve this).

Crosschecked - my own WPF applications still seem to run as expected (so I don't think I've broken anything previous). Also tried misnaming the dll, and got a reasonable "can't find the dll" message - so it's in the right folder.

My guess is that the dll is 32-bit - but I didn't see any mention of 32-bit v2 64-bit versions when I looked on the AvalonEdit site (maybe I need to look harder).

Any suggestions - looks like it'll be an invaluable tool?

By the way - what does "assign automatically the events beginning with ∇" mean? Can you show me an example?

[PGilbert]

The idea of having a del character was showned to my knowledge by Dyalog has a way to be able to remove an event from the XAML code before it is 'compile' and fix it later. For example:

Code: Select all

    <Button
      Name="button1"
      Height="91.456"
      Width="207.764"
      Grid.Column="1"
      HorizontalAlignment="Right"
      Margin="0,0,18.577,17.148"
      VerticalAlignment="Bottom"
      Click="∇ClickAction"
      Style="{DynamicResource GlassButton}">Button
    </Button>


In the above example the Click="∇ClickAction" line is removed by APL using ⎕XML and later fix by doing something like:
MyRootObject.button1.onClick←'ClickAction'. This is coded in the 'GetObjectFromString' function of the attached WS. I have seen also Dyalog used the delta character in a Web application for something similar. That way we can keep the events as part of the XAML code. My version is different from the 'Load' version provided in the Dyalog's WPFTOOLS WS because of some errors I was having sometimes because of the particularity of some XAML code. The goal is to provide an improved version that hopefully will allow us to converge toward a final one.

[Dick Bowman]

Thanks, now I get closer to understanding.

Ever the optimist, I'd thought this was a magical feature of XAML syntax. I'd tried entries like this in my XAML files and got pages of abuse in the Status Window as my sole reward.

As I now understand it you have a pre-processor which reads the "augmented" XAML, strips out the extras, presents cleaned-up XAML to <LoadXAML> and uses the extras to define callbacks. I've also felt the need for a pre-processor to do some XAML tweaks (but hadn't had the wit to include this).

Maybe there's a "community project" out there waiting to be started, where we define the "super-XAML" that we need for effective APL deployment and all use the same preprocessors - rather than each building our own little nests. I think this is related to my suggestion a week or so back that we ought to have something of an equivalence for the folders and files that Visual Studio automatically creates for every WPF application.

[Vince|Dyalog]

Pierre, thanks for this contribution!

I have asked Dan to advise you about User Commands.

Dick, the DLL attached to this page is a 32-bit DLL. I can know this as it works with my Dyalog 12.1 32-bit, which would not be the case if it were a 64-bit DLL.

[Dick Bowman]

Thanks Vince, I suspected that to be the problem. But, as I said earlier I didn't find a 64-bit AvalonEdit when I looked. Am I alone in thinking that Microsoft are making something of a dog's dinner of the move to 64-bit?

[StefanoLanzavecchia]

As far as I know, .NET assemblies (DLLs and EXEs) are platform agnostic. Unless the developer explicitely sets the target architecture at assembly compile time. In other words, the same assembly can be used both on a 32-bit and on a 64-bit system.

[Dick Bowman]

Well, I'm mystified (as usual). There's a .exe included in the Avalon binaries which runs without issue. Hopefully I'll find a little time tomorrow to trace what's going on within XED.

[PGilbert]

By looking on the web for the error:
Request for the permission of type SystemSecurity.Permissions.SecurityPermission you can find that the problem is probably caused by some security issue while trying to access the ICSharp dll. Looks like you need to go to 'Full Trust'. Could you experiment with you UAC (User Account Settings) and advise if there is any changes. In the affirmative, we need to learn how to give full trust to a third party dll.

[Dick Bowman]

Here's what I've done and discovered today...

Changing UAC had no effect.

The sample .exe in the AvalonEdit binaries runs OK on my 64-bit Windows 7 PC.

Stripped down the XED XAML so that the window just contained an AvalonEdit control and tried to display it using the simplest possible code (tweak from Jonathan'd WPF example, adding reference to AvalonEdit) gave me the same error (Status Window contents attached). All good if I take use of the AvalonEdit control out of the XAML - my other WPF applications run OK.

Patched and updated my 32-bit APL/W 12.1 Unicode (also Windows 7, different hardware), installed XED - success.

So - looks like it may be a 64-bit issue. But is it something specific to my PC?

Has anyone else been able to run XED on 64-bit 12.1 Unicode Windows 7?