For organizational purposes I have tried to set up two classes in my Class Library project, “KregUtilsCL1”.  

• I added a second set of entries in the GUID region by copying the one there and creating and pasting in a new GUID for the new class. 
• I added two new methods in the region for my new public class and these functions work in the Cielo Explorer.
• I then rebuilt the project.
• In APL+Win I can see both classes
       KregUtilsCL1.GEN ActiveObject KregUtilsCL1.GEN
       KregUtilsCL1.Math ActiveObject KregUtilsCL1.Math
  and can create an instance of each.
• When I check the methods of original class I created it lists all the .NET methods but not the two which I created.  These used to show before I added the new Class.
• When I check the methods of the new/second Class my two new methods do show.
• However the methods do not work and do not get an error.   Both method take a character matrix argument and return a character matrix.  But from APL+Win they are returning a single number, a scalar 323 numeric, this number is incremented by 64 every time I call the method.  I wonder if a pointer is somehow being returned.

Does anybody have any idea what is going on here??

Hi George,

The following are my initial thoughts on your issues. Fred and Jairo may have additional (corrective) comments.

(1)   You may have to unregister the COM object and then redo the build. See Jairo's blog http://www.aplnext.com/community/blogs/jairol_weblog/archive/2006/12/08/170.aspx on how to do this. Also this was one of the short topics in a recent VisualAPL webcast.

(2)   Except for the most recent APL+Win v6.4 subscriber's release, APL+Win keeps a COM object file in (shared) use until the APL+Win session is ended (even if one does a []wi 'Delete'), so when doing the build and COM registration in VisualAPL, be sure that APL+Win session is closed. Otherwise one may receive an error during the build indicating that the build cannot be performed because the object is in use by another 'process' (don't quote me on the exact error message).

(3)   When one accesses an ActiveX object from APL+Win, the ActiveX object must specify the datatype it expects and the datatype that it returns. Generally you can examine this by doing something analogous to: ... []wi '??Xmethod_name', where 'Xmethod_name' depends on the COM object. If this returns information indicating that 'object' is requested or returned by the method, this is generally not sufficient for APL+Win to properly cast the APL+Win datatypes to a COM-compatible datatype.

The datatypes are limited to those which apply to COM objects, e.g. things like double, double[], string, string[], etc. There is no datatype for COM objects which corresponds to an APL character matrix. So when APL+Win 'sends' an APL character matrix to a COM it converts it to what the APL+Win developers (at that time in the past) thought would be the best matching COM datatype, i.e. string[]. Essentially this conversion is a []split of the APL+Win character matrix into a vector of text vectors which is then passed to the COM interface.

I think that what you want to do is possible, but try changing the argument and result of your VisualAPL method to string[] and see what happens. When the result of the COM object is returned to APL, you may have to do a <disclose> on the vector of text vectors to reconstitute you expected APL+Win character matrix.