hooovahh

If this is true it is a shame. The snippet tool is very neat. Not as neat at CCT but it ships with LabVIEW so you know it is already there. In any case here is some more information on the snippet tool. http://www.ni.com/white-paper/9330/en/

Altenbach has a version, MGI has a version, and I've seen several other implementations of it. There also exists a primitive in LabVIEW that isn't on the palette that does this, but several NI employees have said it is not stable and not to use it.

You gave very little details on what you actually want. At face value I could suggest copying a picture to the front panel and that would satisfy your request. But this obviously isn't what you want. Creating interacting objects as an image in LabVIEW can be done several ways. Look on the Graphics and Sound >> Picture Functions. Here you can draw things into a 2D picture control. IMAQ also has various image tools too.

Yup. The NI installer is kinda limited. So I usually wrap the NI install, into an Inno Setup installer for when I need more cusomization. This can do things like have Full, or Custom installs, and of course installation location control. I usually use ISTool to make, making one of these easier.

I have sent Michael a message. I don't have the ability to add this.

What about reading the mouse pointer? If it is a ][ or what ever symbol then don't discard, and don't sort.

I don't have the link, but I remember someone else telling me that you can choose the INI file to use, in a command line switch. This forces LabVIEW.exe to use a different INI file somewhere else on disk. You could have a batch file that launches LabVIEW.exe with an alternate INI this way too. I've never tried this so sorry if this is incorrect information.

Yeah sorry. I read your post several times and couldn't tell if you knew of the function or not. I know of no way to set this path to the current project. There are likely ways to do this programatically. I assume this information is just stored in the LabVIEW.ini. That INI could be updated. Not sure if it can be done on opening a project, but if it can I suspect that the Project Provider Framework could do it. Yeah sorry. I read your post several times and couldn't tell if you knew of the function or not. I know of no way to set this path to the current project. There are likely ways to do this programatically. I assume this information is just stored in the LabVIEW.ini. That INI could be updated. Not sure if it can be done on opening a project, but if it can I suspect that the Project Provider Framework could do it.

Sure you can add or change LabVIEW search paths. Open LabVIEW and go to Tools >> Options >> Paths, be sure and uncheck Use Default. I've never had to really change this because it would search for missing VIs relative to where they used to be so as long as the file structure was duplicated it worked fine.

XLoader can be used to load HEX files to arduinos over serial. This likely uses a stripped down version of AVRdude and that is a command line program that could be used from LabVIEW.

Is it possible to copy the VI from a previous version, rename it to "Open File in Default Program" and then use it in 2014?

One thing that might help as a start, is the fact that the ECU Measurement and Calibration toolkit has an example for programming an ECU using an S file or HEX file. Now the actual data going down is specific to the device and interface being used. But the example shows how to parse a HEX or S file into an array of chunks to be sent down. This toolkit is not free, but if you install the trial, these VIs are part of the example, and parsing the HEX file can be done without needing a license. The license in this case allows you to program an ECU over a CAN interface.

I have no incite on this function changing or not. But what I do have is the function I use for opening files, or opening explorer windows with that file selected. It just uses a command line call to explorer. Open File Or Windows Explorer.vi

I must say, reading this whole thread all at once for the first time causes a roller coaster of emotions.

What you are looking at is an empty array. If you want to add data, to any array the data must be added at the front, at the end, or inserted in between existing values in the array. Since you have no existing values in the array, then you can only add values to the front or the end, and both are the same again since the array is empty. Without knowing more about what you actually want my suggestions may not be appropriate. One suggestion is to just have an array constant with your data in it. But if you are replacing data this might not be what you want. Also you may want to initialize an array with some size and then replace elements in the array. But again if that isn't what you want, then it won't be of any help. In any case the functions you'll want are under the Array palette, checkout Build Array, Insert, Delete, and Initialize array. If you are interested in some free training check out some of these links. Otherwise try using some of the functions mentioned and post some code of what you've tried. NI Learning Center NI Getting Started -Hardware Basics -LabVEW Basics -DAQ Application Tutorials 3 Hour LabVIEW Introduction 6 Hour LabVIEW Introduction Self Paced training for students Self Paced training beginner to advanced, SSP Required LabVIEW Wiki on Training

Yup this is a big one for me. Our internal spin on Actor doesn't have the issue of launching and destroying actors. Just calling all the actors in parallel just like you would any other subVI. Then debugging tools, and techniques don't need to change. You always have the same number of actors running, and getting references to them or knowing their state is quite easy from run-time or development.

You can formally request topic moderation by using the Report to Moderator button. But in this case I would rather we leave the topic as is. Even if your issue was solved, others may look for help on this subject, and finding what you have already done helps the community.

Wow, okay well you are opening that serial port over and over again as fast as Windows will allow. Now luckily the resource will be locked and you will generate an error the second time that loop runs. Unfortunately you aren't looking at the error, and the error isn't stopping your loop so you won't know there is an error until you stop it your self. Go to the Help >> Find Examples and search for Serial. In newer versions of LabVIEW the example is called Continuous Serial Write and Read. Older ones had a similar example but it has been re-written. This should perform basic serial I/O and assuming it works, you can takes pieces out and make your own application with it.

Yup Brown is private, Blue is scripting, Pink is deprecated.

I'm sure you have it in a specific format, but if you want to go with the ISO standard for having time as a string. http://lavag.org/topic/15034-timestamp-support-for-format-into-string-scan-variant-from-string-string-package/#entry90605

It does depend, but generally I read the event data in the event structure, and in it some information says what case in the state machine it needs to go to. There it can perform the steps, or go to other states in the state machine to do the steps, associated with the event requested to be done. After the QMH states are empty it comes back around to the event structure, to look for user events (or other events) to perform that may or may not have been generated while it was performing the Do steps from the last event. Events are a lossless queue (for the most part) and so I don't really see a need to pull event requests, just to send them to another loop when they could just be handled in that loop, and have the events pile up. Assuming events can be handled as fast as they are added. But even if they couldn't, sending it to another loop wouldn't fix that. Of course in 2013 there are new tools to detect if events have piled up to the point that there isn't hope of processing them fast enough. A pros and cons list might be based on how it is implemented, and how it is used. I list a con, but that might be contingent on the fact that the architecture is used in a certain way. I think this would be a good subject to discuss either here or the dark side.

Correct. You can't set the behavior of locking or not locking the front panel from a user event. If you wired a control reference to the register for events, and picked something like Mouse Enter then you can right click and choose to lock or not the front panel. As for a user event locking the front panel. I've never had this be a problem because very little happens in the event structure. For me the event structure is in a state machine, and after getting an event will go and o what it needs to. During this time the UI is no longer locked and will respond. So one solution is to make the code in the event structure very minimal so it locks the UI but only for a fraction of a millisecond.

Oh sorry I was confused. If the selected object is under the class "Node" then you can use the property node to read the terminals on it. Then for each terminal you can find the wire. Have you looked at the other shipped QuickDrop functions? It helps to see how others have done similar tasks if you haven't already.

Use the Traverse for GObjects function on the palette. Provide it a reference to the VI and tell it to search on the block diagram. As for the class to search for enter "Wire". It will return all the references of that class type on the block diagram but it will be returned on generic GObjects. You'll need to use the "More Specific Class" to turn it into a wire reference.

On each terminal you can use the "Is Source" property node and it will tell you if it is the source, or sink of a wire. By the way I believe index 0 is always a source and the last element is always a sink.