Global boolean variable resets to false or no value selected when manually editing

verified

#1

Background: When testing a piston, I was setting a boolean variable manually, but each time that I try to set it, it defaults to…

false if the value is true
no value set if the value is false

However, if you have set the value through the piston editor, the value will remain the same.

Steps to replicate behavior:

  1. Create this piston (code 6djjn)
  2. Click add new global variable
  3. Select type “boolean"
  4. Enter variable name test
  5. Click Add
  6. Save the Piston
  7. Test the piston to set the value
  8. Edit piston
  9. Click on variable “test”

Actual Behavior
Value of variable changes from false to “variable not set”

Desired Behavior
Variable maintains current value “false”

Notes
You can change the above piston to set the value as true (instead of false) then you will get this result…

Actual Behavior
Value of variable changes from true to “false”

Desired Behavior
Variable maintains current value “true”


#2

I am not sure if this applies to you, but just be aware that when there is a change to @test (a global variable), it will NOT be visible to that current piston until the next run. If you want a variable to be changed and used in the same code a few lines lower, you should use a local variable. (without the @)

For example, lets assume the global @test is true before the piston runs. If we use the code:

Set variable @test = false
IF @test is false then send SMS

This means after one run, you will NOT get a SMS, but running it a second time you WILL.

Another way to say all of this:
Global variables are frozen while a piston is running, and will only update after the code has finished running.

A good way to think of this is globals should be read at the beginning of the code before anything is done, and written at the end, once everything has already happened.


#3

Thanks for the information. That was interesting, but I tested what you are stating and it seems that a piston can see a global variable. Maybe that was a previous bug?

This piston increased the testint variable every time that I ran it.

But the bug that I am describing still shows up. (Note: it is really a minor, minor bug.)

Here is how the bug manifests itself in edit mode…

Note that the value is false, but the edit variable dialog box states it is not set.

For other types (except datetime), the edit variable dialog box shows the current value.

Again, a really minor issue for true/false, but the issue may be related to this bug…

In this case if you have a datetime set and need to adjust it a bit to test a piston, you have to remember the date and time then enter the entire thing.


#4

I confess, once I learned about the global limitations, I have never tried to write to the same global twice in the same piston like you did…

My understanding is that this code will never run the highlighted region.

temp

Something might have changed in webCoRE. Maybe one of the @webCoRE_Minions can confirm this new behavior?


#5

I’m relatively new to WebCore. I understand what you are saying, but I hadn’t run into that before and wanted to make sure that I had no handicapped pistons, but it does appear to work as one would expect now.


#6

Well, until we hear confirmation on changes to the code, I will continue to use LOCAL variables for any immediate processing, and GLOBALS as more of a long term storage option or when I need to share the data with another piston. (locals can and do update instantly)


#7

by global limitations do you mean that global variables value is not updated outside of the piston till the piston changing the global variable value completes that run of the piston?


#8

Yes. I love global variables, but I use local variables when I need immediate processing.


#9

well the scope of the local variable is local so when that works … thats great. the scope of the global variable is global … but till the piston is done executing the scope is local and works the same as local variables.


#10

Hot damn! This is the first mention I have ever seen about this… THANK YOU!

So basically, within the same piston, globals act the same as locals… but no OTHER piston will see the global changes until the piston has completed it’s run… Correct?


#11

yes.


#12

Pure genius!

And all this time I have used locals in the beginning of my code, and globals towards the end.

Sorry to have lead you astray @HAL2000… WebCoRE is definitely one of the things where we learn something new every day!


#13

Regarding OP, this is very strange! The boolean global once set by the piston to false actually has the value [] (an empty array). It is displayed in the globals list as false simply because webCoRE considers an empty array to be falsy. That seems like it may be fairly harmless as long as nothing checks that the value is explicitly false.

When the piston sets the value to true it does get set explicitly to true so this should not cause any issues making use of the variable, however the global variable editor ends up mapping that to an expression and the expression it chooses is "false" while of course it should actually be "true".

This is all very odd. Perhaps related to the datetime global issues that you found, I’ll at least take a look in the same place for fixes to both.


#14

I think I have the correct fix for boolean globals but need to spend a bit more time with it before having the minions test out the fix. I’m trying to stay safe and avoid any changes that could have seemingly unrelated consequences since this passes through a very core block of code.


#15

I have a bit of testing experience. Let me know if you need any assistance.


#16

This fix has been published to ensure that boolean globals show the correct value when editing. See the announcement for more details about the release