> In relation to this point never
> use junctions to control program
> flow unless there is absolutely
> no other way to accomplish the task.
I'd go so far as to say never *ever* do this. If you need to, you need to rethink the algorithm first. There are stupid C tricks, and then there are stupid VEE tricks. IMO this is one of 'em! Feel free to disagree but I probably won't change my opinion :P
> Always to code to limit error pin
> use as much as possible.
Another excellent point. In other languages (including VEE's mother language), throwing and catching errors is The Way, but not VEE. I found that on a fairly large program that used errors as a natural course of logic, after several hundred thousand pings VEE lost it's cookies, reset all variables & started over from scratch! The customer was not amused
And no, I don't think it's ever been fixed. The opinion as of a few (several?) years ago was that it can't be fixed without breaking other things. IIRC it had to do with HP's STL implementation of red-black trees, or some variant library analogous to the STL. Can't figure why a red-black tree would be involved though (maybe has to do with stack tracing?).
-SHAWN-
> use junctions to control program
> flow unless there is absolutely
> no other way to accomplish the task.
I'd go so far as to say never *ever* do this. If you need to, you need to rethink the algorithm first. There are stupid C tricks, and then there are stupid VEE tricks. IMO this is one of 'em! Feel free to disagree but I probably won't change my opinion :P
> Always to code to limit error pin
> use as much as possible.
Another excellent point. In other languages (including VEE's mother language), throwing and catching errors is The Way, but not VEE. I found that on a fairly large program that used errors as a natural course of logic, after several hundred thousand pings VEE lost it's cookies, reset all variables & started over from scratch! The customer was not amused
And no, I don't think it's ever been fixed. The opinion as of a few (several?) years ago was that it can't be fixed without breaking other things. IIRC it had to do with HP's STL implementation of red-black trees, or some variant library analogous to the STL. Can't figure why a red-black tree would be involved though (maybe has to do with stack tracing?).
-SHAWN-
I’ve got a dilemma. I wrote a very simple program to communicate with an optical polarization controller. While I was at lunch today, my boss copied it to a different computer. When he tried to run it, VEE threw an error that it couldn’t open the GPIB interface. When I got back from lunch, he had sent me this long e-mail about how he’s losing confidence in VEE and we need a robust platform in the lab. In this particular case, Windows had failed to configure the plug and play GPIB interface (NI USB-GPIB HS). Of course I explained that if the equipment is not connected to the computer, no language in the world can talk to it, VEE simply pointed out that there was no GPIB interface.
The preface to this whole incident is: I have a much more complex test program that had worked for months on end with no problems, and then all of a sudden it stopped working with no changes to the test setup, the PC or the software. While troubleshooting this problem, I saw that the data and execution flow of the program was doing things I didn’t expect. Perhaps this is just a lack of true understanding of VEE program flow on my part, but I’ve been writing test code in VEE for over 13 years and I’d never seen this. In order to get the program running again, I had to revert back to a programming style I haven’t used since I was a rank amateur. I started using loads of variables instead of passing data through terminals. I know, it’s not efficient or elegant, but it’s working. My questions are: has anyone else run into problems like this? And has VEE program flow changed as operating systems and VEE have evolved?
Thanks in advance,
Doug
Douglas B. Rudrow
Systems Development Lab Technologist
Aurora Networks
2803 Mission College Blvd.
Santa Clara, California, 95054
U.S.A.
(408) 235-7000 Main
(408) 235 7084 Direct
HYPERLINK "mailto:rvilla@aurora.com"drudrow@aurora.com
---
You are currently subscribed to vrf as: ming_meng@agilent.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "http://www.vrfarchive.com/vrf_archive".
Search the Agilent vrf archive at "http://vee.engineering.agilent.com".