I've submitted a sug for this...

Submitted: mrBug00041169: General: SUG: Implement a property or
variable that defines if a survey is in AutoAnswer mode:


--- In NADUG@yahoogroups.com, Bret Hodge <mailhodge@...> wrote:
>
> Thanks for your feedback Jamey.
>
> These features (IOM.Info.IsTest and IOM.Info.IsDebug) are useful
and we do use them on all of our projects. The concern here though
is we want the program to act the same way it would on the server
when in mrStudio. We want to validate ALL of our logic through
punch through on mrStudio. IF we use these commands to negate how
the survey would act in mrStudio vs. a live server then it defeats
one of the most powerful aspects of mrStudio (checking complicated
logic before pushing out to a live envirnoment).
>
> AutoAnswer trips up on complicated logic when used with custom
validation functions not to mention AutoAnswer doesn't run JS in our
templates so we must have a way to check ALL logic through punch
through in mrStudio AND have AutoAnswer be able to finish without
issues.
>
> The only way to achieve this is to edit your code before you run
AutoAnswer since IOM does not have a property we can directly access
for this mode of click through. This is not the preferred method
because it requires us to edit our script from the "final" version.
The solution we came up with essentially creates a pseudo property
which we can access. This allows us to have the same code for
AutoAnswer, individual click through in mrStudio, AND live server
environment. No alterations to the code is necessary if you code
your "problem" areas with the AutoAnswer property logic.
>
> The other solution to use AutoAnswer hints isn't very helpful for
complicated logic either as it forces the same answers every time,
which negates data checking if the same answers are checked at the
same questions (which are the questions with the difficult logic).
In addition, the AutoAnswer hints are more difficult to implement as
there is a disconnect from the routing, not to mention the hints are
removed when mrStudio rehydrates so its more difficult to identify
those hints especially when projects can have multiple programmers.
>
> Bret
>
>
>
> ----- Original Message ----
> From: jamey_corriveau <jcorriveau@...>
> To: NADUG@yahoogroups.com
> Sent: Thursday, November 16, 2006 2:00:38 PM
> Subject: [NADUG] Re: AutoAnswer in mrStudio
>
> I'm not sure if you are aware, but
IOM does know the difference
> between:
> 1) Live
> 2) Test (use IOM.Info.IsTest)
> 3) Debug (use IOM.Info.IsDebug)
>
> Although this is not directly related to AutoAnswer, it may still
> help you a bit. IOM.Info.Test is when your project is in Test
mode
> or if you put Test=1 on the URL. IOM.Info.IsDebug is true when
you
> run the survey in mrStudio, which is where AutoAnswer takes
place.
>
> IOM.Info.IsDebug is great for this type of logic because it will
> never, ever run in the live or test survey. You can, for
example,
> set specific values that let you get thru complicated parts of
the
> survey (which might trip up the autoanswer).
>
> Don't forget there are also 'metadata hints' which only get read
by
> the autoanswer facility. This was purposely implemented for the
> purpose of getting past complicated sections of a survey (during
> autoanswer). You can find more information in the DDL.
>
> Hope this helps.
>
> And thanks for the great topic,
> Jamey
>
> --- In NADUG@yahoogroups. com, "mailhodge" <mailhodge@ ..> wrote:
> >
> > We have found that while mrStudio provides a huge advantage
with
> the
> > AutoAnswer tool, it has a hard time completing in most of our
> > scripts. The main problem arises from the fact that if you
> perform
> > custom validation on a question or series of questions,
mrStudio
> is
> > not "smart" enough to answer the question properly and thus
fails
> > during its data generation.
> >
> > Some of our initial solutions caused a lot of headache to
> implement
> > and also posed the potential of launching a study into field
> > with "AutoAnswer" logic which would cause bad data collection.
> The
> > nice and simple solution would be to have a native IOM property
> that
> > would tell you if the program was running in AutoAnswer mode or
> not;
> > however, this feature is not within the IOM feature set.
> >
> > We found that by creating our own property we can achieve this
> same
> > logic:
> > dim propAutoAnswer
> > set propAutoAnswer = IOM.Properties. CreateProperty( )
> > propAutoAnswer. Name = "isAutoAnswer"
> > propAutoAnswer. Value = false
> > IOM.Properties. Add(propAutoAnsw er)
> >
> > Now you can access the property like so:
> > IOM.Properties[ "isAutoAnswer" ].Value
> >
> > Now, everywhere you have access to the IOM, you have access to
the
> > isAutoAnswer property and can adjust your logic accordingly.
> > However, one of the most common complaints we get is how long
our
> > variable names are or how "deep" into objects we have to
traverse
> to
> > get logic. To remedy this we also created a local dim variable
> > called isAutoAnswer in the main routing section. This is the
> > variable which the programmer would edit if about to run
> AutoAnswer:
> > dim isAutoAnswer
> > isAustoAnswer = false
> >
> > One of our concerns though is maintaining the same value for
both
> > the local dim variable in the routing as well as the property.
In
> > addition, we want to ensure that there is NO possibility of a
> study
> > going live with isAutoAnswer set to true. To remedy this we
place
> > the following logic:
> >
> > if (IOM.Info.IsDebug) then IOM.Properties
> > ["isAutoAnswer" ].Value = isAutoAnswer
> > isAutoAnswer = IOM.Properties[ "isAutoAnswer" ].Value
> >
> > The first line only sets the isAutoAnswer property IF in
mrStudio,
> > if you are are on the server this line never executes and as a
> > result the default value of false (set when we created the
custom
> > property) will remain. The second line ensures that the local
dim
> > variable in the routing is in sync with the IOM property. IF
the
> > programmer left the value of isAutoAnswer = true on the server,
> then
> > the IOM.Properties[ "isAutoAnswer" ] would not be set and
remain
> > false, then the isAutoAnswer value is forced to false and all
> logic
> > would run properly.
> >
> > With these two methods you can now run logic in both the main
> > routing and any function/sub which has the IOM passed to it
(this
> > includes validation functions).
> > Routing example:
> > If isAutoAnswer then q1.Validation. Function = "q1Validate"
> > q1.Ask()
> >
> > Function example
> > Function ValidateSum( Question, IOM, Attempts)
> > If IOM.Properties[ "isAutoAnswer" ].Value then
> > ValidateSum = true
> > Exit Function
> > End if
> > ...rest of validation.. .
> > End Function
> >
>
>
>
> <!-- #ygrp-mlmsg {font-size:13px;font-
family:arial,helvetica,clean,sans-serif;} #ygrp-mlmsg table {font-
size:inherit;font:100%;} #ygrp-mlmsg select, input, textarea
{font:99% arial,helvetica,clean,sans-serif;} #ygrp-mlmsg pre, code
{font:115% monospace;} #ygrp-mlmsg * {line-height:1.22em;} #ygrp-text
{ font-family:Georgia; } #ygrp-text p{ margin:0 0 1em 0; } #ygrp-
tpmsgs{ font-family:Arial; clear:both; } #ygrp-vitnav{ padding-
top:10px; font-family:Verdana; font-size:77%; margin:0; } #ygrp-
vitnav a{ padding:0 1px; } #ygrp-actbar{ clear:both; margin:25px 0;
white-space:nowrap; color:#666; text-align:right; } #ygrp-
actbar .left{ float:left; white-space:nowrap; } .bld{font-
weight:bold;} #ygrp-grft{ font-family:Verdana; font-size:77%;
padding:15px 0; } #ygrp-ft{ font-family:verdana; font-size:77%;
border-top:1px solid #666; padding:5px 0; } #ygrp-mlmsg #logo{
padding-bottom:10px; } #ygrp-vital{ background-color:#e0ecee;
margin-bottom:20px; padding:2px 0 8px 8px;
> } #ygrp-vital #vithd{ font-size:77%; font-family:Verdana; font-
weight:bold; color:#333; text-transform:uppercase; } #ygrp-vital ul{
padding:0; margin:2px 0; } #ygrp-vital ul li{ list-style-type:none;
clear:both; border:1px solid #e0ecee; } #ygrp-vital ul li .ct{ font-
weight:bold; color:#ff7900; float:right; width:2em; text-
align:right; padding-right:.5em; } #ygrp-vital ul li .cat{ font-
weight:bold; } #ygrp-vital a { text-decoration:none; } #ygrp-vital
a:hover{ text-decoration:underline; } #ygrp-sponsor #hd{
color:#999; font-size:77%; } #ygrp-sponsor #ov{ padding:6px 13px;
background-color:#e0ecee; margin-bottom:20px; } #ygrp-sponsor #ov ul
{ padding:0 0 0 8px; margin:0; } #ygrp-sponsor #ov li{ list-style-
type:square; padding:6px 0; font-size:77%; } #ygrp-sponsor #ov li a{
text-decoration:none; font-size:130%; } #ygrp-sponsor #nc {
background-color:#eee; margin-bottom:20px; padding:0 8px; } #ygrp-
sponsor .ad{ padding:8px 0; } #ygrp-sponsor .ad #hd1{ font-
family:Arial;
> font-weight:bold; color:#628c2a; font-size:100%; line-
height:122%; } #ygrp-sponsor .ad a{ text-decoration:none; } #ygrp-
sponsor .ad a:hover{ text-decoration:underline; } #ygrp-sponsor .ad p
{ margin:0; } o {font-size:0;} .MsoNormal { margin:0 0 0 0; } #ygrp-
text tt{ font-size:120%; } blockquote{margin:0 0 0 4px;} .replbq
{margin:4;} -->
>