One of the first screen casts, http://forum.apl2000.com/viewtopic.php?t=195, illustrated exposing VisualAPL methods in a .Net assembly as COM so that they might be used by a Win32 application like VB6 or APL+Win. The example provided was a VisualAPL method Getlength() which had an an object argument and returned an int[]-vector containing the APL-shape of the argument.

When an instance of the ActiveX object [exposing the VisualAPL .Net class] was created in APL+Win, because the argument of the method is not strongly typed it appears that any APL+Win variable can be passed as an argument to the XGetlength() method.

What was not mentioned was that the ActiveX interface of APL+Win was designed for compatibility with Win32 VB6 before .Net existed. As examples:

...[]wi 'XGetlength' 'abc'                            returns 3

...[]wi 'XGetlength' (1 2 3)                         returns 3

...[]wi 'XGetlength' (3 4<reshape>1 2 3) returns 4 3 and not 3 4.

The above result is not an issue with VisualAPL, but instead occurs because when APL+Win passes an array to an ActiveX object, it transposes for compatibility with the row and column order of Win32 VB6.

...[]wi 'XGetlength' (3 4<reshape>'abc') returns 3 and not 3 4.

This latter result is not an issue with VisualAPL, but instead occurs because of the APL+Win issue described above and because when APL+Win passes a text array to an ActiveX object, it demotes it to a vector of text vectors for compatibility with the 'bstring' datatype of Win32 VB6.

If instead one sends a 'typed' object from APL+Win, then the 'correct' result is obtained. For example:

...[]wi 'XGetlength' ('#' []wi 'VT' (<transpose>3 4 <reshape> 'abc') 8209) will return 3 4 as expected.

8209 indicates a 'byte array' datatype coming from APL+Win.