hooovahh

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

Each element of an array has the same properties. Therefore you cannot disable some elements of an array using properties, you must disable all of them or enable all of them. Is there something wrong with using an event to programatically disable them?

My intend was on the read to have a polymorphic VI for each type (variant being one of them) which performs the Variant to Data back to what is needed. I only was curious about replacing all of the writes with one Variant VI. I can't do the reverse because there's no way of changing a control at run time to the type needed. I did do this to make life a little easier. I create the polymorphic instances programatically, but not the polymorphic VI itself. I come to hate the polymorphic VI editor more and more with usability issues that make it slow to work with. Yeah I know, I can't wait to see the solution to this (sounds like not until 2015 or later).

I couldn't find a "Reuse Discussion" section so sorry if this could be in a better category. Lets say I have a reuse VI. It does some stuff with data that is passed in but the type of the data doesn't matter so I make it a Variant. Now this is sorta generic where I can use this with any data type, but there will be a "dirty dot" showing that a data type conversion took place whenever I use it with a data type other than a variant. The more correct way to do this is to create a polymorphic VI, with a VI type for as many data types as I think will be used (string, boolean, VI Ref, path, numerics etc). Then when this is used it will call the same Variant VI but with a "To Variant" primitive before calling the variant version. My question is this. Is all of this necessary? If I create a VI that works with a Variant, do I really need to make types for all of them that simply have the explicit "To Data" conversion instead of just using the variant version that does the conversion it self. One example I see of this is the "Data Changed?" VI from OpenG under the comparison pallet. This VI will work with any data type, and its default is a variant. So why did OpenG go through the trouble of making a version that works with 40+ other data types? In this example OpenG did not call the variant version but instead made one version for each data type, but I see the benefit of all other types just calling the Variant version. This way if I make an update I just have to update the variant version and all others call that. Otherwise any code update to one polymorphic types, means updating all other types.