Michael Aivaliotis

This is a known issue and has been reported before. See here. If you think this behavior should change contact NI directly. Otherwise you will have to wait for Stephen to see this thread and then he has to agree with you and then he has to open a ticket. It's faster (and takes less arguing) to do it yourself. But you never know, today could be your lucky day. It usually takes at least two complaints over a span of a year or so for issues like this to get noticed by NI.

QUOTE (orko @ May 19 2008, 05:16 PM) What model is that?

QUOTE (Justin Goeres @ May 19 2008, 11:45 AM) Well, in that case it OK. Seriously, unless you are in First Class (which may be possible with your luxurious lifestyle), no matter what size laptop will be a pain on a plane. Just hope that the person in front of you doesn't decide to recline their seat (which always happens anyway).

Here's a VI Shots interview with Justin and his OLPC. Check out TurtleDraw. Very nice. Edit: It looks like OLPC is partnering with Microsoft. Gonna switch to Windows? Uh oh.

QUOTE (Aristos Queue @ May 18 2008, 07:37 AM) I was just about to post a rant about this very same thing. I found this a problem from day one. Not sure why NI never thought of this before 'cus it seems obvious to me. You want us to use the project environment don't you? For starters, why doesn't NI change the icon of the titlebar of the project window? That way you can find it and click on it easier from the taskbar. --- As far as the screen size, I think it's more of a resolution issue and it's not that simple. If you have a desktop screen then it's nice if both the desktop screen and the laptop screen have the same resolutions. if they don't, then large diagrams on the desktop will be overflowing on the laptop. Airplanes are not for programming. If you are programming on a plane, then change jobs. If you need to read a document or something then get a small laptop or hand held device. If I could get a 15" laptop screen with the same resolution as my desktop screen (1920x1200), then I would get it. If not then I'm not sure If I would.

Not sure why but can't download your attachment. Please upload again (using a simpler name).

QUOTE (Gary Rubin @ May 16 2008, 04:53 AM) Thank You! C'mon people. none of you have seen code like this? I think the hardware vendors should start outsourcing the development to LAVA members.

QUOTE (BrokenArrow @ May 15 2008, 08:17 AM) Re-Write? Uh oh, You're never suppose to use that term. Ever! It translates to: "You just wasted company time and money on a perfectly good piece of code" Remember, LabVIEW users "Optimize, Modularize and Reuse". Now go forth and practice these terms in your day to day conversation. For example: "I optimized that code we got so it's more modular and can be easily reused in our current and future applications". Now doesn't that sound more salary increase slash promotion worthy?

QUOTE (Yen @ May 15 2008, 11:16 AM) Yen, you need to lighten up once in a while. BTW, check this out... even Chuck Norris' cat can roundhouse kick: OK, so I had to post this... I couldn't resist, since you guys won't do it I will.

Perhaps "best" was too strong a word, but I think Classes need to be examined as a way of implementing hardware interaction.

World Wide Telescope

Where are his ouzies? Man I loved Chuck back in the 80s.

QUOTE (PaulG. @ May 13 2008, 11:12 AM) Wait a minute. Hold on there. So if a VI makes a VISA call to a GPIB instrument and that VISA call has a string input constant with a properly assembled format taken from an operating manual for that instrument, it's not a driver? You better tell that to 90% of the instrument vendors out there. "LabVIEW SDK", now I'm really laughing out loud!!! HAHA. QUOTE (Gary Rubin @ May 13 2008, 11:56 AM) I agree with that. If a VI is calling a device-specific DLL, I wouldn't call that VI a driver; the DLL would be the driver. I'd probably call a VI a driver if it was performing the hardware interface using only native Labview and OS functions (i.e. memory peeks/pokes). Gary Spoken like a real C programmer. QUOTE (Daklu @ May 13 2008, 04:14 PM) As to the original question, "When is a VI a 'driver,'" I'd say a single vi is almost never a well-written driver. (I suppose there may be some trivial cases where a single vi could serve as a driver.) A good driver is generally a collection of vis. If your hardware has a single vi as a driver it likely needs to be broken up or rewritten. I would agree that in complex hardware this may be true but I disagree that a single VI can never be called a driver. QUOTE (Aristos Queue @ May 13 2008, 07:08 PM) What if the DLL is a LV-built DLL? Do the VIs in the DLL count as a driver? Touché QUOTE (rolfk @ May 14 2008, 01:07 AM) I don't think you can draw the line that strictly. Very strictly speaking the device driver is nowadays the piece of software that translates user application level requests into hardware specific cammands and address accesses. And that piece has to reside inside the kernel as kernel mode device driver since that is the only way to directly access hardware in nowadays protected mode OSes. However talking to that kernel device driver directly is tedious at best so they usually come with a DLL that provides an easier to use API and can be considered part of the driver as well. But with that I do not see any reason to exclude the LabVIEW VIs that access that API as being part of the driver either. After all they translate the not so easy to use DLL calls into something that can be used much more easily in LabVIEW. And once you are there why not qualify any collection of VIs that translates access to some form of hardware in something more LabVIEW friendly as a driver too? I wouldn't go as far as calling VIs to access the normal OS API as drivers though, but that is an entirely arbitrary and subjective classification on my part. Rolf Kalbermatter I agree with rolfk but I think we all need to make a distinction here. There is a different definition for the word driver depending on what software language you are using to program the application layer. To us, a driver can be LabVIEW friendly and contain VI's we just plop down (regardless of what's inside the VI's), or can be LabVIEW agnostic in the case of a pure C DLL call which we have to interface to by writing wrappers. In both cases, it's a driver but the level of LabVIEW integration varies. I think the best LabVIEW driver is not really called a driver at all, but is a specific Instrument Class using LVOOP.

Does anyone know how to programmatically launch the compare VI's tool and compare two VI's that I specify? LV8.x

One thing that ticks me off to no end is when you discuss a new application with a customer and they bring up the fact that NI has "drivers" on their website so this should automatically translate to: "The app can be finished in a day or two right?" People, a hand full of turd balls does not translate to a full blown user interface with real time graphing, reporting and data analysis application. Unless of course you're a mystical fairy who shoots pixie dust out of your a** when you fly.

QUOTE (Jim Kring @ May 12 2008, 04:17 PM) Ya, what makes it more confusing is that I'm not using any libraries in my project. However I assume that I'm calling libraries in vi.lib somewhere without knowing it.

QUOTE (Jim Kring @ May 12 2008, 03:54 PM) As far as I can tell I'm building an Application. Edit: I figured it out. I had the "remove unused members of project libraries" unchecked. It kinda makes sense, but it's hard to relate that to a list of mnu files. http://lavag.org/old_files/monthly_05_2008/post-2-1210633712.png' target="_blank">

Can someone tell me why all these mnu files are in my build output support folder and how do I get rid of them?

I would of used a Wii nunchuk controller.

If you were to pay for online video training then I would definitely check out LabVIEWMastery.com. The site is run by our very own LAVA member Ben Zimmer and is highly recommended by me. You can't go wrong with it. You also get a trial period where you can check out some of the content before you buy.

The LabVIEW Wiki is BACK UP NOW. Thanks for your patience.

The LabVIEW Wiki is down for maintenance.

Check out the Google Ad below your post.

QUOTE (jasonw @ May 7 2008, 02:23 PM) Probably because your employer is blocking Youtube: that lets you bypass the corporate overlords UltimateUnblock.Just type in the URL of any Youtube video in the field and voila!

QUOTE (crelf @ May 7 2008, 04:56 AM) Now I know how crelf gets the highest post count... automated response bot.