I wish I could take the habit of using API2, for the long run, but since API1 is still supported, I usually write as I know (API1 syntax) and don’t learn API2 much.
If only there was a switch to deactivate API1, to learn API2…
3 Likes
While I haven’t tried, I’d give an attempt to this:
if String(“0123456789”).InStr(key)
Which wouldn’t require variable or constant. I’d expect this to work…
well yeah it still does require a constant… it is just you are casting it (unnecessarily) to a String… in this case Constant and Literal Value are the same thing
dim s as string = "12345678"
const c = "12345678"
if s.instr(key) then ..... // variable
if c.instr(key) then .... // constant
if "12345678".instr(key) then ... // literal
if String("12345678").instr(key) then .... // still a literal
heh 
you need more contortions than that to make it work
a cast wont work
this one gives you
Type mismatch error. Expected String, but got TextLiteral
If String("0123456789").InStr(key) > 0 Then
you end up needing to do
If CType("0123456789",String).InStr(key) > 0 Then
and this is also true in most places a literal might be used
Yes. I actually meant you avoid having “something” that holds the value (a dimmed variable or a constant defined).
Casting, in this case, wouldn’t be unnecessary, as it’s how avoiding a “holder” would work. It just enforces the fact that it’s a string, so then the dotation way works.
Yes, it was one of my requests, Some kind of STRICT mode to allow API2 only mode, but, they prefer the mess of just warnings.
I admit I never encountered this case (since API1 didn’t enforce this notation). I was also unaware of the CType function.
So it’s a matter of choosing to hold the string in a variable or use a “convoluted” way.
Now that I know about CType, I’d go for it if I ever come across this issue. Having a variable just to be explicit about the fact it’s a string (and allow methods on it) seems a waste of resources to me.
Thanks for pointing CType.
Well, I usually check for warnings after substantial changes; I don’t think I would notice I was using API1 before I’d have to rewrite a lot (thus avoiding API2 all the way).
Yes Norman.
But with iOS noted everywhere, that is how I was feeling things.
Also, Desktop extension (New Framework for Desktop) does not appears. So, I stayed with my wrong, understanding.
This was only a perception issue.
The problem with having to use a variable is that a literal is more like a constant
I could declare a local constant and do
const localNumbersConstant = "0123456789"
If localNumbersConstant.InStr(key) > 0 Then
...
End if
Again there’s a new “variable” of some kind ot have to go refer to when you look at that line of code
It’s all trade offs
This is one of my biggest pet peeves and I’m thrilled to learn about CType here. @npalardy do you know why a normal cast won’t work and does anyone know if Xojo is going to be make this easier/more intuitive down the road?
To be kind of simplistic about this a Cast doesnt alter the TYPE that same way Ctype does
Its more like a simple hint rather than a type conversion
Its all kind of hand wavy and really internal to how the compiler treats things
Suffice to say that CType DOES an explicit conversion and gives a “string” that can be used that way
they have not said anything about this and, on the case I filed, their replies dont seem to indicate they understand why this might be needed or useful case # 56629 which, despite at least 2 requests, remains private so only testers can see it
My simple example was
which, while trivial and frivolous, illustrates that there are things API 1 could do that API 2 cannot without adding variables constants or cluttering the code with CTYPE’s