GP Beta Test Forum

Not mainstream but in trying to write networking stuff using primitive GP elements such as

openClientSocket

I'm finding that GP is very "moody" over what it thinks is an acceptable Ip address

it won't accept 1.2.3.4, (thinks its 1.2) - it usually accepts join (1.2.3.4) () or join (1) (.) (2) (.) (3) (.) (4) but not always - once it doesn't project needs to be saved then re-loaded

It won't accept to string (1.2.3.4) - thinks its 1.2

basically GP treats anything with a . in it as a number (most of the time)

I think if GP should treat any field in a join as being a string - even if it has a . in it

If you used "blockify", you may have created the block with a number input slot vs. a string slot.

Note the difference between blockifying this with quotes around 1.2.3.4:
versus no quotes:
You'll notice that in the first case you get a square ended input slot (string) and in the second case you get a rounded input slot (number). In the second case, GP also tried to interpret 1.2.3.4 as a number, but it only took the first three characters because you can't have two decimal points in a number.

Moral: when using blockify, put single quotes around anything that you want to be sure is a string.

Got it

So this was one of those things where the question wasn't, why didn't it work all the time, but in fact how come it worked some of the time :)

The "number or string" input slots in v75 do a much better job at detecting things that start with a digit but are not numbers, such as IP addresses.

So '1.2.3.4' or '3 + 5' will not be treated as strings rather than trying to force them to be numbers and getting values like 1.2 or 3.

In addition, you can now use a context menu force an input slot to expect only numbers, only strings, or either (with the slot guessing the user's intent based on whether the format is a legal number:
Note that an input slot set to 'string or number' will change shape to indicate when a number is recognized. Square ends indicate that the contents is being read as a string, rounded ends indicate a number. In 'number only' mode, the slot will only accept input that is a valid integer or floating point number.

String:
Number:
Number treated as a string in 'string only' mode:
With these changes, users will have control over the difference between strings and numbers in input slots.

Excellent - I'd been running into issues and using join to overcome them - will let you know if anything crops up now

The only thing I'd mention at moment is that if you try use a returned numerical value in a place that expects a string - it fails unless you explicitly convert

It'd be nice if it didn't but arguable that it fact it should fail :)