hooovahh

It isn't quote clear what you are asking for. Do you simply want a list box that fits to a pane? If so use splitters to split up the UI into sections which can be resized independently.

Years ago I showed how you could call the 7-zip command line EXE to have it perform functions that are hard of impossible with the native LabVIEW zip, or OpenG. I suspect that the 64 bit built EXE could perform the compression without any issue and can be called using the System Exec. Beyond that I'm guessing you already know about TDMS defragging, and how it can save on TDMS file sizes. After a defrag most of the data will be binary, and won't compress much anyway. I'd suggest defragging first, and then zipping. If your size doesn't go down in the zip it might not be worth the extra effort.

So I have the need for a stack light, Red, Green, Yellow and I'd prefer something that can be controlled over a wired network via TCP. I swear I remember seeing something but now that I'm looking for it I can't find much. I found this place which is fine but I'm curious if others have had success in using stack lights like these and have any that are recommended. Thanks.

It isn't just that these special controls need to be there, but they also need to be connected to the connector pane the right way. Making a new VI does this automatically. It is somewhat like a DLL call. To call functions dynamically, the interface needs to be known, like what kind of controls are found at what location. Removing these removes the ability to call the functions from the NI API. This is similar to calling any subVI where if the interface changes you need to relink the VI to call it properly and some times rewire the VI. If you are new to LabVIEW you might want to check out some of the free training links at the bottom of this page. There's lots to learn for sure.

I think this is a bug. Also you can see the behavior without even running the VI. Just put the VI into run mode with CTRL+M and the behavior can be seen. Might want to crosspost over on the NI forums to get more attention. Some NI employees check LAVA (the cool ones at least) but you'll likely get more attention and possible a CAR posting it there.

Do you know what a non-disclosure agreement is? Well you agree to one when you sign up for a LabVIEW beta, and you can be subject to whatever NI feels that are legally allowed to come after individuals for. One such restriction is to not discuss beta topics outside of approved areas. This can have a real negative impact on NI's business. LAVA is about minimal censorship and unless you, or NI complain I won't be editing your post, but if I were you I'd edit your post, or ask them to be edited.

Do you know what a non-disclosure agreement is? Well you agree to one when you sign up for a LabVIEW beta, and you can be subject to whatever NI feels that are legally allowed to come after individuals for. One such restriction is to not discuss beta topics outside of approved areas. This can have a real negative impact on NI's business. LAVA is about minimal censorship and unless you, or NI complain I won't be editing your post, but if I were you I'd edit your post, or ask them to be edited.

Sound really cool and I hope it takes off. But based on my travel allotment for work, I won't be making it.

I get your point, and there is large amounts of debate over similar topics. Should I not use Variable=Variable++ since not all developers know this is short hand for incrementing a variable? To me the delete from array with nothing wired is used for getting the last element, but I get not everyone associates this function with that feature. But I suppose if you really feel strongly about this you could make a VIM that just has this one primitive in it.

There already is a primitive that does this. The Delete From Array returns the last element in the array if nothing is wired to the length and index. There was a thread on LAVA years ago about which was a faster method, and a few versions of LabVIEW the method you showed was faster, but in most the delete from array is faster. And it already has a quick drop dfa.

The all powerful Michael has spoken, and updated things.

