Variable type error issues and problems with the automagical approach to types

Questions about Thunkable
1

There’s definitely some automagical stuff going on around variable types, but there are also situations where the need for to_int or to_string type functions would be useful, especially around APIs.

Specific example. The MAP component insists on lat and lon as numbers. It will fall on it’s face if you give it strings…

… BUT lat and lon are often treated as strings, so if you pull a lat and lon from an API there’s a good chance you end up with a string.

So the life of a variable initilized for lat could be:
initialize lat = 0 (numeric)
hit api lat becomes “40.123456” (type converts to string)
hit map with lat = “40.123456” and it falls over (creating a thunkable app crash)

The workaround I’ve found is to use Math.

“40.123456” + 0 = 40.123456 (converts string to number)

Keifer

2

That is the work around I use for converting text to numbers. For numbers to text, use the JOIN block with just one element (the number).

1 Like
3

I agree those would be handy. It’s easy enough to make your own converter function(s), though, until we have built-in ones.

3 Likes
4

OR blocks like map make implicit conversions for us. Just saying…

2 Likes
5

Can you say that in a different way? I don’t understand.

Thanks

6

That actually makes a lot more sense! There’s no reason to send a string to a map component for a lat/lon value. So if you sent it the string “40.123456” it would just convert it to the number 40.123456 and use that for the lat/lon input value. If you sent it the string “hello” it would return an error.

7

There’s a Thunkable Use Case if I have ever read one. :wink:

8

Nope. If you send it a string, even though that string contains an integer the map component blows up.

9

@keiferwq We were talking about what we wish Thunkable could do. Not what it can do right now.

For now, you have to convert the string to a number by adding 0 to it.

2 Likes
10

Oh… I see. Agreed.