Darren

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)

So we have a tool which is kind of like quick drop but searches the open projects (BTW it would be awesome to have this feature as part of QD).

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)

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)

Is there a way to drop a specific VI on a diagram a la quick-drop? I see there is a special invoke node App:User Interaction:Drop Control or Function, but it doesn't seem to work with VIs.

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)

That seems pretty interesting, though I don't want to copy pre-existing code, just a VI from disk. Maybe scripting could drop it in a new VI and your tool could grab it from there (seems like a rube goldberg approach). I was hoping someone who knows more about quickdrop (Darren?!?) could tell me how to do the very last bit of putting something on the cursor for dropping.

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)

Maybe Stephen's heard of it as the "http://wiki.openg.org/OpenG_Builder' rel='nofollow' target="_blank">OpenG Builder" and not just by it's acronym of OGB?

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)

Thank you! My idea is it can share to someone. Who don't need to add shortcuts again. If your guys can share your "QuickDropDiagramShortcuts" to me. That's great.

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)

In addition to slug bugs, we also watch for sting stangs (Mustangs) and cruiser bruisers (PT Cruisers). There's alot of hitting going on, needless to say.

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)

My kids rented Mario Kart wii last week, and it was really cool racing against people around the world. One of my kids spent hours trying to set a world record on one of the courses. That's one Christmas present picked out!

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)

Correct me if I'm wrong, but I think what JiMM is looking for is documentation on why the heck anyone should use the project (besides the obvious: "to build an exe").

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)

The info included with LV is pretty crappy (as usual).

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)

Could you urge the people involved in this effort to please run the list of tokens that will be eliminated through the "LAVA grinder" (or at least the LabVIEW Champions forum) before work is started?

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)

How do you make shortcuts?

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)

Just realized now that "Select VI..." and "Select Ctl..." are available from the quick drop list, bringing you directly to the open file dialog.

QD is really turning out to be one heck of a Swiss army knife.

Beans anyone?

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)

Is there anyway to force the tip strip on in LabVIEW when you want to?

I have been looking on NI's website, the tip strip seems to be a function of Windows. Is there an Active X or .net way to have more control over the tip strip? I think it is called the ToolTip. However when trying to google this I get tips on tools for windows. :headbang:

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

QUOTE (Michael_Aivaliotis @ Aug 22 2008, 03:08 AM)

To Aristos and the other NI folks arguing that the 3 button dialog VI is fine. All I have to say is, you just don't get it. This type of coding is not acceptable in my books regardless of how much pixie dust you sprinkle over it.

Let the record show, your honor (yes, I'm assuming Michael is the judge in this case), that I was not defending the appearance of the 3-button dialog VI, I was merely defending the use of a Flat Sequence in a UI VI. AQ made a perfect argument regarding Flat Sequence usage, and I was affirming that argument.

-D

P.S. - In his defense, though, given the huge amount of initialization required in the 3-button dialog VI, I'm curious how others would design it that it would look so different. Is the issue purely one of modularization? Would y'all be happy if he simply used more subVIs? Because regardless of how it looks, there's no way around the fact that all that code does need to run before you get to the event structure...

QUOTE (normandinf @ Aug 22 2008, 08:11 AM)

VI tags are easily found in Invoke node and can contain any data type. (I can foresee a nice OpenG set of VIs for that...)

In LabVIEW 8.6 there is a small set of VIs that deal with VI and object tags. They are located at [LabVIEW 8.6]\vi.lib\UserTags. Let me know if you have any feedback on them.

-D

QUOTE (Aristos Queue @ Aug 21 2008, 05:17 PM)

The defense rests, Your Honor.

Not so fast...before the defense rests, you should call your first witness, Darren, who has advocated Flat Sequences as a perfectly legitimate UI programming structure for many years (when was the 7.0 release?), for the very reasons you have cited.

-D

P.S. - Stacked Sequences, however, are pure evil. Just want to make sure there's no question on that.