Most front panels are removed automatically when building an EXE or DLL. I'm unsure of what the rules are but basically if the VI doesn't have settings to show it then they are removed. Password protecting the VIs seems to be sufficient for most tools network developers, but yes there is a risk of cracking them open. But even removing block diagrams and front panels, doesn't mean the VI can't be called similar to a compiled DLL. You might not know what is going on inside but it can be called with inputs and an output be returned. It may also be possible to load a VI of the same name in memory and have your functions link to the new one (assuming they aren't in libraries or classes). Protecting LabVIEW IP is a tricky one for sure. Even things like code obstruficators are rendered useless with block diagram cleanup most of the time.

Very neat and postage stamp sized. There are apparently lots of different ways to perform this and I have yet another way that I've been doing. This is part of my Force 1D Array Min or Max Size VIM that is part of my array package found here. I am curious what is the fastest, and under what conditions one works better than another. Also somewhat relevant is my Circular Buffer XNodes I made here. This one uses the shifting method, but tried to be a little more efficient with things like not shifting if it wasn't needed, and if a shift was needed to keep the shifted data so a consecutive read wouldn't require a shift or split and build.

Thanks for the advice. On my system all of the string character sets I tried had the same result, summing their parts, as NI's method.

So attached is my first attempt. I did things a little different than you described. For any one set of font settings I didn't generate the size of each printable character. I only get the size of each character in the string and cached the result. If that character for that set of settings was already generated it uses it. At the moment it only supports Left to Right text, without offsets (unlike the normal method) but that could be added. Also I included a test VI which after you run it a few times clearly generates text that is always faster than the built in method for a set of random strings. If you open up the font range obviously it is less likely to have a cached value for your characters and will take longer. Also my test runs the cached code twice, in the hopes I could see the difference when some text hasn't been cached but when you run it with 1000 random strings of random sizes it becomes noise quickly. Get Text Rect Cached.zip

Oh I like that. I too have done some image processing stuff and found that function to be quite slow. One simple technique I wanted to try (but probably wouldn't help) would be to have a string control that isn't seen, and get the size of the text in it, after setting the text and information appropriately. Not sure if several thread swaps using property nodes would be faster than the internal call to a LabVIEW function or not. But caching the characters would definitely be faster. I see a place where variant attributes could be used for sure.

Yes this is somewhat known and talked about, being able to white list a data type is important and I remember hearing black listing one would be possible at some point too but since that is for a future version of LabVIEW (2018?) it might not come. That being said AQ has a philosophy that is pretty sound in most cases when it comes to VIMs. The idea is you shouldn't have to white list data types, and really the true propegation of the code you wrote should dictate what data types are possible. If the code you wrote accepted the data type and worked fine, then it shouldn't need this function to force only that data type. While this is true most of the time I can think of a few places where the data type might be accepted, but cause unexpected results. Imagine if I wrote a randomize string function. It takes in a string, randomizes its characters, and outputs a new string. If this were a VIM it would also work with the 2D picture control since this has a data type that coerces to a string, and many string functions work on this data type. Of course randomizing a pictures bytes will result in garbage data so one might want to force that function to only work on the string, and not the picture data type which can coerce to a string. Here in my opinion is a good place to white list the data type, allowing for possibly another custom set of code which randomizes the picture in a known way. Anyway what I'm trying to say is personally I will try to use white listing (and black listing if it exists) as rarely as I can when writing VIMs. But still won't mind using them in places where I need them.

Web publishing does work in an EXE, but has many limitations and requires silverlight which is deprecated and only is supported in IE among other limitations. There are many 3rd party solutions for controlling a VI from a web page, and a couple 1st party that have issues. My personal favorite is this one, which the source is fully available.

Okay how about this. Attached is an example where you give an array of Bar Plot values, and a gradient graph is generated. It uses the gradient code I posted earlier, along with code to get the colors of the plot, and find their positions for replacing. It is somewhat robust in that the plot size and positions can change and the new gradient overlays should be placed in the correct locations. At the moment only positive values are supported. If you really wanted I think you could give the 3D look with some minimal effort. This is all using the picture control overlay feature of the graph, and on initial creation you can see the flicker between the normal solid bars, and then the overlays. Gradient Bar Plot.zip

I was going to suggest the 2D picture control anyway. I mean you probably can do some post processing like get the image of the graph, and then overlay an image of the gradient on top, but I don't think it is all that hard to draw a gradient bar. Attached is some code that does the trick and pulls code from the dark side. Gradient Picture Hooovahh.zip

First please post code, or snippets, but not pictures. You wouldn't upload pictures of notepad for a text based forum. Second if you are new to LabVIEW then you should checkout some of the free training online. NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Self Paced training beginner to advanced, SSP Required But as for your specific question you appear to have rings and enums. A Ring is a numeric where a single value corresponds to a text element which can be changed at runtime using properties. An enum is type specific numeric that cannot be changed at runtime, and will likely have type propagation when the values in it are changed. Attached is a quick demo that shows the difference. The Item Mode is an enum and has two values it can be, while the Selection is a Ring that can have its values changed. Clicking OK will return the selected item by indexing out the right string based on its value. Ring Enum Demo.vi Also it appears this is for a class assignment. You may want to study up on any materials the professor gave you on rings and enums.

There are a few VIs not setup to be reentrant. There is a quick and dirty solution, which doesn't work quite as well as I'd like but may work for you. If not you are welcome to try to make improvements. The following two VIs need to be set to be reentrant preallocated in the execution of the VI: \FP Publisher\Websocket_class\Protected\Connection Listener.vi \FP Publisher\Front Panel Manager_class\Protected\FP Server.vi And then the Open VI References in these two VIs need to have a decimal 8 constant on the Options terminal. There are two in each VI: \FP Publisher\Websocket_class\Protected\Connection Listener Repository.vi \FP Publisher\Front Panel Manager_class\Protected\FP Server Repository.vi Once I did that I was able to make a second example, and run them both, and then get updates from both at the same time. The problem is the close function doesn't differentiate from one web page to the other, so running the Cleanup.vi on one, will cause all webpages to stop updating, and then trying to cleanup a second time will result in an error. To cleanup only one at a time, more work would be needed to track the name of the VI better but for now this will allow you to have multiple web pages going at once, until I or someone else gets time to improve it.

I've been avoiding these functions since they are much less efficient than the variant to data functions. I made an XNode that you wire an array of variants to, and it will turn it into the cluster you told it. Of course if you don't like XNodes not written by NI you can do this normal VI that converts the array of variants, to a cluster variant, which variant to data can turn back into the cluster. Note that VI has a bug where clusters of size 2, 3, 4, or > 50 elements don't work properly. Also the Idea Exchange where Database Variant to Data function seems to do the same thing (also an XNode but by NI).

There is not a native way to do this. Clones are created and destroyed as needed, and I don't think there is a central place that keeps track of what ones are opened. In the IDE you can go to View >> Browse Relationship >> Reentrant Items, but I think this list is probably populated and maintained by the IDE and not some VI server pool. Your method would probably work fine as long as you remember to run that function and track them appropriately.

Firewall? Network restrictions? Have you tried starting in private browsing/incognito mode? This eliminates any left over cookie issues. I've been able to access the NI forums.