The easiest route to follow is to start with something that works, then tweak it when you find problems. I've started with Jonathan Maktelow's example (from the Dyalog 2008 conference), evolving over time into something like this (used with .NET Framework 4.5)...
use←'System,System.dll' 'System.IO,mscorlib.dll' 'System.Xml,system.xml.dll'
It's something of an omnibus edition, and doubtless there's a performance hit if it evolves to contain everything all of the time (and maybe a different performance hit if we make cut-down versions for specific purposes for each nook and cranny of our applications). Frankly, it looks like another mess being thrust upon us by Microsoft - and we (with Dyalog) are making the best of a bad situation.
You may also be puzzled as puzzled as I am that even under 64-bit Windows 7 we seem to have to go looking in the 32-bit Program Files folder.
Note: There's a workspace called WPF available from Dyalog support which contains versions of this and other more or less useful tools - further references to the WPF workspace on this page refer to this file as of May 2013 (it may have changed by the time of reading).
Downsides to this general setting are...
- When your requirements go beyond the straightforward it may not have all of the entries you need
- By trying to be universal it may contain many entries you don't want, and this may have an adverse effect on your application's performance as APL hunts through all of the redundant entries.
So, you'll probably want to generate your own ⎕USING values.
If you hunt through the Microsoft Class Library Reference you'll eventually find the assembly and dll information you need.
Alternatively, you can get APL to do this work for you by using #.WPF.FindUsing (also in Dyalog's WPF workspace) - for example...
The bad news is that you're still going to have to read at least some of the Microsoft documentation in order to find out how the control behaves and what it can do.
WPF (as supplied by Microsoft) can be frustratingly incomplete and you'll probably find yourself using software from various third parties.
In general the authors follow similar documentation conventions as Microsoft and you'll find what you need to know relatively easily. So long as you know which folder contains the dll it's straightforward to construct the ⎕USING entry - for example to access the AmCharts charting package you would need the element
appropriate folder name.
Referring to Button is a reasonable approach in the majority of cases, but pedants (among others) could argue that it's less ambiguous to use the fully-qualified System.Windows.Controls.Button. If you'd prefer to do this (and have the stamina to do all the consequent typing) you'll need an empty vector in ⎕USING - this forces APL to look in the default dll (mscorlib.dll) to resolve fully-qualified names, hence...
⎕using←'' 'System.Windows.Controls,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\PresentationFramework.dll'
Once an object has been created APL makes no further use of ⎕USING,
you can reset it (to create other objects) or empty it ( ⎕using←,⊂'').
A file generated by Dyalog during installation/configuration, dyalog.exe.config lets you control which version of .NET (and hence WPF) your application code is going to use. Here's a sample...
<supportedRuntime safemode="true" version="v4.0.30319" sku=".NETFramework,Version=v4.0"/>
Which I'm currently using with .NET Framework 4.5. Now you may look at it and wonder precisely where it says 4.5 because it clearly doesn't. But these things are made by people with a different mindset than the typical APL programmer so just take my word for it - use this file and you will get to use .NET Framework 4.5.