hooovahh

Name: Toolbar Class Submitter: hooovahh Submitted: 16 Jul 2014 Category: User Interface LabVIEW Version: 2011 License Type: BSD (Most common) Toolbar Class Copyright © 2014, Brian Hoover (hooovahh) Author: Brian Hoover (hooovahh) Environment Support: LabVIEW 2011 and up Windows only (likely XP and newer) due to .NET dependency Description: This is a toolbar class designed to make toolbars in the UI, which appear more like normal toolbars seen in Windows. The idea for this came about because I wanted a way to make a simple toolbar, but didn't want to have to make all the button states for mouse not over, mouse over, mouse down. I just wanted to provide one PNG file for a button, and have it take care of how the button should look. I also wanted a way to handle when there are more buttons than there is room for horizontally. When this happens I wanted a More Options button to appear which when clicked gives a vertical list of the remaining buttons, and a veritcial scrollbar if there are too many buttons to show vertically. I also wanted support for basic veritcal and horizontal separators. This toolbar class can do all these things, and all that is needed is to provide the buttons as PNG files with alpha layers. other file types like JPG, and BMP are supported but won't look as good just because buttons don't need to be a rectangle and can have soft edges. The Add Icon(s).vi is a polymorphic and also can add images from Image Data, or the native LabVEW picture data type. But these image types have the same issue mentioned with JPG and BMP that they don't support alpha layers. Dependencies: This relies on the following OpenG packages, a VIPC is included. OpenG Error Library-4.2.0.23 OpenG Application Control Library-4.1.0.7 OpenG File Library-4.0.1.22 OpenG String Library-4.1.0.12 OpenG Array Library-4.1.1.14 OpenG LabVIEW Data Library-4.2.0.21 Installation and instructions: At the moment this is not distributed as a package but just a zip with the required files in it. Install the OpenG packages required or install the Required Packages.vipc. Then run the Example Toolbar under the Example folder. This uses images from within the Example Images folder and must be in the same directory as the Example Toolbar.vi. There is also a Toolbar Tree.vi which shows the public functions as they could appear on the palette. Distribution: This code was downloaded from the LAVA Code Repository found at lavag.org Click here to download this file

Post an example of your code so others can see what you mean. I don't have IMAQ so I won't be able to try it myself. Also if this is a real bug you will want to notify NI too.

Funny you should say that, I'm actually helping organize this year. So there's a chance I'll give the prize to myself. Conflict of interest? Maybe.

Oh man that is cool. I didn't get anything last year so I should get a myRIO this year right?....right?

Finally got the confirmation I can go. Now to frantically buy everything. Also Hooovahh Incorporated a division of Hoover Corp is donating a Teensy 3.1 microcontroller.

Or have moderators around to split topics...

