Chris,
1/2 : Conversion is not that straightforward because there is not migration tool and:
a. the localisation rules in APL+Win and Visual APL are (almost) the opposite; variables/objects in the header of a function are local in APL+Win but global in Visuall APL. The scoping rules for global variables created by functions are different.
b. Component files and []wi (and []fmt) from APL+Win are not compatible with Visual APL: however, Visual APL does support []wi if you create an express reference. Look up refbyfile and refbyname in the Visual APL help files.
c. the structure of data (nested) is not compatible; []dr which can flaten a nested array into a character vector and could have been used to effect the transfer is not compatible.
d. Visual APL does not support dynamic localisation of user defined variables (it appears to do so for system variables): this can present real problems for APL+Win workspaces.
For 'simple' workspaces, you could do this:
In a loop, take every function, remove all localisation, insert a { after the header and add a } at the end of the function and write it to a text file.
In APL+Win, read the text file into a variable, )edit the variable, Select All + Copy.
In, say, Cielo Explorer, )ed myclass, Edit + Paste APL+Win, Ctrl E+E. The functions are now in your session ... then it is testing, debugging .... When all is done, you can copy the class into your Visual APL Project. The fonts aren't compatible between the two.
For workspace variables, look at the TRANSFER workspace that comes with APL+Win.
3 : I do not know about this one.
What I would do:
1. Write/re-write the user interface using Viaual APL because the .NET GUI is far more powerful .. automatic resizing of controls is a good incentive.
2. Review all existing code and then migrate manually taking the opportunity to a. remove the clutter of utility functions because there may be simpler solution for them in Visual APL or the .NET platform. For example, MessageBox.Show can replace messaging functions, OpenFileDialog and the like replaces all interaction with the filing system, use the .NET solution rather than Win32 APIs etc etc
Visual APL supports overloading; unlike APL+Win which can two arguments, Visual APL function signatures permit multiple arguments by name or position and some/all can be optional.
3. Make the application tiered by using ADO.NET rather than Component/Native files for the data tier.
Visual APL documentation refers to APL+Win as lecacy APL (although APL+Win is still being developed ... 7.2 was released this year) and Visual Studio 2008 is just round the corner (beta 2 is available now). There is some wrting on the wall in here somewhere ...
Software development seems to have gone full circle: in the 80's, it was all about economy (of code, of scope etc) and then when hardware became cheap(er), it was more a case of 'let the machine take the strain' and now with .NET, it seems to be back to the 80's where scope and code-reuse is the essence of any solution.
Good luck.