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

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

From   "Sergiy R." <>
Subject   Re: st: Stata 10 behavior different from Stata 9 behavior for dialog controls
Date   Wed, 15 Aug 2007 10:22:40 -0400

Dear Mr. Hassell,

thank you very much for the detailed explanations that you provided.

Best regards,
   Sergiy Radyakin

On 8/14/07, James Hassell <> wrote:
> Sergiy R. <> 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:
> *
> *
> *
*   For searches and help try:

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