Leaderboard

One thing that I've wanted for a long long time in LabVIEW is Native Support for Dynamic Palettes. I'd really appreciate it personally if everyone took a minute to read (and possibly even vote for) David_L's idea on the idea exchange here. If you're interested, take a look at jgcode's post on JKI's VIPM Idea Exchange here too.

I favor this approach, too. Within a view element (and for us a view is a composite of individual view elements, not a large monolithic VI) the code handles user events (eg., button clicks) to send messages orresponds to messages by changing state (updating data or appearance). There is (generally) no need to pass control references; although I think passing control references can be a valid approach, most often I think it is not the best option in LabVIEW. Note that we do invoke lots of common code within the view elements themselves. With this approach views are quick and easy to create, and simple. (What is important is to keep the view decoupled from the controller, by the way.)

Having tried many of the solutions suggested here (and having authored the doc on the dark side about plugin architecture) I have a few comments based on much time spent wrestling with these issues. Agreed. Since Chris wants "plugins... able to update independently of the application", this is not an option. You're on the right track here, only it's widely considered poor practice to have anything in source directory have dependencies in builds directory. I tried this once - problem is, you end up with duplicate copies of many things in vi.lib. If you want to develop new plug-in code that links to this common source distribution, you can't drop vi.lib functions from the palette anymore. I tried to work around this with a "build wizard": In development, my plug-in would link to vi.lib and other common code as normal, but as a prebuild step the wizard would check all dependencies against the common code library, exclude these from the plug-in build, and perform relinking. The problem I didn't anticipate, is that new plugins often introduced new common dependencies! So, the wizard actually then had to check the main app and all existing plug-ins, to see if any new common dependencies needed to be moved to the common code library distribution, then I had to rebuild the main app and all affected plug-ins. It was a nightmare, and didn't even satisfy the original intent of decoupling. Here's the idea, illustrated: Plugins A & B have shared dependecies x & y with the Main App. Loading plug-ins directly from built app doesn't work. Moving x & y to common directory does work if the main app and plug-ins are linked to this common code distribution. But, when we introduce plugin C that has shared dependencies with the Main App (code w) or another Plug-in (code z), then those dependencies must be moved to common or else the new plugin (or existing plugins if the new one is loaded first) will be broken. The fix requires moving w and z to common, and rebuilding Main App and Plugin B. The solution using packed project libraries is a fairly elegant solution to this mess. Here, the interface is the only common code, built as a packed proj library (to the source directory, and treated as source code). The Main App uses this interface, not directly calling the plugins. The plugins are classes that inherit from a plugin interface class in the built lvlibp (yes, OOP makes this so much simpler). Lvlibp's build all dependencies into their own package using unique namespace. So, although there will be bloat to the program where dependencies are duplicated, the upside is that they can vary independently and not introduce conflicts with other plugins or the Main App. I'm sure there are other great solutions out there... but this one works for me. Go here for a more thorough step-by-step and example code. Hope this helps!

I was able to set both class and lvlibs without any problems. How are you calling the VI, i.e. what app refnum are you using? (I ran it standalone) A little later....... I can get error 53 if any of the Major, Minor, Fix numbers are zero. But works perfectly if they are all non-zero Aha! You cannot decrement the version of a user class. So if you are trying to set it to a lesser value, it fails with 53.

Following in the tradition of LAVAr's from around the globe, I am very pleased to introduce... Digby and Dexter! Dad sure has his hands full Mad props to Jack for the outfits.

Man I'm late too to congratulate, but here it is 'Gefeliciteerd!'

True, especially in this use case. I see your point about it being correct in terms of the framework. I'll mull it over and post if I come up with anything interesting.

Well the rotation can be handled by some Transpose Array I would assume. It's not a big problem right now. And if you create an U8 greyscale IMAQ image, you better connect an U8 data array to the U8 input of your IMAQ ArryaToImage function. But why did you say your numeric values are integers between 0 and 255? The Z value in the intensity graph only shows a 0 and 1 in the cursor display. So I really very much doubt that your values are between 0 and 255 and they are definitely not U8 but rather floating point values. So what is the minimum and maximum value in your 2D array?

In an array the datatypes are always the same type. You could read the spreadsheet as strings and at the time you want to do comparisons convert the string to the type you want