Leaderboard

Many free online repositories require you to grant the host varying degrees of license to your code. Be sure read the fine print.

All IP. If I own a piece of metal and cut it into a shape that [you believe] 'belongs' to you, I've legally 'stolen' something from you. I think this is absurd.

You can lead a horse to water... (Why would they be too intimidated to read the forum?) It's okay in that there won't be any naming conflicts with LapDog. My personal opinion is the class name should describe what the class is. Typically if I have a plural class name it's because the class is a collection of items. "Messages," to my way of thinking, is a collection class that holds multiple messages. Additionally, your Messages class is just one particular kind of message--a command message. There may be other messages that are not command messages in your application. My preference would be to name the class "CommandMessage." [Edit - I rename classes and methods a lot as the code evolves--it helps keep the code readable.] Nope, at least not the way I think you're thinking about doing it. Since the DequeueMessage method output terminal is a (LapDog) Message class, you'll need to downcast to your CommandMessage class in order to wire it to the Do method. The Message class doesn't have a Do method, so trying to connect CommandMessage.Do will give you a compile error. Downcasting (and upcasting, to a lesser extent) tends to trip people up when learning LVOOP. I know I struggled with it a bit. The key for me was realizing we are downcasting the wire type, not the runtime object. In LV when you create an object, that object will always and forever be an object of that class. It will never be an object of its parent class or child classes. Labview's on-the-fly compiling feature tends to blur the line between edit-time and run-time. LVOOP is a lot easier to understand when you conciously distinguish between the two ideas. They are essentially the same thing. Technically, "Dynamic Dispatching" is what happens during program execution when the LV runtime engine chooses whether to execute the parent vi or child vi. "Overriding" is a more general term that usually means, "create a method in a child class with the same name and conpane as a method in the parent class." It's something the developer does, not the runtime engine. They both refer to using the inheritance feature of OOP. [Edit - I was thinking about this a bit more and decided that statement isn't accurate. "Override" is context dependent... "You should override the CommandMessage.Do method in each CommandMessage child class." "During execution the child class' Do method overrides the parent method on the block diagram." Both are legitimate uses of the word, even though one refers to developer activity and the other refers to runtime activity.]

Close. DequeueMessage is a method, not an object, of the Message class. Correct. That gives you a compile error (broken run arrow) because there's no way for the compiler to guarantee the object on the wire during execution will be a LaunchView object. That's what I do when I'm casing out based on message name. I wouldn't say there's a "more correct" way of doing it, but there are "different" ways of doing it, from wrapping the DequeueMessage and downcast in a sub vi to subclassing the MessageQueue class. That's the command pattern and it's easy to implement in LapDog. 1. Create a class called "Command" and make it a child of the Message class. 2. Add a single dynamic dispatch method named "Do." 3. Change your messages to inherit from Command. 4. Add a Do method to each message with the appropriate execution code. You'll still need use the To More Specific Class assertion to downcast the Message wire to a Command wire before connecting to the Command.Do method. If that really bothers you there are various things you can do to hide the downcast from users, from wrapping the DequeueMessage method and downcast in a sub vi to creating a new CommandMessageQueue class.