Darren

Ok, hopefully this will make things easier. The menu item I hijacked was Tools > Measurement and Automation Explorer. I don't know what version of LabVIEW this option was introduced in. Probably 8.0 if I had to guess. Anyway, I never use this menu option, so it was a good candidate for my prototype. This menu option launches project\max.llb\MAX Launcher.vi. If you replace that VI with your own VI, then whatever key combination is assigned to Tools > Measurement and Automation Explorer will launch your VI instead. In my case, it launches my Quick Drop prototype. I changed the key assignment (with Tools > Options > Menu Shortcuts) to Ctrl-Space which is easy for me to type with my left hand, and isn't currently assigned to anything in LabVIEW on Windows. Hope that helps, -D

QUOTE(yen @ Sep 3 2007, 01:57 PM) For my prototype at NI Week, I didn't need to do any polling. I'll give you a hint...I found a VI-based utility that you can launch from a keystroke in LabVIEW, and I hijacked it by putting my Quick Drop VI in place of the existing utility. -D

...and I'll throw in some parsley to garnish the gruel for an explanation of the two Always Copy and Swap Value nodes to the left of the "Do Not Delete" Sequence Structure. -D

QUOTE(eaolson @ Aug 16 2007, 05:45 PM) I ran into this problem in a recent project...I was able to work around it by changing my picture control into a 2D array of picture controls, where the picture control element in the array had no border (so the pictures in the array all sit next to each other, and it *looks* like one big picture). Turns out using the built-in scrollbars on the array control looks fantastic, with none of the redraw headaches I had before with the single picture control. The only drawback is that scrolling the array takes place in an incremental fashion. For me this isn't a big deal since the UI I was constructing was more or less a grid in the first place, so scrolling in increments of one grid space (i.e. one element of the array) actually looks pretty nice...never have to worry about half a grid row/column being visible in the UI. -D

QUOTE(Tomi Maila @ Aug 8 2007, 10:44 AM) Well alrighty then...let me know if/when you guys want me to write a VI Analyzer test for this, and what specifically it should detect. Another idea I had was that the test could have a configuration option that would return a failure for *any* Value property on the diagram, as long as there is something wired on the conpane. That way you could sift through them yourself to make sure none of the non-implicit ones would cause the problem. Also, I noticed the Val(Sgnl) property also demonstrates the bug. -D

QUOTE(Ben @ Aug 8 2007, 07:30 AM) I read through this thread a few times to get a better grasp on the problem. It seems to me that you would want a VI Analyzer test that detects whenever the Value property is written for a control that is wired on the connector pane. Does that sound right? I could write a test that would detect this case for implicit property nodes pretty easily, but for property nodes with control references wired to them, that's a different story. I could detect the Value property on a property node that is wired directly to a control reference, but once you start getting into cases where the control reference is passed through a loop border, a subVI, other property nodes, etc., it becomes much more difficult to develop. So as it stands, I could pretty easily write a test that would detect implicit property nodes (or property nodes wired directly to control references) that are writing the Value property for controls on the connector pane. Would that be useful? Please let me know if I missed the mark and the test should detect something different. -D

One of my favorites is Aristos Queue's scrolling LED XControl. -D

Maybe try clearing your browser cache? -D

I have a few suggestions for you. First of all, don't select all 4 Office support options in the installer, all that does is install each of them one at a time, where each subsequent selection just overwrites the files of the previous one. For installation purposes, you should only select whatever version of Office you currently have on your machine. If the version of Office on your machine changes, you need to uninstall/reinstall the toolkit to update your Office version-specific files. We are looking into ways of alleviating this confusion in future versions of the toolkit. Next, I assume you're building executables of your application for distribution? If so, you should follow the instructions for building executables in the Report Generation Toolkit User Guide. I have attached the latest User Guide (version 1.1.2) to this post, since it has the most updated instructions regarding building EXEs with the Report Generation Toolkit. Now if you are distributing the EXE to users with multiple versions of Office, you will need to create an EXE for each different Office version. Even though only the Office 2003 files are installed on your computer, when you build the EXE, you can include the dynamic VIs for any Office version by accessing the version-specific files in the "Compatibility" folder on your Report Generation Toolkit CD. Finally, I should point out that the latest version of the toolkit is 1.1.2. It is a free upgrade for users of version 1.1.1. It includes various bug fixes, along with support for Office 2007. The installer for version 1.1.2 only supports Office 2000, XP, 2003, and 2007. But the "Compatibility" folder on the RGT 1.1.2 CD still contains the Office 97 support files. Please let me know if you have any other questions. Again, we're working on ways to make this a much easier experience in future versions of the toolkit. -D

QUOTE(LV Punk @ Jun 21 2007, 12:56 PM) Wow, I'm impressed. I tried to reverse-engineer the palettes a few months ago with that method and I didn't get nearly as far as you. Looks like your images are correct other than the coloring, which is a lot farther than I was able to get. Anyway, here's a hint I learned...if you write the U8 "image" array of a palette object to a binary file, you'll have a .emf file that contains the palette image of that object. I studied the .emf file format and was able to extract all the header information in G, but I gave up when I tried to start parsing the actual .emf drawing commands that appear in the file after the header. At that point I looked around for a G-based EMF file reader, and the only one I could find was in George Zou's G Toolbox. And at that point, I actually took a different direction in the project and didn't need to take the EMF approach anyway. Nice work, -D

