hooovahh

Oops you are right sorry.

The first issue I have with your code isn't your code at all. You have in your profile settings saying you use 2011 but these VIs are saved in 2012. No big deal just thought I'd mention to help LAVA try to have the version you use the most, the version in your profile. You have wires going from right to left. This makes code less readable and should always go from left to right. If for some reason you just must go from right to left, I recommend right clicking the wire choose Visible Items >> Labels and then add the text "<< <<" (without quotes) to help identify places that have wires going the wrong way. You're using a sub VI for the Elapsed Time, which was an Express VI. I would recommend right clicking and choose "View as Icon". This takes up less block diagram space and is a more commen way sub VIs are seen. Wires go under things. Whenever possible don't put wires under subVIs, or constants. Try to just cross other wires. Unnessicary bends. Try to have as few bends as possible in the wires Error handling. If there is an error writing the file your loop will continue. Try to have some error handling so it at least gives the user a chance to exit if there is a problem. Your while loop never ends! You wired a constant to the stop terminal. This means your program never ends and you are forced to press the Abort button. As someone else has said, this is like stopping your car by crashing into a tree. It will stop you but you should use the brake. At a minimum add a stop button so the file gets closed properly and the other resources closed. Personal preference but I like to see labels to the left of their controls not on top, not a big deal. I would have changed how the frequency determines the note with an array of constants, instead of using the case structure. It is less readable, and harder to update if you ever wanted to change it. The method Shaun mentioned is probably good too. I don't like Silver controls for much, especially for simple things like Error that the user is never intended to see. If you do use Silver controls try to be consistent. You have the Frequency, Chart, and booleans silver but the threshold and sound format are not. Add more comments. I see very little explaining what's going on. Add VI documentation explaining what this is and how to use it. There is only one plot on the chart and it is named "Plot 0". I would either name it, or remove the channel list from being visible. Because there is a while loop I made the assumption that this is a standalone application. If this is the case you should have the window appear like a normal Windows application, with close working, and other debug controls hidden. When you run the VI it asked for a place to save a file. It does not say what the file is for, or what the expected name/format is. It should have a VI before it asking to get the path and handle these settings. If the user cancels the file dialog an error is thrown, this should be handled. I'm guessing a way to fix the 100Hz is to check the "Detected Amplitude" from the cluster and if it is below a threshold then ignore the value. I've done some of these changes but not the ones I felt unsure of how you would want it done. Note Recognizer Hooovahh edit.zip

Yes, the terminology is slightly different depending on who you ask, but for many cases VIG = Functional Global = LV2 Global. I didn't know that the Actor Framework was OO based. Knowing that I also would be careful about using a VIG to maintain settings, but as I said before it could have another layer on top using a sub VI called "Get Settings" which all it does it read a VIG which maybe a little cleaner.

I am not an expert at the Actor Framework. I've only used it a few times, so I'll answer the easy ones in my opinion. 1) The Hardware Actor should have the hardware settings. 2) Is it necessarily for the other Actors to know the settings? If not then they don't need to know. If you want the other actors to know I would recommend using a VIG where only the Hardware Actor performs writes, and the other Actors only perform reads. You could get away with this by using two separate VIs that call the same VIG, one with a constant for write the other for a constant for read. Then you can find all instances of writing/reading to verify that only the correct Actors are writing to it. If you have a VIG being written to in multiple places at once there is no way to maintain the correct data (just like a normal global).

I really like the idea of this and am curious about if there is further development/official API? That being said I found a few issues, some of which I know can't be worked around at the moment. First if you run the demo and collapse, the play controls, then the one just below it, then restore them but in opposite order, you will have odd behavior where things don't restore properly. I know this has to do with the interaction with multiple collapses in the same direction (two vertical/two horizontal), and I thought moving the splitter a set distance, instead of to a specific location would fix it but it didn't for some reason. Secondly is an issue you're already found dealing with the "Scale Objects While Resizing". It looks like this property is not exposed. In my opinion this is the deal breaker for this API. Many times I will have a graph or table fit to the whole pane, and I (as well as my users) have gotten use to the fluid movement of a resize.

