Dear Mr. Hassell,
thank you very much for the detailed explanations that you provided.
Best regards,
Sergiy Radyakin
On 8/14/07, James Hassell <[email protected]> wrote:
> 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/
>
*
* 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/