Program Testing and Persistent Properties

[Bob Warren]

I don't know whether Ken Ray posted his MARVELLOUS answer to the List, but
in case not, here it is! QED. A ray of light has entered my brain! Well
done, Ray.

There is one remaining question for those of you with experience in both VB
and RunRev. Do you think it would be a good idea to make the "persisting
properties" OPTIONAL as suggested by the penultimate "dream" picture of my
article at http://www.howsoft.com/runrev/article.htm  ?

Many thanks also to all others who have participated in this thread so far.

''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
KEN RAY'S ANSWER:

> OK. Here's the basic situation, Bob... and just so that we're on the same
> playing field, you should know that I've used VB since VB 3 (although for
> "religious" reasons, I haven't gone to VB.NET yet ;-).
>
> The fact is that a stack *can* contain its own data that has been entered
by
> the user at runtime. This is unlike VB in that forms *never* contain their
> own data from user input; it is always added as static text values or as
> data read from an external source (text file, database, etc.).  In a
sense,
> think of Rev stacks like VB forms except that what can be done by VB in
> design time can be done by Rev in *both* design time AND runtime.
>
> So if you make a text object in VB and set its Text property to a value
> (like "this is a test"). You see it in design time. When you run the form,
> you see it at Runtime as well. However if you change it during runtime and
> then stop running to return to the IDE, it returns to what it was
> preprogrammed for during design time ("this is a test").
>
> One issue here is that Rev doesn't have separate design and runtime
> environments - they are one and the same. So that means that if you change
> data while in pointer mode by adding info via the Properties palette, this
> is the same as if you had the browse tool and clicked in the field itself
> and entered your data. Once you save the stack, it is saved with the text
> you put into it. If you want it saved without data, you need to either
> explicitly clear the data, OR you need to make the decision to *not save
the
> data with the stack*.
>
> And this is not so foreign - if you want to populate Text objects in VB at
> runtime, the data has to come from *somewhere* (INI file, XML file,
> database, etc.). The same is true with Rev. If you make the decision to
keep
> the data outside the stack and read it in at runtime, the stacks
themselves
> can be designed as either "cantModify", or you can just make sure you
never
> execute the "save" command through your scripts or through the Rev IDE.
>
> So one of the answers to question #1 above is "you don't necessarily want
> to". However there *are* times when you might want to keep the data in the
> stack (more below), so another answer is "because it keeps all the data in
> one file and makes it easier to work with the data".
>
> For example, suppose you had a simple Address stack. Fields that have been
> put into a group with backgroundbehavior turned on will show up as being
> empty whenever a new card is created in that stack. So for example,
suppose
> you made fields for name, address, etc. with no text in them, grouped them
> and set the background behavior to true. You then use the browse tool to
> enter data in the fields. Now when you create a new card (either by script
> or via the menu item in the IDE), you go to the next card automatically,
and
> the fields are empty.
>
> Note that I said they are *empty* and not that they are *emptied*, they
are
> naturally empty since Rev makes a distinction between the field object and
> the text it contains. For fields that are not in a background group, the
> text and the field object both reside on the card. For fields that *are*
in
> the background group, the text stays on the card, and the fields stay
empty
> in the background group. So when you create a new card, the background
> fields display in their *natural* state - empty and waiting for someone to
> put text into them.
>
> So in *this* kind of instance, you might want to keep the data in the
stack
> and save the stack to disk to keep the data saved.
>
> Rev gives you the choice - you can save data with the stack or not,
> depending on what you are developing and what best adapts to the situation
> at hand.
>
> HTH,
>
> Ken Ray
> Sons of Thunder Software
> Web site: http://www.sonsothunder.com/
> Email: kray at sonsothunder.com
>
>
>
>