SteveChandler

Thanks. It's on order. I hope there is a new edition in the works just in case the author is reading.

Do any of you recommend this book? The amazon site has some pretty negative reviews but all dealing with poor print quality. One of the more recent reviews said that this has been fixed. My biggest concern is that the book seems old. I think it predates LVOOP.

Done

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?

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.

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.

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.

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?

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