AnsweredAssumed Answered

VRf-VEE_Bug

Question asked by VRFuser on Jul 13, 1996
from: Greg Goebel / HP-MXD
      gvg@lvld.hp.com / 970-679-3030 / FAX 970-679-5971
to:   VRf
date: Sunday, 14 July 1996 1118 MDT

An interesting bug ... might as well share this one on the VRf.

[%%] gvg



[VEE] Obscure VEE PreRun Bug

* A customer gave us a program that exhibited peculiar behavior ... it
consisted of four Call Function boxes as follows:

   +---------------+
   | Call Function |
   +---------------+
   | setheader()   |
   +-------+-------+
           |
   +-------+-------+
   | Call Function |
   +---------------+
   | setdata()     |
   +-------+-------+
           |
   +-------+-------+
   | Call Function |
   +---------------+
   | setdata()     |
   +-------+-------+
           |     
   +-------+-------+
   | Call Function |
   +---------------+
   | setheader()   |
   +---------------+
                 
The only thing the functions "setheader()" and "setdata()" contained were
To File objects, with the flag "Clear File At Prerun & Open" set ... the
"setheader()" function stored the string "Header", while the "setdata()"
function stored the string "Data String".

When this program is run, it produces the output file:

   Header
   Data String
   Data String
   Header

Now the bug shows up if you add a Start button:

       +-------+
       | Start |
       +---+---+
           |
   +-------+-------+
   | Call Function |
   +---------------+
   | setheader()   |
   +-------+-------+
           |
          ...

Run this and the file contains:

   Data String
   Data String
   Header

The initial header is missing.

* On talking with the lab, they indicate that this is a known problem, due
to the fact that when a Start button is used in a program, prerun is deferred
until an object is executed ... this means that "setheader()" is executed
and prerun (clearing the file) and then "setdata()" is executed and prerun
(clearing the file) -- the following executions of "setdata()" and
"setheader()" are OK since they have now been prerun.

The lab guy clearly thinks this is a bug that should be fixed in 4.0 and I am
putting it on the defect tracking system as a high-priority bug.  In the
interim, there are two possible workarounds:

% Execute the file userfunctions as part of an initialization step and
   then rewind the file to really write the data.

% Don't use Start buttons.

This last is a little more practical than it sounds.  If you want to
implement multiple programs, you could do it like this:

   +-------+
   | Until |
   | Break +----+
   +-------+    |
                +-----+
                |     |
                |  +--+--+
                |  | OK  +---+
                |  +-----+   |
                |            |
                |      +-----+-----+
                |      | Program 1 |
                |      +-----+-----+
                |            |
                |        +---+---+
                |        | Next  |
                |        +-------+
                |
                +-----+
                |     |
                |  +--+--+
                |  | OK  +---+
                |  +-----+   |
                |            |
                |      +-----+-----+
                |      | Program 2 |
                |      +-----+-----+
                |            |
                |        +---+---+
               ...       | Next  |
                         +-------+

Note that you can get into trouble with this, however, if one branch of this
system is operating at a continuous high rate.

[<>] gvg / 14 jul 96

Outcomes