GregFreeman

I agree with you on this. But, to clarify a bit further, I want to have a VI that manages the drag and drop of the listbox, items moved, copied, and deleted from the listbox etc. If an item is deleted from the listbox, it needs to delete that item from the array that holds the associated information for that item also. I'd like some methods to do these things (which I was going to put in the listbox class), but then these methods need to accept any array type that may be passed to them as an input. so they can be used across apps. But, in order to do that, any array that is passed to this method needs to be made of items that inherit from whatever type the array is on the connector pane of the method. But, I may not want my "test data" class to be coupled to the class that is on the input of these methods. Does this help, or make more sense? I can put together what I'm thinking and post it a bit later today if that would help

I'll just explain my thought process and where I'm at now and you guys can let me know if there is a better or more flexible way to do this.... I have a listbox with items, and each item will have corresponding information. For example, I may have a listbox of test step names and each test step has associated information about that particular step. So, my initial thought was have a "listbox item" class and as part of its private data it could hold a "listbox item information" object. The problem with this is, if I wanted to reuse this listbox functionality on an application which wasn't configuring test steps, but maybe was a list of users and their associated permissions (a class "user permission info"), I wouldn't be able to reuse the "listbox item" class and pass "user permission info" into its private data unless "user permissions" and "test step info" both inherited from "listbox item information". This doesn't really make sense and is too coupled because now if I want to move the test step information class or user permission information class to another project, they are tied to the listbox item information as their base class. Hopefully that makes sense up to this point. Lots of words and no picture or UML make it difficult, I know. So my next thought (and current solution) is to have a "listbox item information" class which is in the private data of the "listbox item" class. But, I'd create a class called "Test Step Listbox Item Info" which inherits from "listbox item info" and in this class's private data it would have a "test step information" object. Now, any time I want to use different item info with the listbox class I can just create a new "<name> listbox item info" class which holds <name> in its private data and everything else should take care of itself. (man, UML would help this haha, sorry if you're just as confused at the end as the beginning, I can try to reword...it's late).

Ok, I unknowingly used "abstract" classes, scratch interfaces. Thanks for the link to your IF though; I looked it over last night and that makes sense. I don't currently have a need for it, but like so many other things, it's an idea to have in my "toolbox" so some light bulb goes off the situation arises where I may benefit from the concept.

I'm not directly interested in only this, although I see why it came off that way. As I transition to using and fully understanding LVOOP, I just want to make sure I cover all of my bases, and there are certain points I understand more than others. So, some I may hammer home until I understand the best way, then move onto the next thing that I'll repeatedly ask questions about until I understand it fully . I assume it will be like learning LabVIEW; I'll just do it, ask questions, refactor it, ask more questions, refactor it then one day I'll realize I no longer have to ask questions and instead can answer them.

As I study this more and adapt it to meet my general needs, I came up with another question. You mentioned providing type safety by passing the slave loop class to the event loop, which forces developers to write methods for the messages. But it seems that this same type safety doesn't hold true for messages sent back to the "master" because the slave loop can get the queue reference directly. Would it be safer to have a "master" class as well which holds the queue ref in its private data and then pass that class to the slave loop instead? Then it would force messages sent to the master to have methods defined.

Thanks for the responses, guys. Hopefully this will never turn into the OOP version of the string vs. enum debate! I try to keep in mind this is LabVIEW, not c++ or JAVA so sometimes things will not conform perfectly to the generally accepted practices in those languages.

I'm curious if someone can speak to the benefits and drawbacks of having a case structure that takes a string from the message (as is shown in this example), versus something like the actor framework that has a Do.vi that is must override for every message. I feel the actor framework method of message handling is safer because the programmer is required to define a Do method for each message which defines how it is handled. In this example, the programmer still has the possibility of having a typo in his message name or case structure which would not be found until runtime. With the actor framework, it forces you to implement what to do when a specific message is gotten, and if this isnt' defined it is caught at compile time.

Thanks Paul. I actually was just looking at your PDF from NI week yesterday and discussing it with one of my coworkers. Admittedly, it was a bit over my head but I'm taking it in slowly. I will look at the links you have provided when I have some time. I should also make a note that I didn't make in my reply to Asbo, I noticed that with the example link he provided, the concrete class is made to be an attribute of of the interface class. Is this always the case?

Thanks! My follow up question to this is then: why have the interface there? It looks like you wouldn't lose or gain any functionality if you stripped out the interface classes, as they have the exact same methods as the top level observer class. If you just had player and spectator inherit directly from observer, you'd still have to implement these 3 methods so what do you gain by putting the interface class in between? Is it just for code readability, or is it to further define the classes that inherit from observer (just in this case they only have the same 3 methods) and then any concrete classes can extend functionality even further? I have attached the UML from the other thread for reference

