Darren

My first thought was to solve it like jdunham suggested...it would be interesting to compare the performance of the techniques...I wonder if there's a way to get rid of the memory allocation on the second indexing tunnel? -D

QUOTE (Justin Goeres @ Dec 6 2008, 08:40 AM) Popping up a dialog and requiring user interaction doesn't seem like too much of an improvement over Michael's Find/Replace trick (and I believe his trick is undoable). I was suggesting that we do automatic relinks only in cases of changed connector pane, with no renamed terminals (and the VI still residing in the same place on disk). Are y'all not comfortable with an automatic relink in this scenario? I think a change like this would primarily benefit people in Michael's scenario, or people who distribute VI-based APIs and need to add connector pane terminals between releases of the API without having to perform mutation or having their users perform manual relinks. -D

QUOTE (Michael_Aivaliotis @ Dec 5 2008, 09:36 PM) That is a nifty trick that I did not know about. Good find. I'm pretty sure I would have attempted to solve this with scripting if I had 675 instances to fix... Along these lines, I'd like to know how you guys would feel about LabVIEW doing the relinking automatically in some cases. There are a few reasons that the relink is currently manual...for instance, if there are several identical data types on the conpane, and in addition to changing the pattern, you also rearranged (and renamed) some of the terminals, the relink might not wire them correctly, so by manually visiting the subVI instance, there's a better chance you'd discover the incorrect routing. However, I must say that in my 7+ years doing VI development full-time, I don't think I've ever seen LV mess up the wiring after a relink. Do y'all think it would be beneficial for LabVIEW to automatically relink subVIs on VI load if the only thing changed was the connector pane pattern? In Michael's case, it sounds like having this functionality take place at edit time when VIs are already loaded would be useful as well. -D

I ran into this exact issue a while back...I posted the CAR number I filed on the corresponding thread on the NI forums. -D

QUOTE (jdunham @ Nov 21 2008, 12:51 PM) We've received this feature request before...we're looking into adding functionality along these lines in a future LabVIEW version. QUOTE (jdunham @ Nov 21 2008, 12:51 PM) It works great for opening VIs, but often it would be cool to have the VI it finds available for dropping on a diagram. PJM's suggestion about replacing an existing palette VI with your VI is intriguing, but it seems to me you might have linking issues (like VI search dialogs) when dropping a VI that normally resides in one location on disk from a completely different location. Could you perhaps add code where, if the user double-clicks a VI in your tool, it uses New VI Object to script that VI down on the diagram of the currently active VI, at which point you could drag it where you want it to be? I know it's not as convenient as putting the VI on the cursor, but it's the best solution I can think of with what you currently have available. -D

QUOTE (jdunham @ Nov 19 2008, 08:19 PM) How are you specifying which VI you want to drop off disk? If it's with a File Dialog, you can just use Quick Drop to "Select a VI...". In fact, I have a shortcut ('sav') for Select a VI to make it even faster. -D

QUOTE (jdunham @ Nov 20 2008, 02:14 PM) You can use scripting to drop a VI from disk (the New VI Object function has a path input), but there is no easy way of putting an arbitrary VI of your choosing *on the cursor*. The Drop Ctrl or Func method will only take an object name (as a string), and that object has to be on the palettes. The only way I can think of (and this is very kludgey) is to programmatically add the VI in question to the palettes with the Palette API (maybe to a dummy user.lib subpalette?), programmatically refresh the palettes, then use Drop Ctrl or Func (or Quick Drop) to put the newly-added palette VI on the cursor. The main problem with this method is the amount of time it takes to programmatically refresh the palettes. -D

Your VI was saved with its block diagram removed. You need to find out if there's a backup of the VI anywhere that still has the diagram...otherwise, you're stuck with it. Also note that you can't use a diagram-less VI in any LabVIEW version other than the one it was last saved in (i.e. the version used to remove its diagram). Good luck, -D

QUOTE (crelf @ Oct 28 2008, 07:40 PM) I assume that's it...I've heard of the OpenG Builder but I would have had trouble with the "OGB" acronym just reading the initial unedited post. -D

2.63 on my first try...I think that explains why my VI wires are so straight. -D

QUOTE (ancle @ Oct 2 2008, 10:05 PM) See http://forums.lavag.org/-t11805.html&view=findpost&p=51007' target="_blank">this post, where I attached a file with my shortcuts. -D

This problem always intrigued me, but I was never able to come up with a solution. In case anybody is interested, I posted the Round Robin problem on the LabVIEW Puzzles thread on the NI Forums, and one of the NI Forums members named ShotSimon was able to come up with a solution. See here. -D

I agree...it seems to me we should turn off this setting for subVIs in a built EXE. I made sure the App Builder team is aware of this thread. For now, you can use the attached VI Analyzer Test (saved in 8.6) to detect this situation in your VIs before you build an EXE. Place this LLB in [LabVIEW Data]\VI Analyzer Tests, then launch Tools > VI Analyzer > Analyze VIs and the SubVI Suspend When Called test will be one of the tests you can run. Note that in LabVIEW 8.6, you do not need to have the VI Analyzer Toolkit installed in order to run tests...the UI and Engine for the VI Analyzer are now part of core LabVIEW...the toolkit now consists of the toolkit's original test suite and the VI-based analysis API. Let me know if you have any questions, -D

QUOTE (AnalogKid2DigitalMan @ Sep 3 2008, 04:14 PM) My son (who was 3 at the time) started calling PT Cruisers 'slugs' because "they kinda look like slug bugs". So we call slug bugs, slugs, cons, and Ds. 'Con' is convertible. 'D' is Durango, which is what I drive. -D (for 'Darren', not 'Durango')

