dterry

The refnum was coming from the code I posted previously (see below), but a string would work fine as well (probably better, I have no idea how refnum comparison works, but I would guess its not as simple as you might think). As mentioned above, passing the subpanel prevents me from using the class on RT, so I am avoiding that option, although it does simplify things a bit. Thanks! I'll mark your post as the solution as soon as I can test it out.

Very cool, maybe I'll have a chance to work with this at some point. That's fair. How would you compare the differently named static methods option to the control value set option? In my mind, the latter is less to keep track of, and "just works". While it is not the ideal solution, the only downside I see is if you change the names of the controls, which can be mitigated by using an override template. Since there is a lack of performance and stability concerns with either method, I think this may come down to personal preference. You bring up good points here, and I originally looked at just using the CEF/TBF, but I couldn't really wrap my mind around it, and I lean towards a "simpler is better" style in my code, which made 1 class more attractive than 3. That being said, I definitely understand where you are coming from, and have considered moving UI elements into their own classes before. As far as windows code "contaminating" the classes for RT, the subpanel issue is the only one that I have seen that couldn't be solved by either a conditional disable structure or an abstraction API. Ooooooo I like this idea shoneill! Let me see if I understand it: So the basic flow would be to call the "Get UI Refs" DD vi to gather the necessary identifiers, then use ACBR to call the DD UI method (wrapped in a static VI in the parent method) and pass it the chosen UI ref. The DD method then checks its own VI ref against the input ref, and calls the parent if it doesn't match. The only task left is to pass the active vi ref back to the caller for insertion into the subpanel, which can be accomplished with the single element queue we discussed previously. Am I understanding your suggestion correctly? This is why I love LAVAG, great architectural discussions!

Totally agree here, something I missed doing it so fast. Thanks! I think I am either misunderstanding yours and shoneill's recommendations, or misstating the problem. I have actually done exactly what you suggested with the single element queue passing back the refnum, but I don't think that helps here. To restate my issue: If you have a static dispatch wrapper around the DD method, there is no way to allow the user to select which implementation of the class to use; the LabVIEW will select the implementation associated with the object input. If you then use the Call Parent Method node in the child implementation to access the parent's implementation, I can't see a way to insert the parent UI implementation into the subpanel. To be fair, I have found one way to do this, by passing the subpanel reference as an input and allowing the method to insert itself. However, I am using these classes on an RT system, and including the subpanel reference in the class will cause it to fail during deployment. Therefore, I am looking for a way to do this without having the method insert itself. Am I missing something? Thanks,

Normally, this would be my go to as well, but this particular design restricts that option, see below Wrap each class' implementation in a static vi.You cannot have VIs in child/parent classes with the same name unless they are DD. Therefore, I would have to create and name each UI differently, which is not very maintainable. Wrap the DD vi in a static VI at the parent level onlyThis would mean that it would no longer be possible to call the specific implementation that I want. This option is great for the general case of calling a DD vi with an ACBR node, and I use it in several places already. This line of thinking is why I was wondering if this breaks OO design rules, although I am not well versed enough to know why. Essentially, I am looking to call a DD vi statically in special cases. Any other thoughts? I have implemented the set control value code into my framework, and it seems to be working alright (if not a little slow) so far. Thanks,

(New code attached, run "Launch UI 2.vi") Alright, let's try this again. First off, I modified the original example to obtain it's references via the Call Parent Method, thanks to the suggestion from shoneill. Each implementation contains a static reference to its own implementation of the UI, and adds it to the array. This definitely seems way less brittle/fragile, and will scale easily. Thanks shoneill! smithd, I went ahead and set it up with ACBR to show you what I am talking about. It definitely looks nicer, but since the terminals of the DD UI VI are dynamic, the VI is broken. Any thoughts on getting around this, aside from setting the control values by name? LVOOP UI (2).zip

