Data Types – Codeblocks

Here we have four code blocks relating to a height parameter.

The parameters values block expects a list or collection of data.

The list can be composed of any of the other data types.

In this example, though, it includes just two pieces of numeric data, ten and eight.

The next block is a value block and expects a numeric data type.

Third in the list is a label block which expects a text data type. In this case, the word length.

The last block is a read only block, which sets a parameter to be editable or not editable in the form.

This block expects a true false data type.

Here, we modify each block to see how it relates to the form.

First, adding a new number value of seven to the list.

With a click of the update button, we see our new value.

Next, we change the number for the values block, just as an example, to understand how we set a new value.

On to the label block, we change the text to read Hello World.

We update the form and see the change.

We'll quickly change that back to read length so that the label makes more sense.

Lastly, We'll change the read only block to be true and see how it impacts the form.

Quickly, we'll change that back to false. So the user can input values.

Next, we'll add a new parameter block and see how it handles data type changes.

First, we'll pull a number block from the math category of code blocks and snap it to the parameter value block.

In addition to accepting a simple number block, the value block will also accept mathematical equations.

We'll move the eight down into the new block and then set it up to subtract one.

Let's take a look at what happens when we change the block from value to the plural values.

Notice that the block kicked out the equation block. Since values expects a list data type and not a numeric.

Attempting to snap the numeric equation back to the values block is of no use. As it is smart enough not to accept a data type that could generate an error.

Maybe it's the equation. Will it take a number?

Nope. It won't.

Let's try a string of text.

We'll pull a basic text block from the text category of code blocks and set it to read test.

Nope. The values block does not accept string values either.

A glance at the example above and we see that the values block expects a list.

We'll pull a create list with block from the list category of the code blocks and attempt to snap it to the values block.

Finally, we have matched the values block with a block of the data type it expects to receive.

Notice that the list block will accept the different data type blocks.

What happens if we change the block from a values block to a label block.

The labels block kicks out the list block.

Will it take a number?

Nope. Maybe a text block then.

Indeed.

The label block wants a text data type to hand the form label.

Finally, we'll change the block to a read only block and run it through the same tests just so we can understand how the various block types expect different data types.

This helps learn to recognize the way that code blocks kick out incompatible data and block them from snapping together to prevent data type mismatch errors.

In summary, different code blocks expect different data types attempting to snap a incompatible data type to a code block is prevented.

The general code block data type categories are text, numeric, lists, and true false.