hooovahh

Scripting is your friend.  With it you can automate code development.  So given a folder of VIs, open a reference to them, then create a new object (text) set its value, place it and save the VI then move on to the next.  Here are a few links.

http://sine.ni.com/nips/cds/view/p/lang/en/nid/209110

http://sine.ni.com/nips/cds/view/p/lang/en/nid/209110

Note that scripting is free and is enabled using the Tools >> Options menu in LabVIEW 2011 and newer.

In 15 years I never used the matrix control before, nice!

I've never used it before either, but to be fair I'm not sure that the matrix control has been around 15 years.

So I did some testing with Arrays of numerics and seeing how close together they are. I found that the array of numerics are the same size, if you are using a System Array, Classic Array, or Modern Array controls. The Silver Array takes up more space, which didn't surprise me.

I couldn't find anything about smaller arrays, but in my searching I did find this post about small clusters.

The "TopLeftBorderOnlyCluster" is the smallest cluster I've found, but it has the down side of only being able to click it on the left or top edge. The right and bottom edge appear to really be 0px in size and unclickable.

I was told (possibly incorrectly) that both BSD and LGPL were very close. The explanation given was you can use it in commercial applications, and you can modify it, but the author must be attributed. I was not aware that LGPL was the one less recommended.

My knowledge on licensing is limited so please someone correct me if I am misinformed.

What do you think is the best way to help users? In a recent thread I helped a user with a basic data transport / manipulation problem. My reaction to her problem was to show her how to solve the problem with a better way to program so that her application would be faster and more flexible in the future. I didn't rearchitect anything, just made a suggestion for a small change.

Then rolfk came along and described a much simpler way to fix her problem. He acknowledged there were some potential problems in the design, but solved it quickly (i.e. with a simple cast) of helping?

To be fair I'm guessing rolfk was just suggesting another path. If you would have opened with the simple solution he may have replied with the "better way to program" answer.

You see this alot on the forums (and I do it myself). Someone will ask a question and an answer will have already been posted, but there are usually multiple ways to do the same thing, so I will post another possible answer (if I know of one). This gives the user more than one option, and they can choose what works best for them.

Hah, Hooovahh beat me to it.

I really do love that technique by the way, and I've been trying to combine your stuff with this:

I have made alot of progress, but it seems like XControls are never done. I really should post what I've come up with so someone else can have a go at it.

Well this isn't a VBA or Excel forum, so you will likely find better answers elsewhere. If this is being done in LabVIEW it is quite easy. You use the OpenG Array package and use the "Remove Duplicates" function, which returns the indicies that were removed. Then you can use the Delete From Array providing a 2D array and then removing columns or rows, at the indicies found earlier.

I agree to use defer front panel updates, but if you are dealing with coloring alot of cells (more than say 40) I would recommend trying to do something like this which uses a "Virtual MultiColumn Listbox"

This technique only shows a few rows of data, and the rest is shown as the scrollbar changes. This is a good candidate for an XControl.

This doesn't work because LabVIEW doesn't control the rendering anymore, it's moved into dotNET's domain.

Yeah I kinda figured that's why it behaves the way it does.

Hi hooovahh, thanks for adding the test cases.

I did test resize event handling and then noticed the same issues that you did. Since we are generating a new html document and loading it in the browser every time the size changes, it was really slow and the clicks were annoying.

For handling panel resize event, while still doing most of this stuff in LabVIEW, I would rather refresh in a separate loop and use lossy enqueue to a single element queue to pass on the panel resize message so that we don't refresh for every single resize event LabVIEW fires. Ideally, we should resize the thumbnails using JavaScript onresize event and calculate the thumbnail sizes within JavaScript, not in LabVIEW. Yair has lots of munitions on that. May be we can put together a quick example.

I'm not sure how close you looked at my resize code, but it is essentially a lossy queue. If you resize a windows by dragging you get lets say 100 events to resize, but I don't have the resize take place, all I do in those 100 events is set a boolean to TRUE, which is handled in the timeout case. So the resize only takes place if another resize hasn't been fired in the last 0ms. This isn't perfect but much better than performing 100 resizes on the UI.

Very nice, but I didn't like how panel resize wasn't handled, so I modified the .Net version to basically perform a refresh after a resize. I also wanted to see the disable function in action, so I added code to disable items randomly when a refresh takes place. One side effect is I see flickering of the images when resizing slowly. I added a defer front panel at one point but that didn't seem to fix it.

