Typically, if adding timing determines if something works or not indicates a race condition in the code. "Fixing" it with a delay may mask the problem until next time you upgrade your LabVIEW version or computer. This is not a recommended solution. Still, I don't see any potential race condition.
I cannot reproduce your error, but a delay is always recommended, else this loop spins millions of times per second, consuming all CPU.
In addition to adding a small delay, here are a few more tips..
- On the left, you have two property nodes for the same control. Use one property node with two entries instead. Wire the "error out" to the border of the while loop to ensure that the while loop does not start until the initialization has completed. Right now you have no data dependency and it is equally possible that the loop starts first. Here it probably has no ill effects, but it is good practice to ensure proper sequencing.
- You do two comparisons linked by AND ("string starts with L" AND "string is not empty"). You can safely remove the "not equal empty" because if the first character is L, the string cannot be empty anyway. 😉
- "Update while typing" is a static property. Once you set it it stays that way. It is sufficient to change it once and not every time the dialog box appears.
- The inner case structure serves no purpose because the FALSE case can never happen. Delete the inner case structure.
- It does not matter in which order you clear the string and set the key focus. You can safely delete the sequence structure. All you need to do in the big TRUE case is probably the following. Reusing the dialog box output automatically ensures that the property write occurs after the dialog has been pressed.

Message Edited by altenbach on 02-13-2007 03:25 PM