There's the Palette API posted on the NI Community website...this would be a good place to start if you've already got .mnu files that you want to present to the user in your own manner outside of the LabVIEW palettes. -D

QUOTE(jlokanis @ May 24 2007, 06:17 PM) Methods 2 and 3 (property node ref and This VI ref) are functionally the same if you don't wire the output of whatever property you're reading. They return a "Self Reference" to the VI that does not need to be closed. Instead of dropping a control ref and re-linking it to the VI, you can drop a "This VI" reference from the Application Control subpalette. Ooh, now that I think about it, that reference may drop as "This App" instead of "This VI"...I don't have LabVIEW open right now. Either way, This App/This VI are the top two choices on the top of the list when you operate-click the reference. Hope this helps, -D

QUOTE(crelf @ May 23 2007, 02:43 PM) My rudimentary web searching skills are revealing the largest ranch in Australia to be about 30,000 sq. km, and Texas is about 680,000 sq. km. What else you got, Dundee? -D

QUOTE(xtaldaz @ May 23 2007, 02:12 PM) I wear my 'Large' LAVA shirt sometimes anyway, even though it makes me look like I should be in a Will Ferrell SNL skit. Some chick in downtown Austin actually asked me one time (when I was wearing my shirt) what LAVA was. Her eyes glazed over after I mentioned computers. I think next time I'll make up something about volcano worship. -D

QUOTE(xtaldaz @ May 23 2007, 02:00 PM) I wish I'd known you had an XL LAVA shirt when you still worked here, Crystal...we could have traded! -D

QUOTE(Tomi Maila @ May 23 2007, 01:31 PM) The feature I've been wanting that would be well-suited for one of these mythical "XNodes" would be a growable Array Size function, that returns 'n' scalar "dimension size" outputs, where 'n' is the number of dimensions of the array. I would much prefer this to the current method of dropping an Array Size and an Index Array. -D

Hey, if there's another T-shirt giveaway at the BBQ, make sure to bring plenty of Extra-Larges this time. Remember, everything's bigger in Texas. -D P.S. - Seriously, I'm guessing you guys like the idea of me wearing a t-shirt with a big ol' LAVA logo to work...but I'm guessing my LabVIEW R&D colleagues don't want to see me in a tight t-shirt of any variety. P.P.S. - haha, I'm glad to see my 100th LAVA post was something classy like this.

QUOTE(Jim Kring @ May 18 2007, 09:46 AM) Hey Jim, Seeing your post reminded me of a similar technique I use for debugging Event Structures. You inspired a http://forums.ni.com/ni/board/message?board.id=170&message.id=248138' target="_blank">Darren's Occasional Nugget today! -D

QUOTE(BrokenArrow @ May 18 2007, 10:14 AM) I know a lot of people have wrapped the Delay function in a subVI and given it error I/O...if you do this, you can put your Delay "subVI" at the end of your error chain in your loop, guaranteeing it runs after all the other code in the loop. -D

QUOTE(yen @ May 18 2007, 06:06 AM) I saw the "Null Vote" text, but kinda didn't think about it. This is the only on-line survey I've ever encountered where viewing the results counts as a vote. I'll make sure to register what the words "Null Vote" actually mean the next time I read them... -D

QUOTE(Herbert @ May 17 2007, 06:12 PM) County Line on the Lake does provide an all-you-can-eat group deal...at least they did when I went there in Fall of 1998 with about 100 other senior engineering students... -D

QUOTE(Aristos Queue @ May 17 2007, 03:15 PM) Hey, at least you got to vote...it says I've already voted, but all I did was view the results without voting. I demand a recount! Actually, I was also going to pick "somewhere else" since the Salt Lick is in BFE, but I really couldn't think of a venue in Austin that can accomodate such a large party and provide the amount of food that The Salt Lick provides. Bring on the meat! -D

Alrighty, here it is. Create a directory under your My Documents\LabVIEW Data folder called "VI Analyzer Tests". Put the attached LLB in that folder. Now, the next time you launch the VI Analyzer, you'll have a new category in your tests list called "User-Defined Tests" that contains the Find VI Calls test. With this test, you can specify the names of VIs (as strings), and the test will find any instances in your VIs of subVI calls to this VI name, along with any string or path controls/constants that contain the VI name (in case you're calling it dynamically). If you're not looking for instances of Globals, you can ignore the "Types of Globals to Detect" option on the config page (I added this for somebody who needed to only find a certain type of a certain global). This VI Analyzer test is saved in LabVIEW 8.2.1 and is only compatible with VI Analyzer 1.1 and later (the current version as of today is 1.1). I hope it helps, let me know if you have any problems using it. -D

Do you have the VI Analyzer? If so, I've written a test in the past that will do this subVI search. It doesn't ship with the VI Analyzer though...let me know and I can dig it up and post it. -D P.S. - If you're not sure whether or not you have the VI Analyzer, it's included in the Dev Suite, or sold separately as an add-on toolkit.

QUOTE(i2dx @ May 2 2007, 12:42 PM) That reminds me of a line from the now-canceled HBO show "Lucky Louie": "Do you know how much money we have in our bank account? Negative 50 dollars. We have to *raise* 50 dollars to be broke." -D