Here's a couple pics that didn't seem to upload on my first post:

Hi Dave,

It looks like your first post included "pics" that didn’t seem to upload. I understand you’re troubleshooting the Running BG Color setting on the second user interface in Interface Builder. Let’s see if we can narrow down the issue.

A few things you can check:

Configuration Consistency:
- Double-check that the button controls on your second interface have the Running BG Color property set exactly the same way as on the first interface.
- Verify that any associated scripts are assigned in the same way and that no conflicting color settings (such as a different script resetting the background) are interfering.

Script Duration and Timing:
- Sometimes if a script executes very quickly the running state may not be visible for long enough. Consider adding a short delay (for example, using sleep(500)) at the beginning or end of your script to see if that allows the color change to register.
- Ensure the button’s script isn’t ending before the UI has time to update to red.

Control Naming/Group Differences:
- If you’re using different variable naming or if the buttons are part of a different user interface group, make sure that nothing in the script or interface settings is resetting the button’s appearance.

Platform or Version Specific Behavior:
- If everything appears to be configured identically between the two UIs, the problem might be isolated to this particular interface. Try duplicating one of the working buttons from the first UI and placing it on the second UI to see if it retains the functioning behavior.

Since you mentioned the images didn’t upload with your first post, if you’re able to share screenshots of the button settings (or at least provide a detailed description), that could help us better pinpoint any discrepancies.

Could you confirm if these settings match exactly between the two interfaces? Also, do you see any error messages in the ARC project logs when the script is running on the second UI?

Let me know what you find or if you need further help troubleshooting this issue. I'm here to assist!

All buttons are configured the same in both interfaces. The boarders are set thicker in the 2nd interface but the problem was there before I did that. I also thought about a quick script ending before the color could change. However the scripts run at least 10 seconds. As long as the scripts in the working color change in the 1st interface.

Show me the code to a button that doesn’t turn red if there's more than what's in the screenshot. What I mean by that is the code that runs when the button is pressed.

I ask because the code in the screenshot is this:

ControlCommand("Bing Script Support", "ScriptStart", "Impersonate Doctor Smith");

Nothing in that code is blocking, so the button can't show itself as "running" because it'll run fast. All that code does is instruct another script to run. No actual code (other than that control command) runs in that button.

For example, if you added a sleep(5000), you'd see that the button would stay red (or whatever color you set it) for 5 seconds. But without any blocking code, the script runs and exits too fast for any color change to matter.

You could use ScriptStartWait, I guess. This will wait for the child script to complete before exiting the button script.

DJ is spot on - in that a script button would only display the "running color" if the script is running. In this case, the script would run for a fraction of a second, not long enough for even a flicker of the button color. The ControlCommand (click on the words ControlCommand to check the manual, which dives deeper into explanation) is not a blocking call, unless the command it sends strictly defines it as blocking. DJ mentioned that using ScriptStartWait would wait for the child script to complete, which "may" display the color if the child script also takes time to run. However, if the child script also has non-blocking calls, you will experience the same behavior.

Below is an example of a button script that uses a blocking call so that its "running" color (red in your case) will remain active until the child script completes.

In this example, instead of using:

ControlCommand(Bing Script Support,ScriptStart,Impersonate Doctor Smith);

we use ScriptStartWait to block the button's script until the impersonation script finishes:

ControlCommand(Bing Script Support,ScriptStartWait,Impersonate Doctor Smith);

For example, a complete button script might look like this:

// Button script example using ScriptStartWait

// This will send the command to the "Bing Script Support" control to start the
// "Impersonate Doctor Smith" script and wait until it completes before continuing.
ControlCommand(Bing Script Support, ScriptStartWait, Impersonate Doctor Smith);

// Optional: add additional code after the child script completes if needed.
print("The impersonation script has finished.");

Here’s what's happening:

Using ScriptStartWait makes the button script wait until the child script finishes executing.
Because the button script is blocked during that time, the Interface Builder will display the running (red) color for the entire duration of the child script.
In contrast, using the nonblocking ScriptStart causes the button script to exit almost immediately, meaning the running color may not be visible.

If you need to simulate a delay (for testing purpose), you could also insert a sleep command. For example:

// Blocking version with an added delay to simulate a long-running action
sleep(5000); // waits for 5 seconds

Keep in mind that if the child script itself uses only nonblocking calls, the overall blocking behavior will only last as long as the child script takes. Using ScriptStartWait ensures the button remains in its running state until the entire operation is complete.

Let me know if you need further assistance or have any additional questions!

This all makes perfect sense now. The interface button is watching the length of the very short ControCommand in it's script section and not the script that the ControlCommand is calling that's located outside of the user interface. Thanks for the help. I guess I didn't think the process through.

I used @DJ's suggestion and used the ScriptStartWait ControlCommand. This method works great. When I now click the button in the interface, it turns red and stays that way until the script it's calling outside of the interface finishes. Such an elegant solution. Thanks! cool

In addition to my last post;

I found that even though when I use the ScriptStartWait, sometime I still need to add a sleep command to the end of the script to keep the button in the running color until the animation or movement is complete. This is understandable because the script will only send commands and sometimes will stop running before the commanded movement is complete.

I just thought I'd add this observation to round out this conversation.

Thanks again for the help.