lv oop brittle code and deployment errors

[Timmar]

Greetings all,

I am developing a large application and I have embraced the power and flexability of LV OOP,

My application is complex with multi-inherited objects (as many as 10 Deep), with some objects including other objects.

It also access some objects by reference.

Architecualy it is a marvel, and has made my application highly readable and highly efficient.

Unfortunately it isn't playing as nice as I would like it to.

Case #1 - Cross References

I get a circular Error if two objects contain refererences to eachother.

Not only have the masters at labview decided not to include the "Friend" and "multiple inheritance" functionality, they have only allowed single direction pseudo-friendships (by Ref).

This broke my first achitecture

Case #2 - Multi - polymorphism.

I haven't been able to isolate this one fully but here is what I have found.

I have a group of 4 Dynamic vi's - [Name Instance, Add Log Queue, Create, Read Config] that are in my base class and called in some form or other by all of my objects.

To simplify my code I put the ancestor version of them in another Dynamic .VI and called the single VI from all of my objects.

Conceptualy the VI's would need "Down" (to generic) convert to the ancestor class and then "up" convert for the relevent [Create, Read Config] vi's.

This worked for a while bout found at some stage that it got a bit confused when I layered this a few times and/or used object references.

Like I said I didn't isolate the problem, merely abandoned the practice.

Case #3 - Unhelpful error messages - "One of the members of this class is broken".

During the development process it is common to break the odd vi or 2.

Traditianal LV programming uses what I call "Broken Arrow Decent" - keep clicking on errors and arrows until you find the breakage then fix it.

In classes a VI will show as broken if one of dynamic members of any contained .vi are broken.

For example if my "create" function in my Log.lvclass is broken, my serial.lvclass (which does not have Log as an ancestor but shares the Base ancestor) will also break identifying serial.lvclass\create.vi as having a broken member   This is not very helpful, I would prefer it jumped to the broken meber straight away.

Case #3 - Deployment

I have White arrows all around my VI's but at time of deployment I get a family of error messages.

Attached is the first.

There is no useful information whatsoever in this dialog.

I can make it go away by stripping my application down to bare bones but I an still trying to pinpoint the problem.

Does anyone have any insight as to a potential cause for this?

After creating this message for this post, Labview crashed... Again....

Case #4 - Crash

It appeasrs that when I move a class, change it's Inheritance or change a data member that is an object, I am statisticaly likely to experiance al Labview 10.0.1 unexpected error crash.

My solution is to save my work before and after the operation,

It seems to reduce the incidences of creash, as well as the damage caused by it.

(In some cases I have had all of my classes replaced with the dreaded Exclamation Triangle Symbol, requiring a complete project re-build.

Any commments, Hints, Do's and Don'ts for Class/object usage will be much appreciated.

Kind regards,

iTm

[Timmar]

Late Breaking News

Case #3 Labview Appears to be selectively Fussy about Broken VI's in classes.

Ensuring that all VI's in a class are executable appears to fix the problem.

[Timmar]

More News,

Installed LV 11 which seems to be a little more clever in the way it handles Object parsing and identifying errors.

It was clever enough to find the attached error. The to more generic class is only valid to the object member, not the data member.

[Timmar]

More imformation which will hopefully help others in the future:

Another Bug I Found (that the compile didn't inform me about)

In this Boo Boo, I called a dynamic VI from a static one.  In the case of my software, a decendant methos call would be snuffed out by the static terminals.

Sill, it would ne nice for the compiler to tell me about this.

[tst]

---

@Timmar wrote:

In this Boo Boo, I called a dynamic VI from a static one.  In the case of my software, a decendant methos call would be snuffed out by the static terminals.

---

I haven't read your posts thoroughly, but if you are saying that calling a dynamic dispatch VI inside a static dispatch VI is meaningless, then that is incorrect - the DD VI will still execute correctly for any child class of Application that you wire into the static VI. The decision which "write app data" VI to run is made purely at run-time based on the value in the wire.

[Timmar]

tst,

I do not fully understand the approved functionality of this, legal or otherwise,

Conceptialy it would make sense to prevent dynamic calls from a static method, especialy for a decendant. An ancestor could easily be accounted for.

I find in my application that if I call a dynamic child from a static function, i get a deployment error and need to exit and re-load my project to get it to recover normal functionality.

No useful debug information is provided and removing this Static-dynamic avoids the problem,.

There are merely my findings in my application.

In my opinion, it should either not throw an error, or tell me what I have done wrong.

iTm

[tst]

I never tried deploying LVOOP code to an RT target and (like I said) I haven't read your other posts. I was just commenting on that point - calling a DD VI in a static VI is something which in principle (and in practice, from my experience) should work. If it causes problem when deploying, then I'm assuming the issue is there.

[Timmar]

I tell it how I see it.

I am just hoping my experience can help others,

I have lost the last 4 Days chasing these 3 error modes.

Sure it's my buggy code, but I would like my $2,000 per Year compiler to tell me where and why it is a problem.