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?
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.
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.
XSharp Development Team
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:
for nI = 0 upto nFiles -1
or this one:
assign ReadVersionOnTheFly( lSet) as logic pascal
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.
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
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.
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.
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:
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 ) )
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.
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
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.
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
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.
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.
ps. looks like I should really not be making posts when it's 35-40C all day