{VRF}
I am having problems trying to run Veetest using Reflections X.
I am using a HP Kayak XU pc. the host is a HP uxix workstation.
* errors while trying to run veetest using reflections x-term
Internal error: Segmentation violation (signal = 11)
** Recursive warning:
_IPFiler (0x53940c): Error occurred during load of device UserObject
-- today --
*** Now it starts to run but aborts giving error code -979
(I am able to run this veetest program accross unix stations)
(I am able to use Reflections X to (remotely) run other programs
like XV)
-- {VRF}
Rick Powell HPL SSTL SSAD
rpowell@hpl.hp.com
I am having problems trying to run Veetest using Reflections X.
I am using a HP Kayak XU pc. the host is a HP uxix workstation.
* errors while trying to run veetest using reflections x-term
Internal error: Segmentation violation (signal = 11)
** Recursive warning:
_IPFiler (0x53940c): Error occurred during load of device UserObject
-- today --
*** Now it starts to run but aborts giving error code -979
(I am able to run this veetest program accross unix stations)
(I am able to use Reflections X to (remotely) run other programs
like XV)
-- {VRF}
Rick Powell HPL SSTL SSAD
rpowell@hpl.hp.com
> I have a test sequence I'm trying to run, and having some trouble.
> It looks like this:
>
> START---FOR COUNT (4)---CALL USERFUNCTION---DIALOG BOX(choice to accept or
> not)
> if accept then it should do next test.
> if not then it should re-do the previous test and somehow 'pick up where it
> left off'
> each iteration performs a different test as defined in the UserFunction,
> the count # (0,1,2,3) is used to determine which test to perform)
>
> If anyone has any ideas, thanks in advance...
>
> Paul
>
Sir:
Sounds a little like this:
[15.3] ERROR HANDLING
* One difficult concept to deal with in VEE is error handling -- that is, how
to perform an action and either repeat the action or continue after an error
occurs.
A simple way to show how to handle this is with a dialog box to represent an
action that can have different outcomes, as the following program (check
xerrdemo.vee for the source) shows:
+-------+
| Until |
| Break +------------------------+
+---+---+ |
| +---+---+
| | Beep |
| +---+---+
| |
| +--------------------+--------------------+
| | Message Box |
| +--------------------------------+--------+
| | Message [ I/O Error ] | Abort +-------------+
| | Symbol [(!)] [ Exclamation ] | Retry +--+ |
| | Buttons [ Abort Retry Ignore ] | Ignore | | |
| | Default [ Abort ] | | | |
| +--------------------+-----------+--------+ | |
| | | |
| +---+---+ +---+---+ +---+---+
+-------------+ | Break | | Next | | Stop |
| +-------+ +-------+ +-------+
|
+------------------+-----------------+
| Message Box |
+-------------------------------+----+
| Message [ ALL DONE! ] | |
| Symbol [(i)] [ Information ] | OK |
| Buttons [ OK ] | |
| Default [ OK ] | |
+-------------------------------+----+
This program pops up a Message Box to ask if you want to "Abort Retry
Ignore"; if you "Abort", a Stop object is executed to stop the program; if
you "Retry", you get a "Next" loop to try again; if you "Ignore", you get a
"Break" that turns off the Until Break that then sequences down to the
Message box that tells you the program is over.
Note how the element(s) to be executed sequentially after the "I/O" loop are
connected to the sequence-out pin of the Until Break -- they are *not*
connected to any of the loop elements. Note also that you could connect the
Break object to the "Ignore" pin instead of the sequence-out pin and it would
work all the same.