Hello Jonas!

I'm getting along quite well with implementing my first real Android application, but now I've hit a little problem: to start a new activity I need to pass the class type as a parameter which is declared as "java.lang.Class". If I give my class type as a parameter (which derives from one of Android's activity classes) the compiler complains with the following error:

TrainLog.lpr(249,53) Error: Incompatible type for arg no. 2: Got "Class
Of TTrainTypeActivity", expected "JLClass"

What is the best way to solve this? I know that there is a "getClass" function declared in JLObject, but that is an instance method and I don't have an instance of my new activity yet and also I don't think that it is wise to construct an instance of an activity class manually.

Regards,
Sven

Ok, I could simply solve this by doing a typecast
"JLClass(TTrainTypeActivity)", but couldn't the compiler do this automatically? (as this looks a bit unclean to me...)

Regards,
Sven

Sven Barth wrote

Ok, I could simply solve this by doing a typecast "JLClass(TTrainTypeActivity)",

That's indeed the proper way.

but couldn't the compiler do this automatically? (as this looks a bit unclean to me...)

It completely clean. The better way to solve this would be to modify the javapp parser to generated overloaded versions of routines expecting a JLClass parameter with a version that accepts "class of JLObject" or similar parameters.

Jonas

Ok, if you say so. Thanks.

Regards,
Sven

The main problem is that the more magic conversions are added to the compiler, the harder things become to maintain (both for the JVM target and for other targets).

Jonas

I understand that, but from a user point of view it's rather confusing (Strings are another prominent example here). It might be a good idea if someone (not necessarily you) writes down these little caveats so that others don't need to hunt down these problems again.

Regards,
Sven

To explain what I mean with "Strings" here:

I have code like this in my application (all units $H+ and $modeswitch unicodestrings):

var
   s: String;
begin
   s := SomeJLStringReturningFunction;
   s := 'SomeConstantString' + s;
   DoSomethingWithJLString(s);
end;

because this code:

var
   s: String;
begin
   s := 'SomeConstantString' + SomeJLStringReturningFunction;
   DoSomethingWithJLString(s);
end;

and this one:

var
   s: JLString;
begin
   s := 'SomeConstantString' + SomeJLStringReturningFunction;
   DoSomethingWithJLString(s);
end;

do not compile (both complain about "operator not overloaded" at the concatenation).

Regards,
Sven

Strings /are/ handled by compiler magic in all cases, no?

It might be a good idea if someone (not necessarily you) writes down these little caveats so that others don't need to hunt down these problems again.

If the header parsing is adapted, most cases should be handled automatically without requiring any compiler changes. Actually, the same could be done with strings (replace all occurrences of JLString in the headers with Unicodestring, and then remove most special code for JLString from the compiler).

Jonas

Sven Barth wrote

I have code like this in my application (all units $H+ and $modeswitch unicodestrings):

Another good reason to not use compiler magic: it requires lots of changes all over the compiler to make sure that things are handled correctly under all circumstances (because as indicated in my previous reply, I did try to change the compiler so that jlstring and unicodestring became interchangeable). Changing the generated headers is much more robust.

Jonas

Somehow I'm coming to the conclusion that you're right. So more "Pascalisms" in the import units is the way to go?

Regards,
Sven