Regarding the "Click" noise, I'm wondering if you can query Windows and ask what the volume settings are (muted or not and volume level) then mute the speaker, then set the speaker back to the previous settings that it was before a refresh. There are examples on how to mute speakers using Windows DLL calls, but I don't know how to query the current settings.

Thumbnail Grid .NET Browser.vi

No problem! You're lucky I actually had a 64-bit RTE installed (though I have no idea why...)

That is odd, I'd assume it was from some NI tool that had been compiled for both 32 and 64 bit because of some increase in performance. Looking at MAX I also have 64-bit 2009, and 64-bit 2010.

I have a suggestion (back on topic to the original post). For the 1D to 2D VI you have a control for how many columns to make. Would it also be useful to have a control for the number of rows to make? I guess at that point there still is the choice of the order they are put into. So for instance I have an array.

[1, 2, 3, 4, 5, 6]

If I choose 2 rows how should the output look?

[1, 2

3, 4

5, 6]

Or

[1, 4

2, 5

3, 6]

My gut says it would be more useful to have the first but I could see uses for the second output.

If you don't, the reentrant VIs will block on whatever VIs are not reentrant. Instinct says this will only become a problem when you forget that you did it that way.

Yes, yes, and more yes. Some VIs shouldn't be reentrant (things like functional globals and uninitialized shift registers), but any other subVI in a reentrant VI should be made reentrant. I found an NI article that talks about it more a while ago but can't find it right now.

I've been burned more than once, where I had a reentrant VI spin off, but one of the subVIs were not reentrant. Under almost all circumstances the program would run like normal, but once in a while there would be a dead lock, where one VI was running this subVI that was waiting on another VI, which blocked all the other reentrant VIs from running.

Attached is a VI if you're interested, which can take a folder of VIs and turn them all into reentrant.

Save VIs as Reentrant.vi

I also have this application to silenly install LV2012 RT eninge if needed.

This is a great idea, and I've thought of it before but never did anything about it. One issue with LabVIEW when no runtime engine is installed, is there is no way to do any thing (kinda obvious but still frustrating). Having an AutoIt EXE that just checks for the existence of the LabVIEW runtime engine seems like a great idea. Not sure what JKI does at the moment, but I assume they could use something similar when distributing VIPM to a machine that may or may not have the right runtime engine installed.

Out of curiosity how do you do the automated install of the runtime engine? I understand there is silent switches that can be used, but do you have it automatically download the runtime engine? Or do you include it with the AutoIt EXE?

On a project once I needed to take a large sample of data, then break it up into chucks and analyze each chunk. I figured I'd use the waveform data type, because the analyzing I was doing was using a few NI VIs that used the waveform datatype. So I read, then used the split waveform VI then analyzed. I found that my VI was running really slowly and the slowness was from the split, and concatenate waveform VIs. I found it was much faster to read as an array of doubles, split or concatenate the array, then turn it into a waveform for the analysis.

I wanted to tell this story because in my case it (for some reason) was much for efficient to split and merge arrays then convert to a waveform, then it was to work with the waveform from the start.

If you are using cDAQ is there a reason you haven't tried the ethernet chassis? I swear there was an 8 slot option, and I also thought they were the same price as USB. I've had good luck with replacing a USB solution with an ethernet one which would be more suited for long routes.

Thats why I asked, I have never used AutoIT, so I don't know. Have you used it together with LabVIEW or other languages?

I have used AutoIt with LabVIEW. If you choose to install AutoIt (which is optional) it will install some ActiveX components. I can't remember why, but when I did this I found the features to be lacking when compared to just writing AutoIt code and compiling. I also looked into getting DDE to work between an AutoIt EXE program I wrote, and LabVIEW. I could get LabVIEW to talk to the AutoIt EXE but couldn't figure out the other way for some reason.

In either case I highly recommend downloading it and at least looking at the shipped examples. They do a pretty decent job of showing you how to do the basics. There's a relatively large community out there to support more complicated programs and functions. It's very liberating, being able to download a single zip that contains source, and a method to build an EXE that will run on any Windows machine, without needing a development environment, or run-time engine.

MonkeyLives=True?

But seriously I've never used AutoIt to test an application, just to automate button and key presses.

I'm sure someone else can chime in if I'm wrong about any of this, but from what I've seen the VIP and OGP file format is very similar. They both are essentially a zip archive, with file groups, and a spec file, and I believe an icon file.

