TOPIC:

Hi Dev Team

I just tried to convert one of our VO-Programs. I was able to correct the most of the errors.
But These two Things does not compile:

Split Window Class:

SELF:Font := Font{,9,"Arial"}
Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand
Fehler XS0144 Cannot create an instance of the abstract class or interface 'Font'


SELF:oDefaultIcon := Icon{ ICONSTANDARD }
Schweregrad Code Beschreibung Projekt Datei Zeile Unterdrückungszustand
Fehler XS0144 Cannot create an instance of the abstract class or interface 'Icon'

Any idea how to solve this?
TIA Markus

Hi Markus,

Those are strange errors..have you created your own Icon and Font class in the code? Maybe in VO you had added additional methods to the already existing Font/Icon classes? Or maybe there is something else causing the problem, can you send the full code of this class so we can have a look?

Chris

Hi Chris

thanks for your fast answer. I attached the solution to this post.
I didn't find an own font class in this Project.

HTH and TIA Markus

Hi Markus,

Thanks for providing the code! The problem is that there's a Font and Icon class defined in the Excel library, which conflicts with the Font and Icon classes in the SDK. There are 2 solutions:

1. Remove the USING Microsoft.Office.Interop.Excel command and supply this namespace when needed, for example change

LOCAL oWorkbooks AS Workbooks

to

LOCAL oWorkbooks AS Microsoft.Office.Interop.Excel.Workbooks

2. Keep the USING Microsoft.Office.Interop.Excel command, but prefix the classes from the SDK with "Vulcan.VO", this is the namespace used by the compiled SDK classes. So for example change

PROTECT oDefaultIcon AS Icon
...
SELF:Font := Font{,9,"Arial"}
...
SELF:oDefaultIcon := Icon{ ICONSTANDARD }

to

PROTECT oDefaultIcon AS Vulcan.VO.Icon
...
SELF:Font := Vulcan.VO.Font{,9,"Arial"}
...
SELF:oDefaultIcon := Vulcan.VO.Icon{ ICONSTANDARD }

Using either way it should compile fine now!

Chris

Chris,

Maybe one more addition to your comment about prefixing classes with namespaces.
We now also have the ability to define an alias for a namespace. So you can write:
This allows you to simplify the namespace in your code. Instead ofyou can then write
Robert

Hi Chris, hi Robert

first of all I have to thank for your really fast Responses!
It's a pleasure to work this way.

With These fixes I can compile the solution without Errors. Unfortunately the app crashes on the instantiation of the TreeView object. I commented out the try/catch in the start.prg to get more Details about the error but have no idea whats the reason for the Crash.

Thanks Markus

Hi Markus,

just a shot in the dark: do you have the cato*.dll files in the application directory? AFAIK the TreeView needs them too.

Wolfgang

P.S. I'm have successfully transported the FTPExplorer to X#, so the ListView/TreeView/SplitWindow work in X#.

Markus,

Was this really an app that ran in VO this way or did you copy and paste some code from different VO apps and combine this in the X# app ?

The Treeview and Listview class need a Point and Dimension argument to work properly.
In your MyTreeView class change:to

and in your clas IMSListView make the following change:

I could not completely test your app because I am missing the resources, and I have the impression that not all the code is there.
The Drive array is missing some array elements I think, and element # 2 in each row is not numeric as it is supposed to be.

Robert

Hi Markus,

In addition to what Wolfgang and Robert said, if the app still doesn't run without errors, can you please send also the VO .aef file so we can try porting it also in our machines?

thanks,
Chris

Hi Chris

here is the aef which works well in VO 2.8.
The program is just a sample which I want to use in our next VO Usergroup Meeting to demonstrate the way from VO to X#.

Markus



Attn. Robert: The error with the ListView was my fault as I tried different Things and did a copy&paste mistake.

Hi Markus,

I've looked a bit at your sample. First: I have very few applications that are larger...

And it contains several constructs that even the VO compiler should never have accepted, like assigns without parameter, or code pieces like this:

or this one:

If a method is declared "as pascal", then the parameter needs to be typed.

And .NET has a much better COM implementation than VO, so please use the relative COM interop, instead of this gigantic MSExcel module. This blows up only the application and generates a lot of code that will never be used.

Wolfgang

P.S. the X# compiler has found several parts of incorrect code like these also in my own applications, and I have corrected them on the VO side

Hi Wolfgang

yes, it's true that this sample has some very strange constructs.
I took this application as a sample for our next VO-Usergroup Meeting to Show the various hidden pitfalls in our old VO Code which runs without Problems. I'll also write a PDF with all steps to resolve the Problems and will it share together with the solution.

Markus

P.S. I will do the same with my real applications: port them to X#, correct the Errors on the VO side, port them again and so on.