Thanks for the replies guys! What do you have in mind as an alternative to LV? What prevents it from being a good fit? I agree that the code is fragile, hence looking for suggestions here. I did try to use the ACBR nodes, but these don't allow dynamic terminals. I'll think on the additional parent method for "Get UIs", but any ideas you have on the specifics would be helpful! As for the CEF, I drew a lot of inspiration for my current configuration editor from it, but I'm not sure how you would implement this idea with CEF. If you mean creating different UIs for each set of data, this is what I was trying to avoid, since it duplicates code/effort. I certainly hope so! I just haven't found any yet. I am aware of the Call Parent Method VI in LVOOP, but my problem with this has always been how to run it asynchronously. However, it occurs to me that instead of calling the UI through the Call Parent Method, I could put a static reference to the correct UI in each DD implementation, in order to build the array of VI refs this way. I will test this out and post an update when I have more information. Thanks, Drew

Hello LAVA, I have been working on a configuration interface lately for my framework, and have found a situation in which it seems desirable to be able to decide between a child and parent implementation of a class method at run time. The idea is that each level of a class hierarchy is responsible for some data which is to be configured at the start of operation. To avoid having to rebuild then extend the Config UI for each child, I have been trying to find a way to display each level (Parent, Child, Grandchild) UI in an "Options Dialog" style window. The user should be able to select the hierarchy level to view and configure it's data. I have attached some sample code to illustrate, but it basically entails a listbox for the different hierarchy implementations, and a subpanel to display the selected implementation. The code starts by traversing the class hierarchy to populate the listbox with any ancestors of the selected (Child) class that implement "UI.vi". Then it waits for the user to select one of these implementations before setting the class object vi Control reference, running the VI and inserting it into the subpanel. Note: It seems like it would be much easier to use the CBR/ACBR nodes to do this, but I was unable to figure out a way to call the different implementations, due to the dynamic dispatch terminals. Because this was not particularly straightforward to implement, I have a strong suspicion that it breaks OOP, is generally terrible, which is exactly why I am posting it here. Can someone give me a reason why this is a good or bad idea? LVOOP UI.zip

Djed, Thanks for taking the time to reply. I agree with what you and Chris said, and at this point, I think I'll accept that I can't know everything, and close this discussion out. Thanks! Drew

Djed, That's a good line of thinking I hadn't gone down yet. Unfortunately, it doesn't fully explain my behavior. True enough, in some cases where I experience Behavior A, the reentrant VIs are being called inside a loop, meaning they may or may not be running at the split second I click. However, in several other cases, the VIs themselves contain a loop and are running continuously. Any thoughts on how that detail may affect things? Just in case it helps, it does seem to correlate (in this, but not all cases) to DD vs static dispatch. Thanks, Drew

WOW, drjdpowell, it's not often I learn about such an amazingly useful feature, and I've been down some pretty deep rabbit holes in LV. THANK YOU! That View menu trick is going to be so helpful!! As for the show front panel message, that is how I am opening the top level endpoint (actor/whatever), but when I would open it's DD subVIs (message router, message handler, ui, auxiliary, etc.), I would get their original copy, which is where your first trick comes in so handy. The View menu trick will pretty much resolve my struggle here, but I am still curious about the behavior if anyone has any thoughts! Thanks, Drew

Hello All, Long time reader, first time poster. I have learned a lot from lavag, and really appreciate what you all do here. I am building an LVOOP architecture that sort of straddles the line between AMC and AF. One of the most frustrating things I have run across (as with most AF type architectures) is debugging shared clones. I've run into some behavior that I did not expect and wanted to see if anyone knew what was going on. First some definitions: Behavior A: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the original, "uncloned" VI, reserved for execution. Behavior B: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the active, running clone VI, which is capable of being debugged. I once thought that behavior A was how LabVIEW worked, however in developing this framework, I have found that some subVIs show behavior B. Behavior A and B seem to correlate to dynamic and static dispatch methods respectively, but I can't make sense of why. If I create a simple example without OOP (see attached), I get behavior A. Has anyone ever seen this behavior, and if so, am I missing something really obvious? Secondly, does anyone have any tricks or best practices for getting into active clones to debug? My only idea at this point is to include some sort of notifier/queue/etc to active a Front Panel Open Method. Thanks in advance! Drew T. CLA, CTA