~~commandScoped variables persist on the queues

[DeckerdJames]

Hello, is it true that ~~commandScoped variables that are passed into a queue with Enqueue will persist as long as the queue does and is that an intended feature?

I think I discovered this for myself because I have been passing ~~commandScoped variables as part of my event log routine and in a certain part, I did not set a new ~~eventMessage so it was not set, but when the unset message was sent to the queue, it printed out the previous message (which then appeared twice in the log). So the ~~commandScoped variables retain their value until that are set again, even when being called by different commands, as long the command doesn't reassign something to that ~~commandScoped variable. In other words, when a queued command completes, any ~~commandScoped variables are not discarded.

[Pfeil]

If a variable is set by a command, and that command enqueues another command, the queued command, and any commands executed by that queued command (when using a method that preserves the chain) will have access to command-shared(I.E. "~~" prefixed) variables.

However, each queued command only has access to the variables set within its chain of commands.


E.G. if you have a command that sets a command-shared variable, which enqueues a command, and then that command is executed again outside of the chain (E.G. by voice), the command it enqueues will have a different version of the variable.


This series of commands will verify that:
Command 1

Code: [Select]

Pause all command queues
Set text [~~variable] to '{TIMESTAMP}'
Enqueue command, 'get value' into []
Enqueue command, 'get value' into []

get value

Code: [Select]

Write [Blue] '{TXT:~~variable}' to log

Command 2

Code: [Select]

Enqueue command, 'get value' into [] (and start queue execution immediately)


Run "Command 1" twice, then run "Command 2"; The resulting log entries will show two identical timestamps, then another two timestamps which are different from the first set of two but identical to eachother, followed by "Not set" for the final entry.


Note, however, that two different commands assigned to the same queue from the same command are not considered part of the same chain (I.E. each command queued will be part of a different chain, branching off at the point they are enqueued).

E.G. if you have a command that sets a value, and a command that retrieves said value, and both are enqueued by a single third command, the command that gets the value will not have access to the value set by the command that sets the value.


Each queued command keeps with it its own individual set of chain-scoped (command-shared) variables, as they were set at the time they were enqueued, as demonstrated by this command:

Code: [Select]

Pause queue []
Set text [~~variable] to '{TIMESTAMP}'
Enqueue command, 'get value' into []
Set text [~~variable] to '{TIMESTAMP}'
Enqueue command, 'get value' into [] (and start queue execution immediately)

Which will write to different timestamps to the log.



If the behavior you are observing is not consistent with this, provide reproducible example commands so it can be checked.

[DeckerdJames]

Event Message Handler (command name)

Code: [Select]

Write [Blue] '{TXT:~~EventMessage}' to log

New Command 1 (command name)

Code: [Select]

Set text [~~EventMessage] to 'Set from Command 1'
Enqueue command, 'EventMessage Handler' into [Event Handler Queue] (and start queue execution immediately)

New Command 2 (command name)

Code: [Select]

Enqueue command, 'EventMessage Handler' into [Event Handler Queue] (and start queue execution immediately)

New Command 3 (command name)

Code: [Select]

Execute command, 'New Command 1' (and wait until it completes)
Execute command, 'New Command 2' (and wait until it completes)

Output:

When I execute Command 1

6:07:51.216 Set from Command 1

When I execute Command 2

6:08:00.917 Not set

When I execute Command 3

6:08:04.557 Set from Command 1
6:08:04.547 Set from Command 1

What I had expected when executing Command 3 was:

{Time Stamp} Set from Command 1
{Time Stamp} Not Set

I was hoping to understand whether my expectations were right or wrong.

[Pfeil]

You are executing both "Command 1" and "Command 2" from the same command: "Command 3", making "Command 1" and "Command 2" part of the same chain (starting with "Command 3"), so the behavior is correct.

If you execute "Command 1" and "Command 2" separately, the output will be what you're expecting.

[DeckerdJames]

Got it! Thank you very much.