Hi Markus,

yes, I have seen the readme of this application.... Personally I would try to move another one - I don't think this one works well as sample as it takes too much time to be xported.

I'm too preparing a PDF of my migration experiences, and I hope some of our experiences will make both the compiler and the xPorter better suited.

Wolfgang

Hi Markus,

Thanks a lot for sending!

I see that the classes MyTreeView, MyListViewColumn and MyImageList are new in the X# version of the code, you have added those because in the VO code, there were methods "injected" to the respective SDK classes. Of course that's correct that you did it, you just also need to supply the constructors, as Robert said. Also for the class MyImageList, you need to add one:

CONSTRUCTOR(nImages , oDimension)
SUPER(nImages , oDimension)

and restore your original code in the IMSDirectory constructor:

SELF:oImageList := MyImageList{SELF:_nCount, Dimension{16,16} }

Btw, I know, in VO you would not need to specify the constructors in the subclass, because constructors get inherited in VO. But in .Net this is not designed like that, you need to always supply the constructors. But we are working on an option to make the compiler automatically emit the missing constructors, with the correct signature, this will be possibly included in one of the next builds.

Apart from that, I see why you got the runtime error, as you said this is due to a typo in the changed code of the FabGetLogicalDrivesArray() function. Btw, you can actually use the original function as is in VO, only thing you'll need to change is:

pszDrives := PTR( BYTE, MemAlloc( dw ) )

to simply

pszDrives := MemAlloc( dw )

After making those changes, I see the app is running, although it will probably need a couple more changes. Please let us know how it work for you now.

Chris

Hi Markus,

Just one more thing, I see in IMSDirectory:FIELDGET(), you have commented a call to SELF:FileDisplayName, because the compiler complained that you did nothing with the return value. But the call of this access is necessary for the app to work properly, so you can change it like this:

LOCAL cDummy AS STRING
cDummy := SELF:FileDisplayName

and now the app runs nicely in x#!

Chris

Hi Chris

thanks you a lot for your fast and valued help!

The functionality for emitting the missing constructors in subclasses would be very helpfull. In my real application which is 100x the size of this small sample I will have thousands of These constructs.

Have a nice Weekend
Markus

Hi Markus,

Do you mean you have thousands of classes that are subclasses of the SDK classes and you have not supplied constructors (Init() methods in VO), or that there are some classes like that and you call them in thousands of places? Because if it's the 2nd case, then just adding the missing constructors in a few places will automatically make the rest of the code work well. If it's the first case, then yes, we definitely need to implement this option

Btw, we'd very much appreciate it if you can prepare as you said a document describing your experience with porting this VO app to X#, the solutions you had to implement, changes to make etc, as this will be invaluable help for other people as well when they make the port of their applications. I know Wolfgang is also already working on such a document(s) with his experiences, the more people do this the better it is! We will be adding more related information also ourselves, but it is always better if you guys present the info from your perspective.

Btw, Wolfgang, Markus' app looks like it requires too many changes to port it to X# because it uses a huge module containing classes for Excel interoperability. But this code does not need to (and cannot) be ported, it can be instead replaced with a reference to the Excel iterop library, which Markus has already done. After doing that, there are still some changes needed, but they are not enormous any more

Chris

Hi Chris,

yes, most "normal" code is easy to port because the compiler is very compatible. But unfortunately there are some hacks and bad code in many applications, often copied from a sample, and sometimes code that should never have been compiled by the VO compiler.

Some of my applications will be easy to port, and some harder, but it is worth the work because code get cleaned up and (hopefully) be more robust.

The main problem with VO is that let programmers work with like with C/C++ - this was very welcome because there were only few limits, but it makes code harder to migrate.

And often it is better do discard code completely and rewrite it in clean .NET code using the functionality of the framework. For sure this is the case of the Excel library, and it was the case with my httpComm library that works much better in X# than it worked in VO (where it needed some hacks to work over https).

Anyway, I'm dedicating time to the migration and to the documentation, but since I had many small issues in wLib2, it is much more work to document and explain the changes than to make them.

Wolfgang

Hi Chris,

and I forgot: in most of my applications the DBServers don't even have an init method - only the class declaration and maybe some access/assign and method definition.

Therefore an automatic constructor generation would be very helpful (but it should be not to much work to add 100 or 200 constructors - will do this in VO code before the migration).

Wolfgang

Hi Wolfgang (& Markus),

Sorry for the confusion, but there is no problem at all with classes already defined in your VO code, because for those the VO-Exporter automatically generates the missing constructors in the ported code.

The issue in Markus' case was that he wrote the new classes _after_ he exported the code, in which case he must define also the constructor or that new class. For already existing classes it's no issue.

Chris

ps. looks like I should really not be making posts when it's 35-40C all day