[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

From |
James Hassell <[email protected]> |

To |
[email protected] |

Subject |
Re: st: Stata 10 behavior different from Stata 9 behavior for dialog controls |

Date |
Tue, 14 Aug 2007 16:14:10 -0500 |

Sergiy R. <[email protected]> wrote: > While testing compatibility of a program written in Stata 9 with Stata > 10 the following issue was uncovered: dialog controls (EDITs) are not > updated (refreshed, redrawn) while Stata is busy. The following > example code illustrates the problem: Sergiy is using the advanced -stata hidden- command from his dialog, and in Stata 10 some loopholes were plugged in -stata hidden- that could lead to indeterminate results. We viewed this as a bug fix, so the old behavior was not retained, even under version control. The short answer for Sergiy is to use stata hidden queue ... instead of stata hidden ... Unfortunately, there is no way to code a single dialog box so that Sergiy can get the old behavior under both Stata 9 and Stata 10. For that reason, we will make the old behavior work under version control in Stata 10. That will happen in the next executable update. Here is a longer explanation for those interested in the details. Sergiy's problem occurred when running Stata commands from his dialog. There are two ways to do this. The first uses the -stata- command from the dialog box. This is the normal/default way commands are submitted and the behavior is just as if you had typed the command in the Command window. This is done by placing the command in a queue to be consumed when Stata is idle or finished with the previous command. This method allows dialog boxes to remain responsive and have the ability to submit commands at any time, even if Stata is busy working on a problem. The second method, and the one that Sergiy is using, is the -stata hidden- command, which submits a command without showing it in the Review window. Under Stata 9, -stata hidden- also never queued the command, but submitted it directly into the command buffer to be executed immediately. The disadvantage to this method is that Stata must be idle to accept the command. What's more, if the dialog launches other immediate commands before the first is complete, the outcome can become indeterminate. In Stata 10 the -stata hidden- dialog command was extended by giving it two more optional arguments that are mutually exclusive; -immediate- and -queue-. -stata hidden queue- submits commands by queuing them the same way commands are queued with the -stata- dialog command, except with -stata hidden queue- the command is not echoed to the Results window. -stata hidden immediate- is a synonym for -stata hidden-. The behavior of -stata hidden- is the same as it was in Stata 9 with one exception. In Stata 10, we do not allow dialog polling to occur during execution of ado code called by -stata hidden- or -stata hidden immediate-. This prevents unpredictable results. It is this new safety measure that Sergiy has noticed. Because polling no longer occurs with -stata hidden- Sergiy's dialog box does not update as the ado program changes its values. As noted above we will reinstate the old behavior under version control, but if Sergiy is coding for Stata 10 he should just use -stata hidden queue-. Sergiy has asked several other questions off list. Sergiy I will reply to those questions privately. -- James Hassell StataCorp LP * * For searches and help try: * http://www.stata.com/support/faqs/res/findit.html * http://www.stata.com/support/statalist/faq * http://www.ats.ucla.edu/stat/stata/

**Follow-Ups**:

- Prev by Date:
**Re: st: Small Stata for teaching** - Next by Date:
**Re: st: Small Stata for teaching** - Previous by thread:
**st: Stata 10 behavior different from Stata 9 behavior for dialog controls** - Next by thread:
**Re: st: Stata 10 behavior different from Stata 9 behavior for dialog controls** - Index(es):

© Copyright 1996–2024 StataCorp LLC | Terms of use | Privacy | Contact us | What's new | Site index |