QUOTE (JiMM @ Sep 3 2008, 06:39 PM) I just bought Mario Kart Wii a few weeks ago. For anyone who was a world-class expert at Mario Kart for the N64, you may find some of the differences beween N64 and Wii to be a bit annoying. For example, you can lose powerups that you're holding onto if you fall off a ledge, get hit by an opponent with star power, etc. Also, power-sliding (now called 'mini-turbo') has lost a lot of its subtlety, which is a shame for those of us who perfected it on N64. They made the off-road areas (grass, mud, etc.) slow down your vehicle a LOT more than in N64...for example, there was a shortcut at the end of the DK Jungle route where you could bypass the inside cave by power sliding directly across the cave through the thicker dirt...this shortcut (and many others) has been neutered on the Wii. I believe they tried to compensate for this by making mushrooms give you a much bigger thrust...but since you can very easily lose mushrooms you've been saving, I don't think it's enough compensation. All that being said, the game is still awesome. There are twice as many tracks on the Wii as for N64 (although many of the Wii tracks are retooled versions of Mario Kart tracks from SNES, GBA, N64, GameCube, etc.). The races also have 12 players now instead of 8. I really like the addition of racing bikes...in fact, my favorite vehicle in Mario Kart Wii is the Bullet Bike, which has a super-tight turning circle...very helpful on some of the very wind-y Wii courses. Being able to play people online is a major plus. Unfortunately, all the badasses online already know all the super-fast shortcuts on all the routes, and I haven't taken the time to figure all of them out. There are several ways to drive your vehicle. One is to hold the Wiimote sideways (or insert it into the 'wheel') and use the Wiimote like a steering wheel. Another is to hook up the Nunchuk and use its joystick. Still another is to use the Wii classic controller. I have tried all 3 methods, and I prefer the Nunchuk method, since the joystick makes it easiest to power slide. The classic controller provides a joystick, but the controller is kinda small, and my hands cramped up when I tried it. So in conclusion, I would say that Mario Kart Wii is not *quite* as awesome as N64, but it's close (maybe my opinion on the Wii will become more favorable if I ever get as good at it as I was on N64). I never even played Kart on the GameCube because I heard from enough reputible sources that it was a waste of time. -D

QUOTE (Michael_Aivaliotis @ Sep 1 2008, 02:16 AM) I was primarily responding to the "as usual" comment. Anyway, my favorite use of the project is the built-in SCC. Being prompted to check out a file that I don't have checked out whenever I start trying to edit it is really handy. -D

QUOTE (JiMM @ Aug 31 2008, 11:00 AM) Can you qualify that statement? I'm (obviously) biased, but I feel the LabVIEW documentation is some of the best I've ever encountered in the software world. I didn't immediately jump on the project bandwagon in 8.0, but when I eventually did, I found its use and documentation pretty straightforward. If you had problems, with the project documentation or anything else, please report it on the http://forums.ni.com' target="_blank">NI Forums so our Applications Engineers can file bug reports (CARs) so we can make the documentation as good as possible. -D

QUOTE (neB @ Aug 29 2008, 11:00 AM) The "authorities" have been notified of your concern. -D Edit: The authorities say that even if we remove a setting from Tools > Options, it is highly unlikely that we would remove it as an INI token as well.

I understand your concern, but if we just receive a bunch of INI files full of the same tokens (because everybody stuffed their files with tokens everybody else uses), the study provides NI with no useful information, and this benefits no one. So do what you want, but I feel that the best way for this study to benefit the LabVIEW community would be for everybody to submit the INI files they actually use. -D

Instead of submitting an artificial INI file, the study would probably be more effective if you submitted your actual INI file, then encouraged everybody (who would have been supplying you with INI tokens you don't use) to submit theirs as well. -D

Looks like I wasn't the only guy who thought Ctrl-Space was a useful key combo... -D

There's a text file containing shortcuts on the Quick Drop webpage. You can copy the two INI tokens in that text file into your LabVIEW.ini file and you'll be good to go. For convenience, I've attached the file here...actually, this is my latest list of shortcuts, so it may have a few more than the one on the webpage. -D P.S. - You'll notice that almost all of my shortcuts can be typed with the left hand only (I'm right handed). Thus, if I type a shortcut, and then click in the VI to dismiss Quick Drop and automatically drop the item, I never have to move my left hand from the keyboard, and I never have to move my right hand from the mouse. *This* is how I am able to program so fast with Quick Drop.

QUOTE (jcarmody @ Aug 27 2008, 05:08 AM) Click the Shortcuts button in the Quick Drop dialog. http://lavag.org/old_files/monthly_08_2008/post-4441-1219849257.png' target="_blank"> -D

QUOTE (Norm Kirchner @ Aug 26 2008, 10:30 AM) I have a shortcut ('sav') for Select a VI. So I Ctrl-Space, 'sav', click in the VI, and I have a file dialog to pick a VI from disk. http://www.youtube.com/watch?v=sRA0bRtsuqA' rel='nofollow' target="_blank">Total beans. -D

QUOTE (ASTDan @ Aug 22 2008, 10:29 AM) I don't know how to control the tip strip from an OS level, but I do have a colleague who didn't like the way control/indicator tip strips behaved, so he made his own. It's a 2D-style string control with a black border and pale yellow background that he shows/hides and programmatically moves around as needed, and looks pretty darn close to what a real tip strip looks like. The only limitation I remember seeing in his implementation was that (obviously) his tip strip couldn't go beyond the bounds of the front panel window, whereas a native tip strip can do this. -D