K-node

For the VI that is going idle, why not just use the VI Invoke Node with the Front Panel:Close in its ChangeView event handler. Then for the VI that is going visible, use SubPanel Invoke Node with Remove VI followed by Insert VI in its ChangeView event handler. I would add a Clear Errors in between in case there is nothing in the subpanel. You might also add a Front Panel:Close in front of all of this in case the VI is already being displayed somewhere along with a Clear Errors in the event it is not currently visible. Your race condition you describe would not occur. However, your user could go click happy and keep changing views faster than the clients can update. It may happen that the last view desired is not the one that ends up showing simply because the last one clicked processed the event fast. I personally would not bother handling that use case. I also agree with James, that you should pass in the reference to the subpanel and not store it. My apps have lots of subpanels. Front Panels are swapped around all the time. Each user wants to see things a bit differently.

I am a bit confused so I will write it as I understand it. Your class has some private data that has in it a cluster. I think this is what you call the object control element. You added a accessor method to Read this cluster as a complete block (not the element of the cluster). I think this is your property node. And it is used by some member method vi. In this member vi, you used the Read <cluster> property node and then the Bundle By Name primitive to set the value of the desired element. At the end of this, you expected that the value supplied to Bundle By Name would be in the object's private data cluster. If that is correct, did you actually write the cluster obtained from the property node (the Read <cluster>) and changed the element value back to the object's private data? For instance using a Write <cluster> method (you would have to create such a method). Remember this is all data flow. The Read makes a copy of the data from the object's private data. If you change your copy, you need to write it back. If I am off base here, sorry, perhaps you can correct my interpretation.

I periodically do what Paul suggests; adding what I think might be a class with few dependencies. Before doing that set the 'Arrange By' of the Project's My Computer to be Custom. The Dependencies should already be 'Same as Parent'. You have a better chance at figuring out where that odd dependency came from when you 'Find callers' on a class, class data ctl or class method.

If done right, the collection class should not know anything about the classes it contains. Though not using a class, in the attached example I have included a function that takes an array of vehicles and returns a properly cast vehicle (vehicle, truck or car). It will error if you index a car and expect a truck. You could actually make the icon look like the Index Array icon. Anyway it is an example of the use of the Preserve Run-Time Class node which often confuses the new OOP user. I do agree with Paul in that once the entities are in an array they should be considered homogeneous - as in all vehicles. I should be able to wire the output of the array to any method supported by the base class. I can deal with an array of vehicles that are all trucks and require the cast. But a collection of cars and trucks and treating them all like trucks is not a good design. I understand your dilemma with those unfamiliar with OOP. I think though, you are setting up the user for unexpected runtime errors. In your real life example, what happens when I wire an AnalogInput to a write byte method? It is Friday night and I am about done with a Long Trail Limbo IPA (delicious by the way) so this is pretty much all I can add for now. -Kurt ObjectInterfaceProblem_ALT.zip

Yup, I got that. Not happy with it, though I do not have the CompSci background to say exactly why. One thing that makes me uncomfortable is that as a developer using this API, I would not expect it to error if I asked a simple question like 'what is your capacity?'. Or more importantly, why I am allowed to ask this question on an arbitrary vehicle if it is truly not a valid request. That aside, what if I have a chain of inquiries to do that are specific to a truck: capacity, # of axles, gross vehicle weight, etc. Do I create a static method that encapsulates the To More Specific node (with the call to the property method) and chain these together? Seems that it is adding unnecessary overhead on the repeat To More Specific call, error trapping, etc. As an alternate to a full collection class, even a simple function that accepts an array of vehicles (or even LVObjects), an index and a target class (constant of Truck in your example) that uses the index to access the array and passes the value to a PRTC node returning a properly 'cast' Truck if the index was a Truck. Otherwise it returns an error. The error would be a 'natural' result for this type of function because the developer could anticipate the request might not be valid. This approach encapsulates the cast in an expected location, 'cleans up' your diagram and maintains design time type safety. Just my opinion, but then that is what you were asking for. Kurt

Here are a couple ideas. Do all vehicles have a 'Capacity'? If so, you might consider having a method or property with dynamic dispatch terminals that returns Capacity. It would be defined in Vehicle.lvclass. Car and Truck (Motorcycle, Boat, etc.) would override to supply their respective capacity if they had any. By default, Vehicle.Capacity could return 0. Also, consider creating a Collection class that holds the array (or some container) of Objects. Methods like Add would allow you to build the Collection up. GetAtIndex would return the Object. Adding an LVObject terminal to GetAtIndex and wiring that into the 'target object' terminal of a Preserve Run-Time Class node will encapsulate those 'To More Specific' nodes and still give you design time type safety. Still, a the PRTC node will error at run-time if you try to make a truck into a car. My development machine is not on the network so I cannot supply an example at the moment. Let me know if that would be valuable and I can try tonight. -Kurt

In case you or others have not seen this article... Implementing the State Pattern in Actor Framework (https://decibel.ni.com/content/message/49271#49271)

reteP, Watch your post at https://decibel.ni.com/content/message/62163#62163, I will be responding there with more information tonight. -Kurt

I just want to make sure I understand this. Pre Launch Init.vi is actually called from Actor.vi which is reentrant and launched by the ACBR node in Launch Actor which is non-reentrant. However, at runtime it is operates like a non-reentrant VI since another Actor.vi/ACBR will not happen until the 'active' Pre Launch Init completes and the new Actor's Enqueuer is sent back to Launch Actor. So unless some developer calls Pre Launch Init from somewhere else in their code, albeit a bad practice, there will only be one shared clone. If that is the case, I take back my statement in Post #3.

I misunderstood the statement. Launch Actor is not reentrant, Pre-launch Init.vi is reenttrant. Phew, I thought my lvlib got whacked somehow.

> Pre-launch Init.vi is called under Launch Actor which is deliberately not reentrant. Really? Crap! Somehow mine got changed. I am sure this was discussed somewhere, but what is the best way to protect Actor Framework.lvlib and its files from getting altered? Do I write protect the files in that folder?

Non reentrant VIs called from pre launch init will cause the others to wait. Just a thought. Update: If you look ahead at posts 14 and 15 you will see that though Pre Launch Init is reentrant, it will never act like a reentrant vi during the launching of an actor. So making any Pre Launch Init supporting VIs reentrant will not improve the launch performance.

Just a note for those booking a hotel thru the NIWeek portal. There are two pages of hotels. Last I looked, the second page only has two hotels, but those may be the ones you prefer. See you all there!

Perhaps if your polymorphic VIs wrapped protected, dynamic dispatch methods that can be overridden by the sub-class. I supppose the protected method could take a variant.

jackmax, AQ last year posted this: http://forums.ni.com/t5/LabVIEW/A-more-successful-experiment-in-creating-compositable-user/td-p/1276802 Look for his post with v2.3, I think that is the latest. While it does not answer creating your tab control, it does show how to mimic the creation of multiple controls on a front panel. Controls are not really created, but rather an image of the control is drawn on the front panel. At least I think that is how it works. Kurt