You can unzip both programatically, and read the spec file if you want to read information about the package. The spec file is in an INI file format and you should have no problem reading.

The main difference I know of, is the VIP files cannot be created or edited manually. You cannot take an existing VIP, extract it, add files, then rezip it and use it. This is because there is added checksum information telling VIPM that the package has no corruptions. I don't believe the mechanism to recreate this checksum is documented so editing the package after it is built is prohibited. There is no such restriction on OGP. Extract, replace, and zip works just fine. Both can be installed using VIPM.

Whenever I find myself in need of a new tray icon, I usually do a search on Iconarchive or Google using descriptive terms for the pictures I have in mind.

I then download the images or icon files I find interresting, or just the ones I think looks cool

If the file is an icon file I use an icon editor to remove icons bigger then 32x32px in the file (I stick with IcoFX v1.6.4 - mainly because its simple and doesn't have a trial timeout, newer versions do).

Couple things. I have used Gimp in the past for icon file editing which supports transparencies and multiple icons (as layers) but does have limitations as far as usability to I may try IcoFX.

Another thing, which may be better in a new post, is what is the restrictions on using icons from sites like the one you posted? It has a "Commercial Icons" section which is where you need to pay to use the icons in a commercial application or website. I don't intend on using it for a commercial application, but a work related one. Does that mean I don't need to pay to legally use these icons? I'm sure most people would just grab images from a Google search and use them without thinking about it, and maybe I should too, but I am just curious about what is legal.

Sounds like you already have an idea of what to do. I've used Orca before to modify MSI installers. I used it to allow an installer to run under a unsupported operating system (Windows 7 at the time). I would give it a shot but adding an option sounds more difficult than just forcing the installer to run like I did. I would be surprises if it wasn't possible, but I would also be surprised if it was easy.

Honestly, one of the best things about this module is also the hardest to show on a spec sheet. It's extremely straight-forward to program.

The first thing I did (after understanding what this is) was look at the example program to see how easy it is to interface with. Obviously being the one who would have to integrate with it, this is one of my major concerns.

I think an alternative to this could be using a serial port to talk to an Arduino. NI's toolkit has a set of VIs for manipulating a 16 X 2 LCD.

I'm also a little surprised something like this didn't exist already. Some kind of quick feed back to an operator would be nice to get the current state of a system without needing communication to a host.

Here's one I posted a while back that you just drop in any For Loop that may take a while. It will pop itself open and show progress if a certain amount of time has elapsed and the loop isn't halfway done yet.

Darren's Weekly Nugget 06/26/2006

Very slick, surprised you have no comments on it in the last 6 years. I personally use the WireFlow Progress, available through VIPM. I wrap it in a functional global, so it is easier to use, and has my more commonly used functions exposed. I then wrap that into three sub VIs, Create, Update, and Close that behave as expected with only the needed terminals showing.

It does have a delay before being shown as well so it isn't seen for quick loading. It also has the ability to cancel, which I think is nice, especially because I can just turn on termination for my for loop, and wire the cancel into that.

As you mention, it is in the online help for the function. We also try to indicate this behavior in the Context Help for Delete From Array:

The fact that "last elem" is in parenthesis indicates that this is the behavior when you leave the index input unwired.

Okay this bugs me a little (but I do use this feature). What I normally see is the control name shown, and then in parenthesis I see the default value, if the value is not the default for that data type. So I may have a VI that will show or hide a VI, and I would want it to show by default. So I would have the control named "Show UI?" and the default would be made TRUE, which is what I would put in parenthesis. So my help would show "Show UI? (TRUE)". But this logic does not stand up with this VI, because I see "index 0 (last element)" is the control named "index 0"? No, it is index and the default is "last element" so I would want to see "index (last element)". I don't believe this is any real standard it is just what I've seen.

But now that I've thought about it I believe this is probably a lesser known feature, because it is not consistent with the other Array functions. If I leave an Index Array unwired it grabs the first element, not the last. I understand a VI can differ with functionality from one to another, I just think this is one reason why someone would not think that this VI works in this way.

Also add to the fact that not many VIs (only primitives I believe) behave differently if nothing is wired, verses the constant made from that terminal. I cannot make a sub VI that has a default of a blank string as a terminal input, but have the VI behave differently if I wire a blank string to it, versus wiring nothing to it. Again it goes to the inconsistency seen between this primitive, and other VIs that developers are familiar with.