Darren
-
Posts
622 -
Joined
-
Last visited
-
Days Won
66
Content Type
Profiles
Forums
Downloads
Gallery
Posts posted by Darren
-
-
QUOTE (crelf @ Feb 24 2009, 05:20 PM)
Oh crap, that was hilarious. Louis CK is great, I've watched some of his stand-up. Too bad his HBO show tanked.
-D
-
Why are you building your tool into an EXE? If it is to simply call the tool as a scheduled task in Windows, you can always schedule a task that launches LabVIEW.exe and specifies a VI to run as a command line parameter.
-D
-
The VI Analyzer VIs do not work in a built executable. There is certain internal functionality used by the VI Analyzer that is not supported in the LabVIEW Runtime Engine. I was surprised to see that we do not mention anywhere in the VI Analyzer documentation that the VIs are not supported in a built EXE. I have filed a CAR against the documentation (CAR# 147643) that we add this information.
-D
-
QUOTE (Aristos Queue @ Feb 12 2009, 05:34 PM)
Congratulations, Mr. CLNCA (Certified LabVIEW No Class Architect).I believe this statement will be my motivation to actually write the blog article on LabVIEW Object-Oriented Programming that has been brewing in the back of my brain for months now. You have been warned...
-D
-
QUOTE (ACS @ Feb 12 2009, 11:19 AM)
The CLD tests if you can design and implement a state machine. The CLA tests if you can design classes.Lest someone read this and get confused, I should point out that LV Class programming is not required on the CLA. You can certainly use them if you want, but they are not a required component of your architecture. I did not use LV Classes in my code for the CLA (and I passed).
-D
-
-
QUOTE (Michael Aivaliotis @ Feb 5 2009, 06:37 PM)
Thanks for the shout-out, Mike. And congrats on passing the CLD, Mark! I plan on posting an article on my blog soon about preparing for the CLA...stay tuned!
-D
-
I posted my suggestions for preparing for the CLD on my blog. See here.
-D
-
QUOTE (Michael Aivaliotis @ Feb 4 2009, 02:26 PM)
Did NI give you an old slow machine? Oh, I see, It's because you program in LabVIEW right? All the C developers get the good stuff.The start menu shoes up instantly for me.
Quad core @2.4 GHz, 4 GB of RAM. I don't think that counts as an old slow machine, does it?
I don't have any shoes in my Start Menu...maybe that was the problem?
-D
-
I just got a new Vista machine at work a few weeks ago. One of the first things I did was change the system theme to "Classic" so it looks like the old Windows 2000 look. All the font sizes look normal to me, I'm not seeing any bent wires in old code or larger-than-usual comments. I changed the theme just because I figured the fancy Vista shinyness probably wasn't worth any performance hits I knew I'd encounter (for example, the Start menu took a second to appear with the default Vista theme, but appears instantly with the Classic theme). From what y'all have said, it looks like the font issues were another good reason to go with classic.
-D
-
Q: What are you if you are a naked secret agent answering a 40-question multiple choice exam about LabVIEW?
A: The Man from U.N.C.L.A.D.
-D
-
-
QUOTE (crelf @ Jan 29 2009, 05:51 PM)
PS: when are you going to get yourself on twitter?
I tried describing Twitter to AQ at either the Norm lunch or the JKI lunch (can't remember which...they were both at the same place, with some of the same people) and I got confused looks and rolled eyes. I'm guessing we won't see him on there anytime soon...
-D
-
QUOTE (Ton @ Jan 27 2009, 11:14 PM)
Maybe any of the http://wiki.lavag.org/Private_events' rel='nofollow' target="_blank">Private events?Especially VI Redraw and VI Scroll, I think VI Redraw is the one you should study.
I tried those, couldn't get either of them to fire on a panel window move.
-D
-
There is currently no event-based way to determine if a VI's panel is moved. The previous two suggestions (your suggest of polling, and Aristos' suggestion of Windows DLL calls) are the only options. I have used the polling technique to link VI windows before...it's rather choppy. If you end up getting a decent implementation of the Windows calls working, I'd like to see it.
-D
-
QUOTE (crelf @ Jan 23 2009, 05:47 PM)
Hopefully everybody noticed that I wrote that VI 10 years ago. I was in LabVIEW Basics class, and it was my very first LabVIEW app. I assure you the framework I wrote during the CLA last month was much cleaner.
-D
-
QUOTE (PJM_labview @ Jan 16 2009, 05:25 PM)
I am trying to find out when the user either:- Press ESC when the Run-time Shortcut Menu is visible
- Click outside (of any LabVIEW window) to "escape" the Run-time Shortcut Menu
In LabVIEW 8.6 there is a private event called "Shortcut Menu Dismissed". There's also the equally-handy "Operate Menu Dismissed" that fires when you dismiss the operate menu of a ring, enum, etc.
-D
- Press ESC when the Run-time Shortcut Menu is visible
-
QUOTE (PJM_labview @ Jan 16 2009, 05:25 PM)
I am trying to find out when the user either:- Press ESC when the Run-time Shortcut Menu is visible
- Click outside (of any LabVIEW window) to "escape" the Run-time Shortcut Menu
In LabVIEW 8.6 there is a private event called "Shortcut Menu Dismissed". There's also the equally-handy "Operate Menu Dismissed" that fires when you dismiss the operate menu of a ring, enum, etc.
-D
- Press ESC when the Run-time Shortcut Menu is visible
-
QUOTE (Phillip Brooks @ Jan 9 2009, 12:42 PM)
Does anyone know if there is a vi.lib/ function, method, or property that can be accessed that will return the Context Help for a VI by file name? The file would not be loaded in memory, I want to supply the full path to the file only...I don't know of a way to exactly reproduce the Context Help window contents based on VI path only, but the private App methods "Get VI.Description", "Get VI.Title", and "Get VI.Icon" can get you pretty close. All of those methods take a file path input and do not require opening a VI reference.
-D
-
I use dual non-wide CRTs, both at 1152x864. Tried to switch to 1280x1024 the other day, but almost got a headache from the squinting, so I switched back. Laptop at home is wide 1280x800, but I rarely do serious programming at home.
-D
-
Sorry, Rolf. I was thinking only of the toolkits owned by the LabVIEW team (Database, Report Gen, VI Analyzer, Internet, etc. etc.) when I made that statement. I didn't think of hardware-related toolkits.
If you haven't already, please report this bug on the NI Forums so the AEs can investigate.
-D
-
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)
I'd go for a new context menu item, right below Relink to subVI, called Relink All Instances. It would need to have a confirmation popup of some sort, maybe like Rolf mentioned: "There are 500 instances of this VI in memory. Do you really want to relink all of them? This operation cannot be undone." When selected it could just automagically do a replace, like Michael discovered.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)
Wow, I just figured out the answer. Apparently this can be done using the "replace with" function. In the search results window. Just do a search on the VI then replace it with itself. Awesome!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
Rebinding the 'Enter' key on Quick Drop?
in Development Environment (IDE)
Posted
QUOTE (jasonw @ Feb 27 2009, 08:20 AM)
If you chant 3 times at 8:20 AM, no, I'm afraid Darren won't come answer this. I'm not what you would call a "morning person"...in fact, my pre-10AM response to this message is quite an anomaly. Kids woke up earlier than usual this morning...
Anyway, when I developed Quick Drop, I wanted to make sure I could drop items without having to move my hands from their normal "left hand: keyboard, right hand: mouse" position. So I added the ability to click and dismiss Quick Drop to immediately drop the item, as Ben pointed out. This is called Super Quick Drop, and it's one of several advanced Quick Drop tips I've outlined http://forums.ni.com/ni/board/message?board.id=170&thread.id=361708' target="_blank">here.
-D