fatal crash datatype.cpp

[LuI]

Hi,
I have sent this to NI Germany, but in case someone of you can help faster:
My test app with TS3 and LV7 crashes with data type error when trying to return to TS after successfully finishing a call to LV. The error log is:
D:\lvworm\src\lvsource\datatype.cpp(763) : DAbort: datasize unknown type
$Id: //labview/branches/Wormhole/dev/lvsource/datatype.cpp#236 $
(weired names, are'nt they?)
The vi in question does function properly when operated alone. It also finishes without any problem when single-stepped from TS. No problems, no error messages. When hitting the button it takes about one second and the crash is there.
BTW, TS reports an error -18001: An error occurred accessing the LabVIEW ActiveX automation server.

A
ny clues?
TIA and
Greetings from Germany!
--
Uwe

[LuI]

ADDENDUM - NOT AN ANSWER!

I did some further research. This carsh is probably caused by rather complicated data returned from LV to TS; which is an array (typedef) of cluster (typedef) of
enum (typedef),
Cluster (typedef of 4 doubles & 1 boolean,
VISA handle,
String

Initially I had left its size 'open' in TS -> crash
Afterwards I tried a fixed sized definition in TS with sufficient room for LVs data -> Crash
Finally I removed that data completely (just to test it) -> No crash!
So what?

[Ben]

No answers,
No clues,

Gotta idea (maybe bad) here goes.

If you go to SearchVIEW

http://www.searchview.net/

and search for typedef, one of the hits is a message from Michael Aivaliotis.

http://messages.info-labview.org/2003/07/08/18.html

There is an un-documented ini setting in LV7 that can be tried. This setting is
"BldApp.RemovePolyVIsandTypedefs=False"

This shutsdown a new feature in LV7 that does not seem to handle typedefs well.

Ben

[Greg_McKaskle2]

> I did some further research. This carsh is probably caused by rather
> complicated data returned from LV to TS; which is an array (typedef)
> of cluster (typedef) of
> enum (typedef),
> Cluster (typedef of 4 doubles & 1 boolean,
> VISA handle,
> String
>

Please file an official bug report and attach any files that help to
reproduce the problem. TS stores the information internally in ActiveX
types, and apparently there is something it doesn't expect and is
failing on. If you want to look for a workaround, you might try to
convert to a type that doesn't contain typedefs. Once the bug is fixed,
you can return to the typedefed code to make it more maintainable, but
this allow you to continue developing your application while the bug i
s
being fixed.

Greg McKaskle

[LuI]

Greg,

I have already replied to you personally. Just a short note about your successfull hint. You know for sure, but I had to try...
The problem is to solve on the LV side - had to disconnect from the type defs there. TS also supports nested type defs, but rebuilding the expected data types in TS without intermediate type defs did not help. And was _so_ sure it was a TS problem...
So if anyone has a similar problem, just make a backup copy of your VI _with_ typedefs, than disconnect from those typedefs and resave.
Just my � 0.02!
Greetings from Germany!