A LVOOP Inheritance Question

[cirrusio]

Hello all you LVOOP guys and girls,

I have a question that seems like it should be relatively straightforward, but it's obvious that I am not understanding what is really going on behind the scenes in LVOOP.  What I have is two classes that inherit from the same superclass.  The superclass provides some basic functionality that I want to maintain between different instances and therefore the functions can't be overridden by the children.  Now, the problem arises in my application where I want the two classes to operate in parallel - in parallel, these classes seem to be contaminating each other and producing odd results that are not ideal.  For instance, I have a function that inserts an error generated by the child into an error queue (the reference to which is maintained by the parent) which is then sent to an error handler owned by the parent.  What I am finding is that the error is then being handled by the wrong instance of the parent class!

Is this behavior to be expected?  Keep in mind that I am using dataflow programming and all access to the two classes is on the same wire where the class is initially instantiated.  If the behavior is expected, is there anyway I can get around this?

Since this might be a little incomprehensible, here are some snapshots of what I am talking about:

The above image is a snapshot of the two different child classes running in parallel which use the same parent class.

And here is the example that I gave - a simple VI for placing errors in a queue for access and handling by the child class:

Any thoughts would be appreciated.

Peace, Matt

[tst · Accepted solution]

Your description and images aren't enough, so this will only be general, but here are some relevant points:

1. How are you getting the queue ref? If you obtain it by name, then both reference will point to the same queue, so that would be my first guess for what your problem is.
2. You seem to not fully understand the OOP terminology. There's no "instance of the parent class" - in your case you probably have two instances on your diagram, each of which also inherits its behavior from the parent class (I say probably because there are any number of operations which can create more instances, such as branching a wire). To make the terminology easier, I would use "object" instead of "instance", so you have two objects.
3. To further clarify that point - in this case you seem to use "instance" to refer to an object which has a specific reference to the queue (i.e. you basically want a by-ref behavior) whereas LVOOP is inherently by-val, and there instance means that memory has been allocated for an object, but that object might be completely identical to another object.
4. I'm not sure how much LVOOP you studied, but there should be some info around (including quite a lot in the LAVA OOP forum), as well as some NI courses which might help (not having taken them, I have no idea what their level is).

If all this doesn't help, then we need more details, preferably the actual code.

[cirrusio]

Sorry about the unclear use of terminology. You will have to forgive me as it was a late night after a long day which was preceded by 5 hours of sleep.  By instance of the parent class, I was referring to the instance related to the child that had been instantiated (what I thought was apparent as demonstrated on the left hand side of the diagram but obviously was not).  But, my terminology was not entirely incorrect - in OOP, instance and object are often used interchangably (think that when you make first make an executable copy of the class, you are instantiating that class - creating an instance).  😉

I understand the by-value/by-ref thing (the upper diagram shown was intended to demonstrate that there was no wire interdependence-i.e. branching - between the two independent, parallel loops and there initialization), but was a bit befuddled by why I might be populating my queue in one loop (the lower in this instance) and dequeuing in another (the upper, in my VI diagram). My question was related to whether we expect these copies of the parent to be unique to the object that had been instantiated (as if they were reentrant) because it was unclear to me (I would expect them to be.  But, tst, you seem to have nailed it!  This is definitely a big duh.  While each object/instance calls a function defined by the parent to create the queue reference, the function uses a single, non-unique name to define the queues.

Thanks for taking the time to look over this although it was not entirely clear.  I know how frustrating these things can be.

Peace, Matt