1)

I’m thinking about building a Visual APL interopt dll to transfer APL+Win data objects stored APL+Win Colossal files to Visual APL where I can save to APLNext  component files.     Will Visual APL's    ‘unwrapl’  ⎕DR  data   correctly interpret and un-wrapl data that was wrapl(ed) in APL+Win?

2)

To test this myself I wrote wrapl(ed) data to a native/text file in APL+Win and was hoping to read it in from Visual APL and try the unwrapl.    I’ve been stumped however because of DOMAIN errors whenever I use ⎕NREAD while in the Cielo Explorer.   I am able to create, write to and check the size of native files from Cielo but get the Domain Error whenever I try to ⎕NREAD.   I’ve created native files in TextPad, APL+Win and Visual APL and Visual APL and cannot read any of them.

1). The internal data representation between APL+Win and VisualAPL is different (and incompatible). Because of this you cannot 'wrapl' in VisualAPL and 'unwrapl' in APL+Win, and viceversa.

2) Did you add the references to the APLNext.LegacyOps:

refbyfile @"C:\Program Files\AplNext\AplNext\AplNext.Apl.LegacyOps.dll"

using APLNext.Legacy.NativeFileSystem

1) Okay, before I precede to write something to transfer APL+Win data structures to Visual APL, it seems likely that this may have already been done.   Are you aware of such a tool?

2) Yes I did the refbyfile and using . . . but I should have check further. 

 The real problem it seems is you cannot read ⎕nsize characters in one read.
 This is demonstrated below.

From APL+Win ______________

      'c:\temp\testtext.txt' ⎕ntie ¯4

      ⎕nsize ¯4

167

      y←⎕nread ¯4 82,( ⎕nsize ¯4),0

      ⍴y  ⍝ THIS READ GETS THE ENTIRE FILE CONTENTS

167

From the Cielo Explorer ______________

      @'C:\temp\testText.txt' ⎕ntie ¯3

¯3     

      ⎕nsize ¯3

167

      x←⎕nread ¯3 82,(⎕nsize ¯3),0  ⍝ TRY TO READ THE ENTIRE FILE

DOMAIN ERROR

      ⎕io←1  ⍝ CHANGE THE INDEX ORIGIN
      x←⎕nread ¯3 82,(⎕nsize ¯3),0  ⍝ TRY READING ALL THE FILE AGAIN

DOMAIN ERROR

      x←⎕nread ¯3 82,166,0    ⍝ READ (nsize -1) CHARACTERS

      ⍴x ⍝ WITH THIS READ WE LOSE THE LAST CHARACTER

166

      x←⎕nread ¯3 82,166,1

      ⍴x ⍝ WITH THIS READ WE LOSE THE FIRST CHARACTER

George,

I think what is happening here is that you are writing out bytes from APL+Win, which in many cases can be read directly back into Visual APL.

However, if you have included some APL characters or other characters which would cause Unicode to be used, then the length returned when read in Visual APL will differe as will the characters read.

In .Net, all of your Windows Controls only accept Unicode characters, the old byte vectors we used in the Legacy APL's will not work in .Net. for the Windows controls or for most other cases where text is used.

So everything in Visual APL is Unicode to be forward compatible.

However, if you need to read bytes, you can do this with the 81 option in []nread.

Once you have the bytes you will probably have to convert them to chars for them to be useful in .Net, but you can easily get them.

Hope this helps,

Fred