hooovahh

I think if there was an unofficial patch put out, it would need alot of customization, on allowing the user to select things that it modifies. Because some people may want their VI.lib replaced, and some may not even want the Riffle function replaced. EDIT: Nevermind read his post wrong.

I think there was a T-Shirt that said something like This seems relevant.

I was expecting some neat little nugget from the VI.lib. Instead I found out that Eric needs to update one of his general VIs.

Wait...EVERYTHING...something tells me they should call them something other than "private message". I know we've had some sales guys that will use some features of the website to see what hardware they would want. Using it to recommend hardware and a chassis and make a shopping cart just for a quote. NI has then called our sales guy and tried closing the deal, not knowing it was for a quote. All they see is a shopping cart filing up with tons of stuff, and then nothing.

I just did a test and that is exactly how it works. I did not know that feature either. Normally I would use the OpenG VI "Current VI's Parent Directory" which will keep going up a folder until it finds a real folder (not a directory in the built EXE).

Now if only you could hide it at runtime, or make it 0 pixels in size.

Well my methods may be disgusting but at least spaghetti_developer agrees with my methods...on second thought I'm not sure how I feel about that. In all honesty my method probably has more maintenance, and is probably less obvious to another developer, but choose which you prefer.

UAC is one of those things I turn down right away on my own machines. I think Microsoft knew it would be something people would want to turn off right away because it is in the "Getting Started ->" which shows up in the start menu after a fresh install.

I agree but it can be slippery slope. Why stop at a built EXE? Should you commit the installer for your application? What about if the installer contains all the NI products that your application uses? Then every build and commit will potentially add GB's of data to the repository, and pulling that from a remote location will be very time consuming. Lets say you agree to commit the installer with all the tools, what about making a hard drive image with the system on it, maybe sysprep'ed for deploying to duplicate machines. Now we're talking about 10's of GB's of data every build and commit. And again someone may just do an update to get the latest and then unexpectedly be waiting for several hours while source, EXE, Installer, Tools, and hard drive images are downloaded. I generally stop after the installer (without the NI tools), but there have been instances where it made sense to commit the installer with all the NI tools.

So with most LabVIEW UI issues there is a work around. This work around only works for strings controls unfortunately. Hide the real string control off screen that has focus, then have it use the event for change value updating the string control on screen. Attached is an example in 2009 that does this. The key is to enable "Update Value When Typing" on the string with focus so that an event is fired after every key press. Keyfocus Without Border.vi

I've seen other similar posts about this issue and was wondering if anyone had a decent work around. This post reminded me of the issues I was having. Basically you have a list of channels that you can view on a graph. As you choose more signals, the plot fills up, and the Plot Legend fills with the signal names. I have it set to show no scroll bar on the legend until you have more than 11 signals. There is no limit to the number of signals on the graph, (this test VI only has 20) and so to see all the signals you'll need to scroll. This all works fine. The issue is when you select many signals, then scroll down, then select only a few signals. The scroll bar will disappear (by design) but the value of the scroll bar stays the same, showing a blank plots. Without the scroll bar you cannot change the value and are stuck until you select more than 11 signals and scroll up. So my question is this, is there a decent work around people have found? I can't find a property of the control that allows me to set the value of the scroll bar (or the optional index) back to zero. I also don't want to show the scroll bar when there are so few signals that it doesn't need to be seen. I would prefer a XControl that replaces the vertical scrollbar with one with more control, as well as not allow you to scroll down past the number of signals on the graph. Attached is an example that demonstrates this issue saved in 2009. EDIT: NI Crosspost Graph Channel List Problem.vi

This is an important thing to remember. Any CRC/checksum method will have multiple messages generate the same result. There are an infinite number of strings that will return the same MD5Sum for example. The likelihood of having two random strings generate the same MD5Sum is 1 in 340,000,000,000,000,000,000,000,000,000,000,000,000 (rounded down). Similar things can be said for GUIDs. There have been several attempts to break MD5 in a systematic way and I believe someone was able to but I can't seem to find the example at the moment. The example was a EXE that when ran would say "Hello Wold". Then there was a second EXE with the same MD5 and when it was ran it would say something else.

