xsharp.eu

Hello Wolfgang,

No it's not simple, at least not in my projects. We're talking about classes spread over a dozen or so AEF's and I can not move most code (which Chris already suggested) without introducing issues. I just want VOXporter to refrain from creating code which introduces dozens of errors and for which I didn't ask for in the first place.

I've just removed 23a and reinstalled XSharpSetup22aFox and after that back to 206GA. Both had the same issue. But when I checked "AllClassesPartial" in 206GA I did not get the external classes with 110 XS9016 errors but only warnings. After clearing a couple of other errors, which was again possible with this version, I ended with the expected "Missing class" errors which I can solve by adding temporary class/method code. However, this does not happen when I reinstall the latest version and convert with VOXporter 2.3.1.0.

@Chris/Robert:
1 is it possible to just keep VOXporter.exe 2.0.0.0 (the one of 206GA) to continue, instead of 2.3.1.0? AT least I can go on with that.
2 Would it be possible to return the behavior in XSPorter, if necessary with a checkbox, that the external_class statements with the 100's of unnecessary XS9019 errors aren't generated?

I am certainly not going to delete those unwanted external_class errors manually. If I can only go on like that I will (once again) put X# aside and stay in VO.

Dick

Hi Dick,

1. Yes, you can actually keep a complete backup of the XsharpVOXPorter folder of any X# version, copy it anywhere in your disk and then you can run the .exe from it directly.
2. What would you like VOXporter to do, to just delete all the methods that you have written in VO that are external to their respective .aefs?

Hello Chris,

Chris wrote:Hi Dick,

2. What would you like VOXporter to do, to just delete all the methods that you have written in VO that are external to their respective .aefs?

Somehow I think you are still missing the point (or I do)

I have NOT written these methods in VO.

Example:
#warning The following method did not include a CLASS declaration
CLASS IC2DBServer_external_class INHERIT IC2DBServer

I assume VOXPorter added this because in the lib I am trying to prepare for X#, IC2dbServer is not present.
So what happens? The methods belonging to IC2dbServer ALL give this error:
METHOD ReturnADSType CLASS IC2DBServer
-->
Error XS9016 Class name IC2DBServer for method differs from parent class name IC2DBServer_external_class IC2 lib

When I used the 2.0.0.0 XPorter with Partial Class checked, I did not get line like these 2 in red. But of course I did get compiler errors that IC2DBServer was missing. That's fine. I fix that temporarily until I merge all AEF's.

But I simply don't want these 2 lines of code x so many classes to be inserted.

Dick

Hi Dick,

OK, so in this particular case, the exporter sees this method, that does not belong to a class in your aef:

METHOD ReturnADSType CLASS IC2DBServer

What do you want the exporter to do with this method? It cannot surround it around a class named "IC2DBServer", because this class is defined in another library. It also cannot leave it just like that, without a CLASS..END CLASS, because then the compiler will complain that the class declaration is missing.

Hi Dick,
if you are expecting that the XPorter or the compiler can fix these issues alone, IMHO you are expecting too much.
The rule that you cannot add a method to an existing class is imposed by the .NET Framework.
AFAIK In the .NET world the method calls are resolved by early binding, whereas the VO runtime does a complete different thing: it builds the class/method structure at runtime and in memory. That has not only negative consequences to the memory footprint and execution speed, but inhibits you to use a library in both a DLL and the relative EXE.
Maybe the XPorter could transform your additions to extension methods, but this will fail if you are accessing protected variables of the class.
It may sound hard, but you need to make the needed changes at the VO side - no migration will be at no cost, and I think we cannot do more than show you how to change your code that it will remain compatible between VO and X#.
Wolfgang

Hello Chris, Wolfgang,

First, @Wolfgang, I do not ask or expect the XVOPorter do do things for me, I am just trying to get done that the XVOPorter is NOT doing something for me...

Chris wrote: It also cannot leave it just like that, without a CLASS..END CLASS, because then the compiler will complain that the class declaration is missing.

That is exactly what I want the XVOPorter to do. I have some more info. The unwanted external_class code is still inserted when I uncheck RemoveClassClause, both in 2.0.0.0 (contrary to what I wrote earlier) and in the latest version. But instead of a XS9016 error it now shows a warning XS1030, e.g.

#warning The following method did not include a CLASS declaration
PARTIAL CLASS adres_external_class INHERIT adres

So I can probably continue the way I want to work (see below to be complete) : I can remove the real errors, create the temporary classes, and re-import which, I hope/expect does not insert these classes at that time & I can have the class statements like they are in VO added!

In short: I do not want the external_classes added. I only want that after METHOD X the XVPorter leaves CLASS Y as it is (required) in VO.

Probably as an option so anyone who enjoys the addition of these external classes & dozens of errors can keep enjoying these :woohoo:

Is that something you can easily fix with this information?

So this is what I want to do:

