hooovahh

I think something like this could be in the idea exchange but would affect previously made VIs and their functionality enough that I don't think NI would implement it. Right now if I have an error in the Variant to Data because of a type mismatch, the value I get out is the default value for the data type. I think it should be the value wired into the Type terminal (similar to OpenG). Secondly what your VI is doing is slightly different (correct me if I'm wrong). It tries to match the data types based on the label name, not the data type it self. At the moment the Variant to Data doesn't care about the labels at all. I can have 2 clusters that have different labels, but the same data and the conversion will work properly. If I had 2 labels swapped (change bool and num2) then the data won't be able to be set, and it won't be listed in the "Missing" array because it found matching labels. Neat functionality but I don't have a use for it at the moment.

@rolfk Regarding the LabVIEW stop / Car into wall situation. I only use the LabVIEW stop in situations in development, when I know that all hardware and references I've opened, have been closed. Similarly I am only talking about using kill as an option after all resources have been closed (File/DAQ/Queue/Events etc). There is tons of details on how memory management works and I know very little. I just don't know what kind of affect I will see (if any). I've already released everything I care to release, and then tell Windows to remove the application from memory, terminating it and all of it's threads. (I'm guessing it executes this Windows function) What real issue could this cause? Can anyone say doing this will cause an application to be corrupted? Or for memory to not be released? I'm not advocating this method, I just think it is a pretty simply way to make an application more Windows like (responsive close) and I have not seen any side effect yet.

I noticed today that there is a private method "Owning Project" and it works the way AQ mentioned where it would not work if the project owning it was not open. As an experiment I added this VI to two projects and opened them at the same time. The property worked as expected where the VI running in the context of one project would return a reference to that, and if it was running in the second projects context it would return that reference. This property does differ slightly from the "Active Project" property which is a scripting method but not private. NI does not support private methods and it's functionality may change unexpectedly so use with caution, or don't use it at all.

Using a modified version of this. That VI specifically flushes out the working set memory for the application running named "SeqEdit.exe", it can be changed to any application name. Using this on any application will cause the working set memory to drop very low but as soon as you need memory again it climbs back up as expected. Using this code I've never actually seen any problems get fixed, just prolong the inevitable.

I like this. I'm going to steal this quote.

Dang, but my sincerest thank you for addressing this.

I don't have to resort to this I just don't know why it isn't immediate. When I call quit I want the application out of memory within human noticeable speeds. (say less than 500ms) I'll add a case to my standard Quit if in RTE VI that has a kill as an option set to false by default. If I see any issues this will be the first thing I change back.

If this is true close LabVIEW entirely to ensure that it isn't holding the resource. This isn't always necessary but if cleanup is not done properly this can be an issue.

There is nothing running, after all code has stopped executing, and Actors have have performed their cleanup and then I call the Quit. As for memory swapping out. This is what can be used to show the biggest time in shut down. If I force LabVIEW to release the working set of memory during normal execution, then Quit will take much longer to stop the EXE. Now this is something I don't do regularly I just noticed it made it worst. Even so why should this matter all my VIs are done running, when I say Quit why should it take a long time even if I did screwy things with memory. That's fine and all but the EXE is still running. I have the INI key of allowmultipleexecutions (it might be slightly different) set to FALSE, so if I exit (which just hides the UI) I can't restart the application until the last run is really done, which again may take a while. I also noticed longer shutdown time in newer versions. But what could the run time engine be doing that is so important, where killing it would be bad if all the things I care about are closed out properly? The problem with this question is no one but NI has a real answer, or could suggest why I shouldn't just kill it.

The most obvious (and most popular) answer is a state machine. You can queue up your 25 operations and then do them one after another. With a state machine you can have it update data, between states, or go to cleanup if something fails on step 15 or do what ever you want. You aren't limited to performing the 25 states one after another until they are all complete. I recommend a modified type of state machine called a Queued Message Handler (QMH). Go to File >> New... and select the Queued Message Handler under VI >> From Template >> Frameworks >> Design Patterns. This works in a similar way to a normal state machine but uses strings for the state names (not enums) and is more flexible, but also is more error prone (mis-spelled states for example).

So lets say I have a large application, lets pretend it is a 50MB EXE (it's not we are exaggerating). I run this EXE and it runs for thousands of hours, then I close it. When I close it all of the "Actors" run their own cleanup, and then the UI is hidden, then I call the Quit LabVIEW primitive. If I look at the task manager the program still runs for some time after calling the Quit function but eventually leaves the task manager list. I have seen in rare occasions (where I was messing with memory in ways I shouldn't) that caused the quit function to take up to a minute to actually exit. What does this quit primitive do? Why does quitting take longer than it should? As a test I replaced the Quit LabVIEW, with a task kill operation on the EXE name. Now when I hit the close button my application does the clean up on each Actor as it should, and then kills the program. This operation now feels instant. So is there something wrong with killing my program my way, after all logs have been closed, and hardware sessions closed? EDIT: Okay so a search with Killing LabVIEW brought up this work around for killing an Actor based EXE. So does this mean there is nothing wrong with killing other LabVIEW EXEs using this method?

I update type def'ed enums all the time. I think almost all of the time I am adding new values to the end, not updating, or removing them, maybe this is safer since the constants already in my application aren't having their values changed.

Yeah that setting in the VI properties is mostly useless. I say mostly because it does function, just not consistently with more than a few controls. You may resize to make it bigger, then go back to smaller and controls will move slightly, things won't be aligned any more and other general UI issues. For these reasons I never use that function. Instead I make my UI scale appropriately, using a series of splitters, and some times the Panel/Pane Resize events. The more complicated the UI the more work it is but it pays off in the long run when a EXE can be ran on any monitor resolution greater than some limit. If you have 2012 open the Finite DAQ Acquire example, it does some basic UI scaling using splitters.

Use the Variant Attribute. You can have an attribute named "Potato" and set the value to 100. Then Set another attribute (on the same variant) called "Apple" with a value of 13. Then read the attribute with the name "Potato" and you will get your 100 back. You will need to tell the Read Attribute function what the data type of Potato is but that's the only catch.

Yeah I realized that after I posted. Attached is my test that I think does what you want, or atleast will help you in one possible solution. It is a virtual array. You have a UI element that looks like an array but it is actually several clusters and a vertical scrollbar. Then the values in the cluster are changed based on the scrollbar to simulate an array control. You can then click and change the color, and going transparent will make the control not visible. This is some rougher code I was in a hurry and probably spent too much time on it as it is. Transparent Color Box Test.zip

I don't fully understand your problem but a transparent color box confuses me a little. Generally a color box is there so a user can select a color, how is the user going to know that the color box is there if it is transparent? Won't it look like nothing is there at all? Could you possibly make the color box not visible if they select transparent? I guess you would then need to detect a mouse down and show it again so they can select another color.

You will not what? I was asking if this was something made by NI Later will be what? Module generation? What does that mean? Yes, we all have a problem understanding your posts. Descriptions would help. Your posts are hard to understand and your code is not documented. If you are looking for help and beta testers please try explaining what is going on. I still have no idea what your code does. I assume it makes FPGA VIs but that's the only useful information I've been able to understand, and that was in the title.

...so you made something, but won't tell us what they do, or how to use them, but you want people to be beta testers?

Okay we need a little more context. I see that this is just a bunch of menu file so I assume the scripting functional already existed they just aren't on the palette. So where did these mnu files come from? Did you make them? I can't find any official post from NI.

Well a few links that I'm sure you've already seen. Ben's Docking example Dynapanels tst array of subpanels Snap off windows Messing Around with Splitters (can't seem to find source) By combining all of these you can get some neat UI functions. I've tested a few UI techniques and you can get some very nice flowing applications. I think what you are trying to do is very possible but will take some time ironing out the kinks. The things I've done with it were not as feature complete as what you are proposing. One thing to keep in mind is it maybe a good place for some OO code. You might be able to make new instances of a classes and then override the class with functions for the specific UI element. This could be an architecture where there are instructions on how to make your own UI elements that can be plugged in and used.

I used VMWare and actually liked it more than VPC. VMWare also supports sharing USB devices, so I could share NI USB DAQ devices to my virtual PC and it could be used. I think VPC has some support for this now but I think it only works with USB storage devices. There is a performance hit for sure but it wasn't too bad, especially with a fresh Windows image. VMWare also supported 64-bit Windows as the guest OS, and multicore.

I have. I'm not sure when I got it though because I just downloaded SP1 when it come out, and just recently noticed a pack of DVDs with the SP1 release.

... ... (but seriously cool)

Couple things. I downloaded the zip and all that was in it was a text file with some strange characters, no code. What you maybe talking about is the VI needs to have the compiled code in the .vi file for it to be dynamically loaded. If you go to the VI properties under the General section there is a check box for "Separate compiled code from source file" you want this off, or else it won't be able to be dynamically called. Not sure what version this feature was added (around 2009) but if the checkbox isn't there you can't separate the compiled code so there is no issue.

resourcedialogQuickDropplugins http://labviewartisan.blogspot.com/2010/08/improvements-to-quick-drop-keyboard.html