So whenever I go to use this function for simple programs, I always open the VI copy away the functions it calls (which admittedly aren't much) and paste those into my VI instead of calling that VI directly for that reason. Wouldn't it suck if all VIs on the palette didn't return an error but instead had a simple error handler in each of them? Then why do that for this function?

I agree with the error message. But I found that if you go to File >> Open Package File(s) and select multiple packages, one or more of which is built with 2014, then choose to Add to Library, a error comes up explaining that it was built with 2014 which is incompatible. Not sure why this error wasn't used in more places.

This is generally because the package was built with VIPM 2014 which had new features not compatible with previous versions of VIPM.

Would the UID work? It looks like it applies for all GObjects. The help states that it is only unique for objects within the same VI but you could try to hash the UID with the VI name or something like that.

It is voodoo magic. Explain to me why Copy 1.vi gets executed when you drop the XNode on the palette? This is a neat feature, but it doesn't help us get more insite into XNodes.

That is some voodoo magic. I was wondering how that was done too but never looked into it. If I had to guess I'd say Xnodes have the capability to run something on loading of the Xnode into memory. There are obviously at least 3 files in that library, the _Copy 1.vi, _GetHelp 1.vi, and _State 1.ctl. The two VIs are password protected, and don't really go anywhere. EDIT: So it doesn't have to do with the XNode getting into memory. If you load the XNode file as a library it doesn't launch anything. From there you can't do much other then read the library name, get the locked state, and get the Icon of the library. DOUBLE EDIT: So the GetHelp appears to do nothing and loads nothing other typed controls into memory. It never returns an error and does nothing. The Copy function always returns "FailTransaction" as the reply, and never returns an error and appears to do nothing with the XRef input. It does however run the <LabVIEW>ProjectFind LabVIEW Add-ons.vi with the input Source having a constant. Still not sure how the XNode runs this VI when you select it from the palette, or drop it on the block diagram.

It isn't clear what you are trying to say. On the second PC, what happens when you run the EXE? Does it run? Does the EXE have a broken arrow? What do you see? Have you only been able to run the EXE on the PC that the software was developed on?

If you changed that VI, and restarted LabVIEW, and the behavior of the dialog didn't change, then I would say that that VI isn't part of the low level dialog that you see in that control. That dialog that you see could be buried in the LabVIEW.exe file and there might be no way to edit it.

I was just in the middle of saying this. Make a copy of the PickTime.vi and name is something different. Then have on your front panel the time and date control, but don't show the button for picking the date, instead have a boolean that calls your copy of the PickTime.vi

Yeah I'm guessing Tim is right. You'll need to either install all the needed driver, software, and run-time engines on the other machine, or create an installer that includes all those things. In the project under build specifications right click and create an installer. In the install go to the Additional Installers section and choose the software tools you used. Then when the installer is built these things will be in it. Expect your installer to grow into at least 1GB but it sounds like a big program so it will probably be bigger. Once these things are installed new installers don't need to include all of this extra stuff, but it must be there the first time or else you won't be able to run.

After a Read, Write, Get Property, Set Property, or List Contents I know that the reference is not changed. Meaning the TDMS reference going in, is the same as the one going out and there is no need to update the reference. I think that is what you mean by is the pointer maintained. An open operation does take a long time on large files, and is likely very hard drive intensive. Like most file I/O it is best to open it once, at the start of your application, perform all the read and writes with the reference, and then close once. I wouldn't recommend doing an open, then operation, then close, every time you have any data you want to read or write. I've never used the Asynchronous versions but I would assume they work the same way where the TDMS reference doesn't change between operations.

Who wants to resurrect a post . I have a white board in my cube and posting this example has been on my list for a while. Attached is an example of this progress bar loading splash screen I tried to describe a year ago. Nothing too special but I use something similar to this in my production applications. Build the Normal EXE and you'll end up with a 6MB file that when ran shows no UI for about 3-5 seconds. To make it worst add the 8th actor to the main VI along with the other 7. I removed it because it took way too long to build an EXE. The total VIs in memory with it added was around 4500. If you are missing any VIs feel free to delete them, or that entire actor, it is only meant to bloat up the number of VIs in memory and they are never even ran. Then build the With Progress version and you still get the 6MB file but the UI is shown within a second showing the progress of each actor being loaded into memory with an option to cancel. Then once each actor is loaded it loads the main and runs it. For this to work the Launcher is the top level VI and Main is set to always include. And there is a Pre-Build action that gets a list of the actors, and their relative path to the VI to load and writes it to the config file used in the EXE. This Pre-Build action is more elaborate in my production applications because not all actors sit in a folder called "Actors". Instead it opens the project and navigates based on library names, and connector panes but the idea is the same. EXE Loading Progress.zip

Yeah the merge solution is probably the right one, which sucks because I just got the post install hook idea to work, where it scans the installed files for MNU extensions, and then adds them to the root palette (the blank one) automatically. I guess the only downer is that you would then have to manage another VI for every XNode you have, editing the icon, description, and terminals to reflect what you want the XNode to be but that seems like such a minor complaint.

Okay thanks for the info. One more question (for now). What magic did you use to get this to work in the Package Builder? See I realize you have a custom MNU because VIPM's Package Builder doesn't recognize XNode files (as mentioned in the VI Shots). But how did you convince Package Builder to have a sub palette, that is linked to an MNU file? I can do this in a post install hook VI no problem, but what is interesting is if I open you package source in Package Builder, change something small like a description, resave and close, when I go to open it it will complain that a file has been removed from the palette and that connection between the subpalette and the custom MNU is lost.

Thanks for your help. Obviously the best solution is to just go to VIPM 2014 and use the newest, and also abandon support for 2011. Upgrading VIPM is a cost that I haven't talked to management about yet. But leaving 2011 behind is a decision I can make. Thanks again for the info.

Old topic I know, but the recent VI Shots got me interested again. I noticed that the Filter Array will be broken if the "Items to Filter" is a scalar and not an array. The original OpenG ones accepted either an array or scalar. This was on version 1.3.1.31 because I don't have VIPM 2014 yet, and I also want to support a reuse library of 2011 so to be fair this might be changed in the newer versions.

I had hangouts open in a chrome window not maximized. When they started doing demos I maximized my screen, which kicked me out of the hangout, and started from the beginning again, so I skipped to live. Then the demo was done so I unmaximized, also kicking me out and starting it over.

Well, in typical Hooovahh fashion I have a quick and dirty solution. You could set the control to be not visible, and instead make a picture control visible that is in the same location as the control but have a picture constant of the way the control should look when greyed out.

It really sounds like you want something embedded, and it really sounds like you don't have something embedded. Is there a reason for this choice? Work all you want at setting priority loops and avoiding the UI, but as soon as Windows feels like defragging, or indexing search, or update anti-virus, or timeout talking to a driver that doesn't exist, you will be at the mercy of Windows as far as loop rates are involved. Embedded cRIO, Real-Time, FPGA, or even a micro with CAN is going to give you better performance. What driver are you using for CAN? XNet comes with a driver level wait for messages so you don't need to poll the hardware for new messages. It works almost like a trigger on a message with an optional timeout. This might help performance as well.