Current issue

Vol.26 No.4

Vol.26 No.4


© 1984-2024
British APL Association
All rights reserved.

Archive articles posted online on request: ask the archivist.


Volume 15, No.4

This article might contain pre-Unicode character-mapped APL code.
See here for details.

Using VideoSoft FlexGrid Pro with DyalogAPL: an Update

by Jon Sandles


In the last issue of Vector I wrote an article describing how to use the VideoSoft FlexGrid with Dyalog APL. I reported on a number of shortcomings, by far the worst of which was Dyalog’s incomplete handling of events coming from the ActiveX control. Before Vector had even landed on your doormats, Dyadic had published a patch for their new version 8.2 interpreter.

As well as fixing this bug, the new 8.2 interpreter has also completely cleared up the instability problems I was having previously.

The fix is available for download (if you are a member of Dyadic’s DSS service).


In my last article I showed how you should be able to write the following event handler in the ‘BeforeEdit’ event of the flexgrid.

     ’ msg„onFGBeforeEdit msg
[1]    :If 'Sales'­(1œmsg)ŒWG'TextMatrix[0;',(•msg[4]),']'
         ª msg[5]„1 ª :EndIf

The setting of msg[5] to 1 should set the ‘Cancel’ parameter to ‘True’. This should reject the event. Because results were not returned to the ActiveX control under Dyalog APL this technique did not work.

Dyadic offered the following explanation on their WWW pages:

By default, events generated by an ActiveX control (associated with an instance of an OCXClass object) are processed like all other events in Dyalog APL.

This means that if you attach a callback function to an event in an OCXClass object, the events are queued up when they are received and then processed one-by-one, by ŒDQ, from the internal queue. This is the mechanism used to process all events in Dyalog APL and it has many advantages:

Events are handled in an orderly manner

An event cannot interrupt a callback that is processing a previous event

Incoming events are held up so that you can trace a callback function etc.

The disadvantage of this approach is that, for internal reasons, your APL callback function is unable to return a result to the ActiveX control, or to modify any of the arguments supplied by the event. This is a severe problem if the ActiveX control relies on callbacks to control certain aspects of its functionality.

The new QueueEvents property allows you to change the normal behaviour so that it is possible for a callback function to return a result to an ActiveX control.

So by simply adding the following line to my Go function:

fg ŒWS'QueueEvents' 0

And Bingo! Suddenly the edit events are being rejected. Great stuff. The other handler that didn’t work – the one that was meant to set the little scroll tips on when you move the scrollbar up and down –

     ’ msg„onFGBeforeScrollTip msg                                                        [1]    (1œmsg)ŒWS'ScrollTipText'('Row : ',•msg[3])

– also suddenly started working. So Dyadic have solved the problem completely.


Dyadic have acted promptly to address the issues raised in my last Vector article and as a result the FlexGrid is a viable alternative grid control for use under Dyalog APL.

script began 5:26:29
caching off
debug mode off
cache time 3600 sec
indmtime not found in cache
cached index is fresh
recompiling index.xml
index compiled in 0.1859 secs
read index
read issues/index.xml
identified 26 volumes, 101 issues
array (
  'id' => '10007680',
regenerated static HTML
article source is 'HTML'
source file encoding is 'ASCII'
read as 'Windows-1252'
completed in 0.2085 secs