- Could probably have coded this a little more smartly (getting the form name from the callback argument)
- You might expect the Event to be "onClick", but WPF is full of surprises and it has to be "onMouseDown" because this Button (code taken from an application) is sitting in a ToolBar.
- Although there is a clear APL assignment for the Event, you can't actually see the setting after it has been made (0 is returned). At this time it's not clear whether this is a bug or whether we have to deal with this sort of nonsense because we're interacting with nerdworld.
- The standard right argument (filled by WPF) hasn't proven to be especially useful at this time - it's there because it has to be.
- Passing our own arguments into callback functions is
because WPF seems not to recognise this as a possible requirement and
so make no allowances. Assuming that we want to avoid
polluting our workspace with globals, one approach is to put what we
need into an appropriately-named variable within the WPF object,
∇ ToDo w;⎕IO;⎕ML;args
⍝ Review the ToDo list
⎕IO ⎕ML←0 3
At this moment I'm undecided about whether this is going to feel comfortable over the longer term or whether it's brushing the problem under the carpet. Time might tell. Worth remembering also that these arguments are fixed as of the object/event/callback definition, which also limits their usefulness.