Leaderboard

Generally, "Request Deallocation" is not the right solution for problems like this, even if it works more agressive than it did in previous versions, which I'm not aware of that it does. You should first think about the algorithm and consider changing the data format or storage to a better suited way. LabVIEW is not C! In C you not only can control memory to the last byte allocated, you actually have to and if you miss one location you create memory leaks or buffer overflows. In LabVIEW you generally don't control memory explicitly and can't even do so to the byte level at all. It's similar with other high level languages where memory allocation and deallocation is mostly handled by the compiler system rather than the code programmer. Writing a program in C that is guaranteed to not leak any memory or do buffer overwrites ever is a major exercise that only few programmers manage to do after lots and lots of debugging. So having this pushed into the compiler which can be formally designed and tested to do the right things is a major step into better programs. It takes away some control and tends to cost memory due to things like lazy dealloaction (mostly for performance reasons but also sometimes as defensive means since especially in multithreading environments there is not always a 100% guarantee that deallocating a memory area would be a safe operation at that point). Request Deallocation basically has to stop any and all LabVIEW threads to make sure that no race condition can occur when a block marked as currently unused is freed while another thread attempts to reuse that block again. As such it is a total performance killer, not only because of causing many extra memory allocations and deallocations but also because it has to stop just about anything in LabVIEW for the duration of doing its work.

Or learned to use the wayback machine - http://web.archive.org/web/20130329175236/http://www.developria.com/2008/10/project-management-from-the-de.html

Darren, that is quite a few long nights away. To whet your appetite, have many Slylandros!

Fair example. I tend to end up making simple interface classes for this situation but I know they aren't for everyone. Ideally I would have 3 lvlibs. A would be the messaging component, B would be the tcp component, C would just contain the set of functions which tie them together. I'm doing something similar with a file loader right now. I want a generic hierarchy of essentially key value pairs so that the lowest level component can be used everywhere. In the actual application I'm trying to write I have a file loader which loads my particular hierarchy which includes a system configuration object that contains N process objects which contain M plugin objects. So now that I've gotten the two libraries where I wan them, I'm writing a 3rd library which converts between the very generic hierarchy and the specific hierarchy, as well as allowing for some useful manipulations of the data set (lets say I only want to load process #4 and its plugins, but not the rest of the system). Edit: Its worth mentioning that while this is something I am definitely doing, I'd probably simplify it if I were writing from scratch -- I'm trying to refactor months of work so it can be used on a few different projects, which is why having these weird dependency links is currently desirable. Downsides to this are that it can't always work (but usually works enough for me to not worry about using lvlibs) and it does lead to occasional instances of bloat and situations where I have to convert between the types used by the different libraries, but it seems to work well enough for my purposes.

Let me know once you've got Slylandro working...the World's Fastest LabVIEW Programmer needs to be able to fly the World's Fastest LabVIEW Star Control 2 Ship.

I’ve used a single 2D picture control for similar work (no drag’n'drop, but I have full mouse-click logic including insert, delete, cut and paste, as well as “settings†and “disable†buttons built into the picture). It’s not that hard once you have made a “what is the mouse over†subVI that accepts mouse coordinates (you’ll need a cluster/class to hold the known coordinates of your icons). I would suspect that the VI server route would be harder.

If you want to do this using a table, here's some sample code that shows one way you can do it. As Hooovahh mentioned, it uses a table indicator, and controls that are moved on top of the table for each cell to make it appear that the table is editable. http://forums.ni.com/t5/LabVIEW/array-of-cluster/m-p/1822451#M625032

Tables don't work like that. A table is literally a 2D array of string. That is the data type it contains. It does not have provisions for numerics, drop downs, or other data types without extra work. That being said LabVIEW is a programming language and you can make it do what ever you want. In the past I've seen code where when you click on a field, a drop down controls is moved over top of the table to appear as if the table has a limited selection. But in your simple example is there a reason you don't just have a cluster with all of this data in it? A cluster which contains two strings, and two drop downs? Attached is a VI that looks similar to what you posted. Example Table.vi