fpsane.cpp

[Kameralina]

Hello Bart,

If you do not mind sharing the one file, it would be great. In case you don't want to have it posted on the web, I have created a service request for this issue.

You can e-mail support@ni.com and make sure that you put the following exact words in the subject line:
Re: (Reference#1133395) LabVIEW Internal Error

Just the one file problem will be ok, and if you can include the file with the workaround as well, and describe the steps that you took that would be appreciated!

Thank you so much for your feedback!

[AristosQueue (NI)]

> I am currently working with some classes into a shared variable.
> After I add the variable to to routine, the LabView becomes really
> slow and crashes finally with the mentioned error.

Classes are incompatibile with the shared variable. Do not use them together. You already cannot choose a class as the type of your shared variable -- there's a reason for that.  Our test cases never considered that you might hide a class in a variant. We'll have to investigate detecting that and returning an error. To the best of my understanding, this is an architecture problem that is not solvable given the requirements of shared variables. You should not expect that shared variable support for classes will be added in any future LV version.

Instead of shared variables, please consider using functional globals. If you're trying to work across a network, then use VI Server application refnums to open a remote reference to the functional global.

I know that shared variables are touted all over as the greatest tool ever for sharing data. I don't share this opinion at all, and one of the reasons that I don't is because of the inability of shared variables to support classes. In addition to that, shared variables break dataflow and create race conditions. They are just as bad as global VIs -- worse if you consider that they are wide open to an entire network and not just one machine's worth of VIs.



Message Edited by Aristos Queue on 04-02-2008 02:00 PM