I have just been reading up on topics of OOP in general and although I've used things similar to Interfaces and Abstract classes in LabVIEW, I didn't realize I was doing it. Due to differences between different text based OOP languages and LVOOP I was just wondering if I could get some of you to speak to these two concepts, whether they both really pertain to LVOOP, and possibly provide some actual examples (not just vehicle, shape, cookie cutter examples, but something I'd actually use) of when you'd define an interface vs an abstract class? I'm basically just looking for general information to help strengthen my understanding of these concepts, and most, if not all, examples out there are text based. While I can figure them out, it's much more time consuming, still leaves me with some grey area, and my brain tends to understand LabVIEW much better in the first place.

I think I currently have something similar to situation C in the *note* and maybe situation D. The load method is set to must override in my base class "config". So, I can ensure that every class that inherits from this class will have this load method, so there is no chance the parent class's load VI will be called with a child object on the wire. Is this the point you were getting at? I need to digest situation D a little more before I comment on that one in much detail. Are you stating with this situation you could have a parent method which extracts the type of the class in the config file (possibly a child class) then reads the file and casts the variant to the specific data type? I'm afraid I'm not fully understanding this situation and the need for the implementation or the benefits/draw backs as compared to Situation C.

This along with being able to capture every message posted by windows (which is what I think you are implying anyways). Why can't I get the Window Move message? Instead I have to get mouse down on title bar through the windows API, then register for mouse move within LabVIEW, then handle the mouse move event. Then, on mouse up, I have to unregister for the mouse move event. Unless, of course, someone has a better way.

Edit due to miswording: I'm rooting for you! Let me know if you get it working. Sorry to Ned if I misunderstood. I thought I would still have to poll the DLL to get the user event dll to check for Windows messages, but I guess registering for this event in a DLL would remove that polling, as the DLL would manage the capturing of the message and posting the event in the background?

I'm rooting for you! Let me know if you get it working. Sorry to Ned if I misunderstood. I thought I would still have to poll the DLL to get the user event, but I guess registering for this event in a DLL would remove that polling, as the DLL would manage the capturing of the message and posting the event in the background?

Unfortunately I'm not very comfortable, but I could still hack something together. I was hoping there was some way to make things more transparent to the programmer, so I don't have to put a polling loop in at all. Similar to callback VIs, you register and then there is nothing else you have to do, the callbacks are captured for me and I can generate user events in the callback VI to feed to my event structure. I was hoping for something similar to that or similar to a message map in MFC. This windows message happened, do this. Basically, I was trying to capture the system messages without having to add any sort of additional loops into my software to monitor the message queue, but I don't think there's an easy way to do this.

I know there is the windows message queue API that can be downloaded, and I have this working fine and am receiving messages. But unfortunately this requires polling the message queue in my application. I'd like to handle these messages as events in an event structure, and I can do that by having a polling loop to manage the message queue, which then fires a user event when the correct message is captured from windows. But, is there a way to do this any cleaner, similar to being able to register events based on callbacks?

Yup, this is pretty much what I was getting at. I think I understood correctly but used improper terminology between object and class when stating "Is it because you could have a child class on the wire, but the variant to data doesn't recognize this". I should have said, "the actual object on the wire is not recognized by variant to data, only the wire type is recognized by variant to data" In my brain it made sense; writing it out, not so much.

I can see the benefits and drawbacks of both ways, so I will just have to make a decision at some point. For now I'll leave it as-is. My follow up question is this. Why can't the compiler guarantee the classes are 100% the same? Is it because you could have a child class on the wire, but the variant to data doesn't recognize this? I'm just trying to understand what is happening in the background. In this case, I know preserve RT class is safe because this VI is must override. So, the only object that can be on this wire is an XML Config object. Therefore, I *should* be able to guarantee this will be safe.

I have some config classes Base class: Config Child classes: XML Config, INI Config, CSV config, etc In the base class I have a load and a save method which must be overriden by all child classes. To read the XML config I am using GXML which returns a variant then I use variant to data to convert to my XML Config class. But, when I wire this output to the dynamic dispatch terminal coming out of the VI, I get a broken run arrow with the error run-time type not propgated from dynamic input to dynamic output terminal. So, I fixed this by using preserve runtime class (see screenshot) So my question is as follows: 1.Is the reason I have to use preserve run time class because if I had another class inheriting from XML config (say class ThisApplicationsXmlConfig) and it didn't have this method implemented, the parent method (i.e. the pictured method) would be called and the variant to data doesn't know the runtime class on the parent wire is actually a child class, so I have to tell it explicitly? 2. Side question: Does the output class terminal have to be dynamic dispatch or will this cause unexpected results? If I change the output from being dynamic dispatch to just recommended, how does it change the output? Thanks.

I was just reading this thread today. Now I have to go actually look at the source code to digest it all.

My OOP naivety shows again, but oh well, I'll learn, albeit slowly. I have a "network connection" base class and from it I have some child classes. I want to create a public method to check if a connection is valid. It seems like this is a method that should somehow go in the base class because it will be the same for all classes (check a connection refnum whether it's tcp,udp, etc, and see if it's valid). But, I am not sure how to best accomplish getting the connection refnum which is held in the child class, into the base class. I obviously don't want some sort of public accessor to call to return the refnum to be passed to the base classes method because I don't want the connection refnum available outside the class. But, I was trying to avoid having a "is connection valid" method in every single class also, when it seems a generic method would work fine. Suggestions?

With regards to number 1, yes, that would get old quickly, creating X Controls every time you made a new class. I support your decision haha. And with regards to the "for completeness" part, the versioning built into the classes was the main reason I wanted some clarification on why objects were not used.

Why not have your configuration elements as classes themselves? Edit: I may have answered my own question (in question format because I'm not 100% sure), but is it because you need them to appear in the config dialog? The cluster allows you to populate something meaningful to the user on the FP?