Well ok,
If you're set on interrupting your code, one could set an error and build an
error response routine to accommodate cal. Thing is, where do you place the
error trap, at the key press? Anyway, Som'n like that.
rufus
-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Friday, July 30, 2004 3:11 PM
To: VRF
Subject: [vrf] RE: Vee multithreading
> Cheers for that input but it does not seem to solve my problem.
Opposite problem, opposite solution Everything I added I left open.
Note however that the calibration thread is not back-mutexed to the test
thread. IOW if you're in the middle of a Cal you can still click Start. Just
add another global that monitors the state of the Cal thread and check it
before allowing the Start thread to continue.
This is a common problem and there's a kernel object explicitly made for
situations of this sort called a "mutex". Unfortunately that only works with
actual multithreading and it won't help with VEE.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
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".
If you're set on interrupting your code, one could set an error and build an
error response routine to accommodate cal. Thing is, where do you place the
error trap, at the key press? Anyway, Som'n like that.
rufus
-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: Friday, July 30, 2004 3:11 PM
To: VRF
Subject: [vrf] RE: Vee multithreading
> Cheers for that input but it does not seem to solve my problem.
Opposite problem, opposite solution Everything I added I left open.
Note however that the calibration thread is not back-mutexed to the test
thread. IOW if you're in the middle of a Cal you can still click Start. Just
add another global that monitors the state of the Cal thread and check it
before allowing the Start thread to continue.
This is a common problem and there's a kernel object explicitly made for
situations of this sort called a "mutex". Unfortunately that only works with
actual multithreading and it won't help with VEE.
-SHAWN-
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
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".
Having given up on my "is program running" problem I have moved right
along to another difficulity. I have a simple DLL written in C++ and I
wish to use the function it contains from within Vee. The DLL's library
and definition file load properly in C++ and the function works
correctly. The library also appears to load corrctly in Vee and the
function is listed under the Program Explorer's Compiled Functions (with
a yellow f(x) icon). Clicking on the icon brings up the expected "what
do you want to do" box and I can generate a "call" or a "formula call".
However, when I run the program I get an error message stating "Function
is not loadable" (error 604). What have I missed?
Barrie
whoi
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
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".