xsharp.eu

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