Is something wrong with the bit switch compatibility flag of external methods?

This comes from working on iOSLib, but I have the idea it’s valid for every platform – therefore here in general:

I decided to keep the 32/64 bit classes in iOSLib to keep it compatible with older Xojo versions. The external methods seemed like a good way to save a lot of typing: For methods using CGFloats, I installed external methods like

Private Declare Function rotateByX Lib SceneKitLib Selector "rotateByX:y:z:duration:" (id as ptr, x as double, y as double, z as double, duration as double) As ptr
And I set their scope to 64 bit only, duplicated the external method with singles now (except Duration), set its scope to 32 Bit and had only one public method

Shared Function RotateBy(DeltaX as Double, DeltaY as Double, DeltaZ aS Double, Duration as Double) As AppleSCNAction dim result as new AppleSCNAction (rotateByX(classptr, DeltaX, DeltaY, DeltaZ, Duration)) result.retainclassobject return result End Function

This works nicely with 32 Bit and it compiles to 64Bit, but on running it in simulator with 64Bit it didn’t work. Objects simply disappear. Obviously the setter receives wrong properties, and it looks like the 32 bit external method is still being used. I tried it with only one external for both sizes/scopes using CGFloats and this works ok.
Is there some problem with the scope of external methods? Or some problem with my concept of it?

Just FWIW the 32 bit / 64 bit switch is not their “scope” - its a compatibility flag
Its possible its not be being respected by the IDE as its the IDE that evaluates that and decides which code to send to the compiler depending on what type of compile is taking place

Thanks, Norman! Yes, right after posting I had the idea scope is not the right term … but I didn’t find any better. Thx!

So you mean better not depend on it and either use #If Target … clauses or CGFloat? It’s great we can run on 64Bit simulator but if it gets the wrong declares I would better step on the secure path …

I think there’s a bug report about this but I’m not certain

I tried to find one, but scope didn’t bring the right search results :smiley:

There are a few that may be related

But I dont see one that specifically targets the situation you’re seeing
A new report with a quick short example would be good

Thanks, I’ll try to write a small demo instead of forwarding iOSLib.