Leaderboard

I will certainly admit that the placement within Quick Drop of the new keyboard shortcuts isn't the most ideal location for the feature (although it is documented in the Keyboard Shortcuts topic in the LabVIEW 2009 Help). But before deciding to spew forth vitriol against a feature you can freely choose not to utilize, please note that the following conversation has already taken place several times within the walls of NI over the past few months: QD Fan: "Hey Darren, I really like the new keyboard shortcuts in Quick Drop!" Darren: "Thanks!" QD Fan: "One question though, why do I have to launch Quick Drop first to use them?" Darren: "Because every single keyboard shortcut letter is already claimed by something in LabVIEW. Since I can't go messing with the default shortcuts myself, I'm simply using Quick Drop as an entry point to start defining new ones written in G." QD Fan: "Oh, ok. That makes sense." It would be great if we could override the default keyboard shortcuts in LabVIEW with our own (I never use Ctrl-D to distribute objects or Ctrl-T to tile windows!). However, that would require extensive work in the menu code to allow user-defined VIs to run when menu selections (or their associated keyboard shortcuts) are pressed. I inquired about this during LabVIEW 2009 development (knowing that JKI was already doing some work in this area), and was told that nobody with knowledge of the menu code would be able to work on that kind of feature any time in the near future. So instead of throwing in the towel, I took what I thought would be a useful feature, and wrote it anyway, in the easiest way I knew how...as a plugin for Quick Drop. So instead of pressing Ctrl-D to drop controls/indicators that are wired to the selected object, you press Ctrl-Space-Ctrl-D. If it helps, maybe you can close your eyes when you do this so you don't see the Quick Drop window appear for a split second before it disappears? And maybe it would help if I told you that the shortcut mechanism is pluginable? I only had time to ship LabVIEW 2009 with three QD shortcuts (Ctrl-T, Ctrl-[shift]-D, and Ctrl-R). But I'll be posting on my blog soon how you can write your own shortcuts for more keys, including info on how you can use whatever is currently typed in Quick Drop within your plugin code (Replace with Quick Drop instead of the palettes, anyone?). If anybody wants to start experimenting on their own before I have a chance to post more detailed info, check out [LabVIEW]\resource\dialog\QuickDrop\QuickDrop Plugin Template.vi. -D

No problem. [watch] (few other simulations included in this movie) It grew up into quite serious real time dynamics simulator with Euler integration scheme, non-linear spring equations, collision engine, independent display and calculation rates... Few details for those wanting to play little bit (performance is much better than in previous version): Only Nodes and Terminals may be movable (in terms of LV class hierarchy) - so no constants and no flat sequences Masses are proportional to object size and scaled with "Mass ratio" parameter - do not set it to 0 "force factor" scales wires elasticity Damping is applied to wires only (not to bouncing). Very high damping will make wires almost stiff Gravity is in pixels/s^2. y axis points down dt is integration step size in seconds. Fractions of seconds make sense. Smaller is (almost) always better - particularly for collisions fps is display only frame rate Have fun spring-wires2.zip

Hi Ton I am fairly new to OOP but would still like to suggest the following from my current experiences: Using the verification statement for inheritance can help: Ask yourself, or jot down on paper, if the subclass (e.g USB) IS A more specific type of the superclass (e.g. GPS) USB is a GPS (makes sense from a DAQ-type POV) Serial is a GPS (makes sense from a DAQ-type POV) TDMS is a GPS (does not makes sense) CVS is a GPS (does not makes sense) Therefore TDMS and CVS should not inherit from GPS. You may want to create another superclass that these two classes inherit from - e.g. a Log Interface - and this class could be have a association with GPS (either through aggregation or composition relationship etc...). I have been told (in other posts) that design pattern knowledge is the way to go to improve class hierarchy design - this is something I am trying to achieve at the moment. I have had similar issues as you along the way learning this (as I am sure others have too). Its all part of the fun IMO (Endevo) Mike H mad a recently great post regarding Interfaces in LabVIEW - it is work checking out. And of course AQ's Design Patterns Document on ni.com.

Hi Shaun DAQmx for 2009 is now available for download from ni.com drivers and update page Similiar options as before, but with cooler names DAQmx 9.0 http://joule.ni.com/nidu/cds/view/p/lang/en/id/1278 DAQmx 9.0 Run Time Engine http://joule.ni.com/nidu/cds/view/p/id/1388/lang/en DAQmx 9.0 Run Time Engine Core http://joule.ni.com/nidu/cds/view/p/lang/en/id/1368

Scripting for lv2009 was just released. http://decibel.ni.com/content/docs/DOC-4973#cf

Am I the only one who thinks this is really stupid? Not because of the shortcuts themselves. They're useful. The problem is with placing them in QD. W. T. F. !. This is the kind of thing that would be ideal in something like the right-click framework - select something, operate on it. Why is it in QD? Obviously the answer is simple - someone wanted it and didn't have anywhere else to put it which would make it easily accessible, but I find this to be totally unrelated to the QD functionality and very undiscoverable.