SteveChandler

I'd definitely kudo that.. Add to the idea that the internal connection of the case-selector returns the specific-child class wire, so we don't have to do the cast anymore and we're complete.

Done

By creating your own custom messages that derive from Message.lvclass, you have much more control over the both the message name and the message data. The message object is responsible for ensuring the message name and data match up correctly instead of the message sender. I typically create a 'Create MyMessage.vi' for each of my custom messages that accepts the necessary data types and does not have an input for message name.

LVOOP is new ground for me but I am starting to understand it much better thanks to these forums. So the only thing you need the message name for is so that you can wire it into a case selector right?

This has me thinking of an idea for the idea exchange. What if you could wire the object right into the case selector? It would behave like a typedef with the ability to add a case for every value (child) and break if there is no default and you don't have a case for every value.

Would anyone out there kudo an idea like that?

For those of you who have had issues with PPLs, can you give me more details or reference some CARs so I can see if the bugs will affect me?

I am creating an application that uses packed project libraries for plugins. The only "issue" I ran into involved using classes. See this thread. It is causing me to consider either not using classes in my plugins unless they are used only in that plugin or to stick with using source distributions. Using "replace library with packed library" bit me since it is one way. Is there a plan to have "replace packed library with library" functionality?

I can't answer your question other than to say the desktop execution trace toolkit would have helped. I use it all the time to make sure everything is running as expected, references are closed, etc.

LapDog Message Library v1.2.0 has been released and is available on SourceForge. It packages several classes designed to simplify general purpose messaging for object-oriented programmers. Highlights include:

1. Familiar methods! If you've used a native queue and you're comfortable with LVOOP, you'll have no trouble figuring this out.

2. More convenience! Have you ever overloaded your Default case with error handling, timeout handling, and more? No more! DequeueMessage (and PreviewMessage) checks for errors on the input, errors from the dequeue prim, and dequeue timeout conditions, and returns unique messages for each of those conditions. Say goodbye to the hassle of nested case structures just to handle normal checking procedures.

3. A PriorityQueue! Ever wish you could easily prioritize messages in your queue? The LapDog Message Library includes a class that does just that. Better yet, it allows you to configure the number of priority levels your queue will have.

4. A collection of message classes for native Labview data types to speed up your development. Includes classes to support the following native types: Error Cluster, String, I32, Boolean, Path, and LVObject. If you need something not included, it's a snap to create your own class that inherits from Message.lvclass.

5. Palettes, cool looking wires, and more!

The LapDog Message Library requires VIPM Community Edition (or better) to install. The package currently requires Labview 2010; however, we hope to release a version for Labview 2009 soon.

I have been using this and it is pretty cool stuff. I am mostly using it because I want to learn about object oriented programming and this is a nice example.

Can you explain the benefits (other than #2 above) of using objects for messages instead of a string/enum variant cluster? Do you ever override the message class and create methods other than create and get?

Aristos, I was able to test and understand your solution. So thanks again!

Awesome. That really cleared things up. Mostly about the dark side but the other stuff is making much more sense too.

So, there you go. I hope that helps.

That is going to take a little bit to digest. But thanks!

So is a packed project library a good way to create a plugin? I have not gone beyond simply sending messages to and from the plugin vi so I am not sure what other issues I may run into with dependencies. I want the plugin to be one file that I can drop into a directory. The reason that I don't want it to be an llb is because I discovered dynamic dispatch and llbs can not have two files of the same name.

Maybe it is easier to just stick with a standard source distribution.

Is there a typedef involved?

I think that class controls are all typedefs.

I have written a class which contains LapDog Message Queues as two of it's data members. A vi that I am calling dynamically has two LDM queue controls. In the caller I get the queue objects from my class with an accessor and set the controls in the called vi with set control value.

It works unless the dynamically called vi is in a packed project library. Set Control Value returns Error 91 "The data type of the variant is not compatible with the data type wired to the type input" I tried calling the vi from an llb and that does work. I can send messages to and get replies from the called vi.

What I want to do is to use packed project libraries in a plugin system. I look in a directory for "file.lvlibp" files then look in each of those for a "file.vi", set it's LDM queue controls, and then run the vi. Is this a correct usage of packed libraries?

One more thing. When I build the main vi into an executable and load the vi into a subpanel from an llb everything works but the LDM object controls in the subpanel are missing their icons. They show up as a gray cube with a question mark in them.

I posted this question on "The Dark Side" but have not gotten an answer. I just figured out what The Dark Side is. Why is it called that?

Hi,

I have an array of clusters. There are multiple of types of control inside these clusters (number, string, enum, boolean). If I use event structure, I can manage to find out which cluster changes and which control changes but I cannot get the actual value of that cluster. I don't know how to get the reference of the cluster.

Could you please give me a hint?

This is the part of my code:

Best regards,

Thang Nguyen

I think this may be what you want. It will return the index of and value of the changed cluster in an array.

Find Changed Element In Array Of Clusters.vi