1 No code generated polluted with external_class code
2 So no more errors XS0916
3 Compiler errors for every missing class instead
4 For that I create a one time _TempClass.prg with everything is missing
5 I can re-XPort as often as I like, as long as I add this _TempClass.prg to the result (and anything else I added, like OLE code)
6 When all AEF's are error free I create 1 full conversion of the main project with the libraries. No doubt that will give me new errors. But preparing everything this way I expect to seriously bring down the number of errors on converting the whole project.

Dick

Hi Dick,

In this particular case of having

METHOD ReturnADSType CLASS IC2DBServer

if we make VOXporter behave as you suggest, it will effectively tell the compiler to create a NEW class named "IC2DBServer" in this library, containing ONLY this method "ReturnADSType". So, everywhere in this lib you are using this class name, the compiler will always think you are referring to this small class containing just one method and will be reporting errors everywhere (in this library) you are using something from the "real" IC2DBServer or its parent class.

So if you have for example

FUNCTION SomeCodeHere()
LOCAL oServer AS IC2DBServer
oServer := IC2DBServer{...}
oServer:GoTop() // error XS1061 here
oServer:Skip() // error XS1061 here
oServer:MYFIELD := 123 // error XS1061 here
oServer:Close() // error XS1061 here

the compiler will think you are using the class IC2DBServer with that one method only and will be reporting "unknown method" errors for all code that uses GoTOp(), Skip() etc. So you will be getting probably 1000s or more of such errors in your library. Is this you really want? If yes, I can indeed add an option to make it behave like that, but I am trying to understand why you prefer this to the current behavior.

What that "external_class" postfix added by the VOXporter is meant to do, is avoid the above problem, by separating the real class, from that new one implicitly generated due to the added external method.

One small issue is that because you have disabled the removal of the "CLASS xyz" clause in methods, there is a mismatch now between the surrounding class declaration and that CLASS clause. I can look into adjusting the class clause, so VOXporter modifies that also into

METHOD ReturnADSType CLASS IC2DBServer_external_class

so there will be no error XS9016 anymore. But just leaving it as it is, without changing the class name will lead to the problems I am describing above.

Hello Chris,

As you can read in the previous question I have added the missing classes. This seems to help me in my goal: after adding this .prg I do indeed get 2396 errors, most of these XS0103 ...does not exist in the current context.

But I can sort on the error numbers and concentrate on the real errors, now also present in this list (and these were not present in the list showing the XS1030).

If I have corrected the cause of the errors in the original VO code and/or found and documented an explanation for the other errors my plan is to continue doing the same with the other libs.

After that I hope to be able to XPort a complete program (main program, libs). I assume, as then the classes & methods used are defined in any of the other programs, not only these XS0103 errors are solved, but more importantly, the external_class statements are no longer inserted while my classes are added to the method like in VO.

Am I correct? If that's the case, and as I can now continue, a change is not needed for now.

Apart from this I still fail to see the advantage of the external_class additions. This does not prevent compiler errors after all.

Dick

Hi Dick,

That "external_class" is not there to fix problems. It is just a way to tell you that the method inside this class is orphan. We could had made VOXporter simply delete it, but then you would not be aware of what is the problem.

The only solution to the problem, is to use one of the suggested earlier ways to insert those missing methods in the correct place, inside the library (aef) where the method's class is actually declared.

Hello Chris,

Chris wrote:,
The only solution to the problem, is to use one of the suggested earlier ways to insert those missing methods in the correct place, inside the library (aef) where the method's class is actually declared.

That is absolutely impossible, unless I make one big AEF for every project we have containing all code and copy all this code a few dozen times among all projects we have. I would say the whole idea of libraries is that you put commonly used code there. We have a few levels of "common-ness"; IC2.lib is very general while another lib is still general but not used in all projects.

I thought that I can use PARTIAL classes to have methods of that class in multiple projects, included as references in the X# solution, like we we do in a repository in VO. So what I want to see is:

AEF IC2.LIB

PARTIAL CLASS IC2DBServer INHERIT dbServer
METHOD ReturnADSType CLASS IC2DBServer // In IC2.lib because it needs some functions only present in this AEF
// Do something
END CLASS

AEF IC2DBServer (reference to this from IC2.lib)

Then, in the AEF IC2DBServer, I have the full definition of IC2DBServer, with all methods used in several AEF's (like IC2.lib). When I convert this I expect to see something like this:

CLASS IC2DBServer INHERIT dbServer (or also with PARTIAL before it)
METHOD X class IC2DBServer
METHOD Y class IC2DBServer
END CLASS

After I've solved as many errors as possible, per AEF, I will XVOPort a complete program, where these library AEF's are included.

If it looks like above, errors in IC2.LIB that it doesn't know Method X or Y, will disappear because these are then discoverable in the referenced C2DBServer lib.

So my 2 basic questions are:

1 Am I wrong with my understanding that PARTIAL classes allow me to distribute methods of one class over multiple libs/projects/aef's?
2 Am I wrong in assuming that when I XVOPort (in the end) the whole project I get these partial classes (when checked) and no unwanted external_class inserted anymore?

Dick