Access violation with class specific VIs

[BrotherTom]

Hi

Recently I faced an issue which keeps annoying me when developing my application. I searched the web as well as the forum without success... Maybe somebody could help?

I have an OOP application with a single parent class and one child class. More classes will follow to inherit from the single parent class. Some subVIs implement dynamic dispatching. The class private data consists of multiple strict typedefs.

Now... As soon as I modify one of these typedefs and run the main VI, some subVIs don't seem to run anymore although they are implicit subVIs (see attachment). The VI in the background is the main VI whereas the 3 VIs in the front are the subVIs. The main applications runs, the subVIs don't.

When the main VI calls one of these VIs I receive a LabVIEW crash with this famous "Access violation 0xC0000005".

It is quite simple to fix this indeed. I just have to set one class connector of one of the VIs to "Required" and then back to "Dynamic dispatch" and the problem is solved, interestingly for ALL of the VIs, and not only for the modified one.

Anyone faced this behaviour too? Although the problem is easy to fix it bothers me because LabVIEW crashes everytime and anyway, typedefs exist to be edited anytime!

Thank you for any help!

Thomas

[Norbert_B]

Thomas,

do i understand correctly that you put a type-defined cluster into private data of the class?

If so, do you use "autopropagate" changes to that cluster?

Do you use dynamic calls to class(es) (read: plugin architecture)?

Norbert

EDIT: What is the LV version you use? If not 2014: can you verify with 2014 as well?

[BrotherTom]

Hi Norbert

Thanks for replying!

Yes, the class private data contains multiple typedefs, and no dynamic calls are made. All subVIs which show the problem are placed in the block diagram of the main VI.

What do you mean with "auto-propagate"? Sorry... I've never heard about this.

LabVIEW version is 2014. I already faced the problem in LV 2013 and this was the reason I updated. 🙂

Thomas

[Norbert_B]

Thomas,

do you by chance have a small example project showing this issue?

Is there a reason why you use type defined clusters instead of (sub)classes in your application?

Norbert

[BrotherTom]

Well, no, there's not a particular reason. Each child class represents a product which can be tested with the same test equipment the application is designed for. Each "product class" contains some setup parameters and some product-specific data.

I don't have a dummy project, sorry. I'd have to build one...

Do classes have problems which altering typedef structures? Is this a known behaviour?

[Norbert_B]

---

@BrotherTom wrote:

[..] Is this a known behaviour?

---

Not to my knowledge. But i find it possible, hence my questions.

But you can, for testing purposes, resolve (disconnect) all instances from the type definition. Change the present instances (a sh**load of work, i know) and see if the error persists.

If not, i recommend you to use classes instead of type defs in your class data as this is a setup LV OOP is tested against.

Norbert

[BrotherTom]

I'll see if I'm able to provide a dummy project. Thanks for your hints.