You may want to address him as crelf only because there is more than one person in this thread, with a real life name of Chris.

I hate it when mom and dad fight...

Yeah I totally agree that this should be a native LabVIEW function in the event structure. There are a few idea exchanges suggesting this, some with more votes than others. Here's the one I found with the most number (currently 229). http://forums.ni.com...nt/idi-p/921547 EDIT: Currently this is the 16th most common kudo'ed idea. http://forums.ni.com/t5/LabVIEW-Idea-Exchange/idb-p/labviewideas/status-key/new/tab/most-kudoed

This all sounds great. For some reason I thought this was done in some LabVIEW challenge a few years ago was it not? I can't seem to find it at the moment.

Well you are at a LabVIEW based community forum so I'm going to guess most people would tell you to stick with LabVIEW because of all the diverse fields that LabVIEW is used on, and for the large range of hardware and applications. That being said careers can change, and it may be a good idea to try something new. Keeping your options open is always a good idea and by trying out PLC and learning that field puts you in a better position down the road for other employment opportunities where you can say you are both familiar with PLCs and LabVIEW, but are not an expert in LabVIEW. It's your decision to make, but don't worry about if you made the wrong decision down the line. Things can always change and you can choose the other path in a few years if things don't work out. Or take on a completely different career that has nothing to do with programming.

You absolutely can detect the event of a scroll wheel (at least in Windows). You use the Windows Message Queue to detect the scroll and fire a user event. http://forums.ni.com/t5/LabVIEW/Mouse-wheel-scroll-event-ON-CHANGE/td-p/860112/page/2 Checkout the Scroll_Event_V2.zip file it has a nice example inside.

I'm not sure what parts of the registry you need to modify, but I believe that since Windows 7 the user level of the registry doesn't require admin access. So if your application is writing and reading values for it's own self then you can try to use this section of the registry and not need high level access. Also I'm not sure your environment but under some circumstances the easiest solution is to just lower the UAC level down, so that it won't prompt when an application tries to modify that level of the registry. It should also be noted that you can ready any part of the registry without increased user access if you perform an Read-Only on the open VI.

I may have missed it but where did it say it was controled with LabVIEW? Not that Intel would consider that a selling point for their product.

You can tell the one on the right has had light deprivation, which is why the monitor brightness is on maximum. I can't tell if they are wearing a white shirt or the brightness is washing out the color.

The resemblence is uncanny. I'd go so far to say that an automated image search alorithm thought you were the same person.

Wow I'm a little ashamed to say that I've always done a print screen, pasted my whole screen into Mspaint, then selected just the primative I wanted, copied and then pasted into the icon editor. Also I believe that Flickr allows you to search for images in the public domain, or royalty free. The site is massivly slow for me at the moment so I can't check but I think that's where I saw that feature.

I have never heard of being able to use a FPGA board with LabVIEW, that wasn't a NI FPGA hardware solution. I'm not saying you can't use a different board I've just never heard of anyone doing that. If you must use NI hardware (which I suspect is the case) the cheapest PCI model is going to run you $1500 just for the card, which is a DIO only card at 40MHz and 1M gates. http://sine.ni.com/nips/cds/view/p/lang/en/nid/202011 That's not including the cables or terminal blocks. One other possible option is develop in LabVIEW, then compile to VHDL, then burning that to your generic FPGA card. I've never done this and am unsure if it can be done. I assume at some point the compiled VHDL code is available but you will probably have a difficult time properly addressing hardware IO on a different FPGA.

This is true but one work around is to set the buffer size of the channel before writing the first time. This will allow you to use the write function several times without it needing to actually write to disk, which means it will not need to write the XML header. The down side is the data is not actually written to disk, and if power is removed from the PC then your buffer is lost. For this reason I try to make my buffer size appropriate, so I'm not writing XML header data all the time, but I also don't have a buffer so large that I don't write all the data at once (unless that is desired). http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/setting_tdms_buffersize/