nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

When to use Wait(0)?

nkelleh

Hi All,

I have a question regarding what is best practice regarding when to use 'Wait(0)' command in a JSL script.

I guess there are times when your script can get ahead of itself in terms of executing code before a previously scripted operation has completed, and putting a wait(x) command after such operations is one way of trying to ensure that the operation completes before continuing with your script.

I'm just wondering when should you be concerned about this? For example, if I'm splitting a datatable, do I need a wait(0)? How about sending a '<<Select Where()' message to a datatable? Its just that I'm finding this kind of information hard to come by, and it seems that you just have to run into certain problems before you know when its required?

Also, whats best practice when it comes to using a Wait(0)? I know in the case of waiting for formulae to evaluate in a dt, you would be better served by sending a '<< Run Formulas' message to a datatable instead of using a wait(0), but its not so clear cut in other circumstances.

Apologies if this seems a rather broad/vague discussion. It's stemming from the fact that I'm trying to improve the execution time of a script I have, and the profiler is saying that a lot of time is being spent on these wait commands that I've inserted after the type of operations mentioned above. I appreciate any insight into this or if there are resources available that I can look at, even better. Cheers!

Accepted answers

David_Burnham

"it seems that you just have to run into certain problems before you know when its required" ... I'd agree with that. Using a wait unnecessarily will slow your code down. I only use it if my code fails and the Wait is the only way to fix it.

I've done a quick search on my code and here are some examples - they all relate to interactions with windows. I couldn't find any examples where core JMP tasks such as table manipulations needed a wait.

Example 1: Updating a text box (or some other display box)

Performing a computationally intensive task (loop) and wanting to push information out to the user - you need to gives windows some breathing time to perform the refresh (alternatively in this example a "reshow" message could be sent to the window containing the text box)

tbEstimate << Set Text("Estimated time to completion = " || Char(estimateTime) || " seconds");

Wait(0)

Example 2: Using StatusMsg

StatusMsg was invented before we had the multiple document interface for JMP and so it is unpredictable which window is used to display the message. Using a Wait ensures you have the current windows attention

Wait(0);

strMessage = "Some message";

StatusMsg(strMessage);

Example 3: Dynamically updating content

Not strictly needed but can help reduce flicker

(here:vlb << Child)<<Delete;

Wait(0);

here:vlb << Append( content )

Where vlb is a V List Box or some other display box container

-Dave

All comments

David_Burnham

Example 1: Updating a text box (or some other display box)

tbEstimate << Set Text("Estimated time to completion = " || Char(estimateTime) || " seconds");

Wait(0)

Example 2: Using StatusMsg

Wait(0);

strMessage = "Some message";

StatusMsg(strMessage);

Example 3: Dynamically updating content

Not strictly needed but can help reduce flicker

(here:vlb << Child)<<Delete;

Wait(0);

here:vlb << Append( content )

Where vlb is a V List Box or some other display box container

-Dave

djhanson

I have seen this in the past, example from JMP8 to JMP9 migration some of my scripts did not work as JMP9 was executing too fast. As I recall I placed in some wait(0); and all was fine.

Now I have a new timing issue case, very odd but real:

script: JRN with ButtonBoxes. Each ButtonBox executes a JSL.

Case 1: Good Case - if I open up the JRN via Windows Explorer into JMP, the subsequent JSL works fine.

Case 2: Bad Case - if I open up the JRN as JMP Addin menu, it doesn't work. The log seems to show unknown display boxes (which are contained in JSL at various points). Also, if I just watch these two cases, Case 2 is executing faster than Case 1 even to my eye! And no, in this case all file references are fine, both cases use the exact same JRN/JSL's on my local PC, and even the way I tell it to open in the JMP Addin makes no differences (whether "path">$ADDIN_HOME vs "text">open).

So in my case, it seems even how JMP loads things can matter to the timing. I think in my Case 2 above, JMP is just able to load my JRN and subsequent scripts much faster, but it unfortunately affects the timing in a negative way. Anyways, my approach will be to try some wait(0); 's to see if I can slow JMP down a bit. cheers, dj

djhanson

Followup. I was fooled here about the timing. As it turns out there this odd checkbox in the Addin wizard: "Use the Here namespace for unqualified JSL variable names". Uncheck it and my problems went away. This explains why my JRN would not execute the JSL in its ButtonBox. -dj

msharp

You probably want that checkbox checked. Using the Here Namespace is just good coding and I would encourage you start all your scripts with 'Names Default to Here(1);' If you don't use the here namespace (or a namespace of your choosing) then JMP will assign everything as global variables. For testing and personal code this isn't a big deal, but if you are putting a script into an add-in I'm assuming it's going to be used for production.

Using the Global namespace will surely give issue for production scripts. Most common issue is unintentionally overriding common variables, like "dt" or "datatable". Other issues involve running two scripts or addins at the same time. For example, both may have For() loops, and since the variable "i" is commonly used for For() loops, and "j" for embedded For() loops if they both start running, you may find yourself running an infinite loop where "i" keeps being changed by the two different scripts.

Using the Here Namespace avoids these issues since each script is assigned a temporary namespace as long as the script is open or running. Thus, "i" is local to the script and you won't have to worry about accidental reassignments.

There are about a million ways to fix your button box issue while still using the Here namespace. Defining certain robust variable names as global that the button can use. Defining and using your own namespace (so you don't have to come up with a robust variable name). Redefining key variables in the button box's script so they are reassigned when the button is pushed. Using << Modal. Using Schedule(). Storing variables in a data table. ect. ect.

David_Burnham

As well as using the Here namespace e.g. Here:myVar