> Having this problem at the moment.
"Abnormal Program Termination" is the usual notice presented to users when a
Windows application has generated an exception that the app didn't catch.
The next step is problem identification - exactly what is it that's causing
the exception that VEE isn't catching, or what is more likely, the ActiveX
control isn't catching. VEE usually does a very good job of catching it's
own exceptions. Since an in-process ActiveX control becomes owned by the
client that uses it, anything it does wrong is reported as something done
wrong by the client application - VEE.
Common things to look for are buffer sizes and data sizes. Make sure buffers
are large enough to contain the data that's going into them. Look carefully
at the size specification parameters of any GetBuffer calls you're using: do
they specify number of data objects or number of bytes? Beware of implicit
type-coercions. Make sure ancillary objects are initialized before use (I'm
not familiar with NI ActiveX, but this shouldn't really be an issue).
-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@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
"Abnormal Program Termination" is the usual notice presented to users when a
Windows application has generated an exception that the app didn't catch.
The next step is problem identification - exactly what is it that's causing
the exception that VEE isn't catching, or what is more likely, the ActiveX
control isn't catching. VEE usually does a very good job of catching it's
own exceptions. Since an in-process ActiveX control becomes owned by the
client that uses it, anything it does wrong is reported as something done
wrong by the client application - VEE.
Common things to look for are buffer sizes and data sizes. Make sure buffers
are large enough to contain the data that's going into them. Look carefully
at the size specification parameters of any GetBuffer calls you're using: do
they specify number of data objects or number of bytes? Beware of implicit
type-coercions. Make sure ancillary objects are initialized before use (I'm
not familiar with NI ActiveX, but this shouldn't really be an issue).
-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@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Would appreciate a response on if it's fixable, or will an upgrade fix this
problem. It does not appear to be a memory leak.
I am using NI activeX for vision and motion, and multithreading. I am also
extensively using the 'formula' control input in the formula box, to allow
readable text files to manipulate he core program.
If anyone has experience with this problem, which aborts the program, I
would like to hear from you.
Regards,
---
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@it.lists.it.agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".