hooovahh

I don't remember seeing this thread but I can see why some would oppose it. We are all here to help others (as well as learn) and setting the bar (even a low one) may hinder others from finding useful information, or from teaching others. In the end I guess I wouldn't be against adding some CLAD level question.

According to the the help, the "/c" adds the following "Carries out the command specified by string and then terminates". If I run cmd, then type in "Copy ab.txt cd.txt" it will perform the copy and the command prompt window will remain open. By performing a "cmd /c" it will cause the "cmd.exe" to close after the operation is complete.

If you perform the steps needed to print to PDF without using LabVIEW do you get the same result? If so then this is a problem with the program doing the conversion, not with LabVIEW which is just calling the conversion to happen. There are multiple print to PDF programs, I would try one that works on its own before trying to automate it with LabVIEW.

Oh I just thought of one. Lets say I have three case structures aligned vertically. Why is there not a "Minimum Size" or "Maximum Size" like there is for front panel objects? I have these 3 case structures, all doing similar work in parallel, and I want them to align left, space equally vertically, and have the same size. The only satisfying thing to do, is to set one the way I like then copy and paste it so all 3 are the same size.

Very neat but my CTRL+W is reserved for something else that I've been using and loving, which may one day become part of LabVIEW. https://decibel.ni.com/content/docs/DOC-29452

I've done that on the front panel. Say I have a hidden tab that I programatically change, but when it changes I want the controls that are between tabs to be in the same location so the change from one tab to the next looks seamless. Never on a BD.

You don't triple click? I do it quite often. I colleagues of mine once told me a story of trying to help his neighbor get some files off of a USB stick. This guy didn't have a lot of experience with computers. So he went over and plugged in the stick and showed him the files and how to navigate Windows Explorer. He then said you right click the file an choose Copy. The neighbor quickly snapped back "Oh I don't right click, is there another way?". He told me this story as if it was the guys religious preference or something that it would go against his moral code to right click. Accept the new doctrine of triple click my friend.

The other alternative I noticed (thanks Darren for looking into this by the way) is to change the OpenG VI Window Title name to be "Wait (ms) OpenG". It appears Quick Drop will find the VI name, but use the Window Title as the text to find it if one exists. This is why "Wait (ms)" for OpenG comes up, but the primitive "Wait (ms)" (with no .vi file extension because it is a primitive)

No this just hides the problem (but I understand the urge). Bends must happen in LabVIEW, and the style guide must mentions unnecessary wire bends. This bend is necessary. I choose the error wire be straight first.

I... ...I'm not sure he would mind.

I said "dated in development style". Controls/indicators with white labels, not transparent, labels on top of the controls not to the side, classic controls including error, VIs not inlined that can be. The tools themselves are quite useful and in my opinion should have effort to update the API to have other functions as well.

As time goes on this "Windows API" becomes less useful and more dated in the development style, but I still find uses for it. http://zone.ni.com/devzone/cda/epd/p/id/4935 It has a subVI making a window front most given a HWND. Now getting the HWND of a VI is a simple property node away, no longer do you need to rely on the window title. http://lavag.org/topic/13803-getting-the-window-handle-for-a-fp-with-no-title-bar/

You obviously are in a better position to rate LabVIEW versions for stability over the years. Your intimate knowledge of low level development, and CARs is invaluable. And as years pass my memory of why I feel a way about a version becomes less clear. Also I never meant to go off topic, really I just wanted to say that I hope 2013 is the most rock solid version yet, but if it isn't my fall back would be 2011, simply because for me I've used it on more projects then 2012, which we only started using on real projects since SP1 about 6 months ago.

Yeah I didn't know how far back to go. I didn't use 5.x, and 6.x much but from what I remember it followed my semi-pattern. 5.0 - Stable 6.0 - Not Stable 6.1 - Stable Don't ask me to go back farther. You know my projects have alot of CAN/XNet stuff it could be the driver I guess.

I have a problem where basically all versions of LabVIEW will crash on exit occasionally. 2013 is no different. I suspect it is a system setup rather then a stability/instability of LabVIEW. Traditionally NI (intentional or not) skips a version when it comes to stability in my opinion. There are exceptions to the rule. This list is just my experience and you're welcome to disagree. 7.0 - Not Stable 7.1 - Stable 8.0 - Not Stable 8.2 - Stable 8.5 - Not Stable 8.6 - Not Stable 2009 - Stable 2010 - Not Stable 2011 - Stable 2012 - Stable 2013 - TBD Is there a rule about software releases where every other version is good? I feel like Windows follows this same rule.

It is? Well then there should be no reason to not put it on the palette right

Maybe that's it, maybe they used the High Resolution Relative Seconds to get a more accurate time? Most likely this is not the fix because I think the high resolution time is Windows only which is why it isn't on the palette yet (just speculation).

I've seen something similar with TDMS and Copy. I have a test running where we log to TDMS. Then we close the file at the end, then copy it and the index file to a duplicate location. Many times I would get an error 10 "Duplicate Path" "Asynchronous I/O Operation In Progress". So I would put the copy function in a for to retry a couple times and we no longer have this problem. I never determined the cause, and didn't have time to debug it because a solution was found.

I just tested the VI attached by AQ in the first post in LabVIEW 2013. I clicked Trigger about 20 times, and every time the user event was handled first, and the array showed 0, 1, 2. It does look like this is fixed. I do wonder however, what other event based bugs will be seen now that 2013 had this major overhaul. I don't believe there must be new bugs, but it looks like there was quite a few changes, and I'm sure a lot of testing went into it, but when upgrading legacy programs I wonder what unexpected results may occur.

So a couple things. If you have a professional version of VIPM on your laptop you can create a VIPC file that contains multiple packages. This will create a single file that can be double clicked on any computer without the internet and it will install all the packages just as if you got them from the internet. If you don't have the professional version of VIPM you can still copy the individual package files from your laptop and bring them over. Go to C:ProgramDataJKIVIPMcache to find all the packages that have been locally downloaded. This path is for Windows 7 and maybe slightly different for other OSs. You can then install these package files on your other PC by going to File >> Open Package File(s) and selecting all the files at once.

I can't help but get excited. Because everything this guy talks about resonates with what NI has been trying to do with LabVIEW. Also the fact that people rejected Fortran made me smile a little. Because the same type of people, will reject LabVIEW for similar reasons. Not that I can't be suborn at times. I still don't use the auto-tool.

I started calling myself LabVIEW Overlord as a joke, because people throw around the term Guru all the time. Only now it sound pretensions when someone introduces me as the LabVIEW Overlord. Also someone may take that as me pretending I'm better then a NI Knight, which wasn't the intent either. Lets not be rational here. We can all agree it is NI's fault and I demand they fix it. Can't they just have 6.4 pixels per terminal?

I agree. I have found myself developing a tools menu item, and then changing it to a quick drop item instead. When developing I find two shortcut combos is faster then navigating the tools menu. Especially on a system where the items and order of the things in the tools menu potentially changes after installing something from VIPM.

I'm no quick drop expert but this is how I'd do it. Say CTRL+Space then CTRL+C (maybe that is semi-reserved) this brings up a new dialog window that shows the options, and you pick the one you want which then adds the code to the block diagram. Closing this window does nothing, and calling another CTRL+C brings this window back to the front with new settings if it was never closed before. Not ideal no but I think it could be used this way.

I forgot about this. But usually to highlight this I will color the background a different color, or bold the font. I don't think either of these change the cell height.