Okay so the Pane Size event does fire, but as shown in my example, the Panel Resize does not. Edit: Thanks for the cross post.

Okay I swear I saw this somewhere but I can't seem to get it to work. If I have a subpanel and I load a VI into it, then run the VI and resize the subpanel (causing the VI in it to resize) why does my "Panel Resize" event not fire in that VI? Attached is a quick test. Run Child and see the "NewBnds" value change as you resize. Now run Parent and resize. Notice that "NewBnds" does not change. Crosspost SubPanel Resize Test.zip

He's joking (I assume). We really need to implement the sarcasm font

Yes I've seen this demo, and have played with the XControl too. A few things I don't like about it (but have never mentioned to the author) is the fact that you don't have control over allowing the user to close a tab or not. If I'm using this with subpanels, there is a use case where I load a non-reentrant VI into the subpanel and may not want the user to close it. Also I think it would be nice to be able to have control over what happens when a window is closed. Should it pop back in or close?

Well if we wanted to get tricky I think it could be hidden a little more. We could use the Windows Message Queue library. You could register for mouse movement, and then use that to fire user events. I don't know if you can register for a message that isn't tied to a HWnd, so now that I'm thinking about it I don't know if that would work. But even so I don't think it's that big of a deal. Sure you are polling but only while the object is being dropped. So this will likely happen relatively quickly.

Okay I think I got it. Attached is a main and graph VI saved in 2011. The main can launch a new graph because it is reentrant. You can create a new graph window by clicking a boolean, or by dragging an item from the multi column listbox. Closing or stopping the main will cause all of the reentrant graph VIs to stop. If you created a new graph using the MCLB it will follow the mouse movement (with 50% transparency) until the mouse button is released. I used a few tips that fabric mentioned, but I did it using only native LabVIEW code, no Windows DLL calls, just the mouse VIs, and the VI property nodes. MCLB Drag Reentrant.zip

I almost feel like the sarcasm tag wasn't even needed for this one.

I don't know what (if any) value can come from low level editing like this, but I am curious about what things are possible. Like would it be possible to make a 0px splitter bar?

If you are having problems installing VIPM you may want to contact JKI or post on their forums here. As for alternative ways to install package files. The packages them selves are just zips, so you can extract the file and see the contents. The spec file defines things about the package, and the files and groups. Using this information you can manually install the files by placing them in the right locations. It wouldn't be too much trouble to make a VI that does this. HOWEVER, this will go against what JKI has been trying to do with VIPM having configuration management. Lets say you manually install a bunch of packages. You have no way of knowing what conflicts, or limitations exist and you may end up with code that is broken, or missing components. You also don't know what versions of what packages you have already manually installed, and you may overwrite VIs with newer, or older versions of them selves. VIPM helps to know the dependencies, and links requires, as well as the limitations, and environments that those VIs can be used in.

The example code posted by Ton works just fine. After adding it to a VI you will need to re-link the event to the pane but both the "Mouse Down?" and "Mouse Down" work just fine for stopping the VI only after a double click.

Okay so I promise I haven't been working on this since November, but I did come up with a solution that uses pure LabVIEW (mostly) and doesn't rely on ActiveX, .Net, or HTML. It is very rough around the edges. There is little error handling, there is at least one default subVI Icon, and I'm pretty sure there are some unclosed references. But in any case, extract the zip and run Main Parent. It will call a dynamic number of Children, each one being an item in the grid. They are then put into the Parent using some Windows DLLs. Then when there is a mouse down we can fire the event and determine what one was clicked. It still supports captions, mouse over, and disabling items. It also now supports resizing without the odd clicking sound. The images look much more crappy because of how LabVIEW loads and then zooms the images. You can also change the number of items while it is running. For me it took about 700ms to load 8 images but I do have 8 logical CPU cores. Alot of the Parent/Children code was taken from the DynaPanels found here. Native Test.zip

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.

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.

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.

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.

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