hooovahh

It seems the opened VI couldn't find the dependencies where it thought they should be. This is probably because the dependencies, or the main VI have been moved on disk in explorer, since they were last saved. The paths to the dependencies are relative and moving them in reference to each other can cause that to happen. If you are new to LabVIEW there is some free training here. NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 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

You selected a function not a terminal. What kind of control would you suggest it make? Right click a terminal (one of the inputs or outputs of a subVI) and then create the control/indicator/constant from that and it will make it for that data type. Same with a selected wire.

Okay fine, let me try this again. Those that I've spoken to on the subject find my implementation cleaner and easier to follow. If your opinion does not align with that statement then you are dumb. That being said my implementation could benefit from some classes for sure, and I looked into once but never finished the re-write. Oh and there are some CLNs that could simplify my code too, rather than parsing blocks manually.

Don't expect anything too mind blowing, it's basically all stuff you can research on your own, with a few added breakdowns, and experiences.

I would not consider VI Explorer well written. It is written by someone who is clearly an expert at other programming languages, but not LabVIEW. That isn't to say I don't appreciate their work just that I found my implementation cleaner and easier to follow. Of course my implementation doesn't show how to replace passwords, posting that publicly would cross a line in my mind. Looking at the VI file structure as an exercise in pulling data out without involving VI Server is a useful tool. Glad to hear you were able to independently reverse the VI file structure. I always assumed that the original writer had some internal knowledge at NI to accomplish what he did, but now I realize how that doesn't necessarily have to be the case.

Sorry I misread your opening paragraph to say it worked with a Strict type, but not a normal type def. There is a private method for a VI class type, for Synchronize In All Contexts, not sure if this can be applied to the control VI and have it work or not. Synchronize Private Method.vi

Unless I'm misunderstanding something, the type def is doing just what it should and not updating unless the data type of the control changes. If you are only replacing the pictures in a boolean, but not the actual data type, then an update won't be forced on the instances of the control. Only a Strict Type Def will apply changes to all instances of the control, even if a cosmetic change is made.

All I can say is you're not crazy, and there probably isn't anything we can do about this. I modified your OnDoubleClick2 in the hopes that adding a cancel output, which would then not add any states (like get terminals and redraw), but as you stated the dirty dot appears even if you don't add those states. Next I looked at the VI property Modifications >> Block Diagram Mods Bitset, this tells you what on the block diagram is unsaved. If the value is 0 then there are no unsaved changes. This value is still 0 when the OnDoubleClick2 VI is ran, so the bit is being set after the OnDoubleClick is done running, which to me means there isn't really anything we can do about it. The second time I double click the XNodes it does have a non zero value, meaning it is reading the bit sets on the calling VI. But even if we were able to clear those bits indicating a modification was made, those bits aren't set until after the VI runs. Oh and another thing I checked was maybe in newer versions of LabVIEW there was an OnDoubleClick3 which fixes this, but in 2015 there isn't.

Welcome. Yeah feel free to post your projects. I too would encourage you to post them in the actual Code Repository if they are in a decent state instead of In Development. Bother are fine places but I've found posting in the In Development does get messy, with attachments and updates from users and the original poster. Posting in the Code Repository will have a discussion where this can still take place, but the first post will always take you to the main page where you can download the newest official release, and any previous official releases. Rather than having someone read multiple pages of a discussion trying to find the newest version.

Asking questions isn't the problem, there is tons of stuff I don't know about LabVIEW and I've been doing it for some time now, I still ask questions. The problem is some times we ask questions in the wrong way, and that will either bring out the wrong answer, or the wrong attitude from other members. I'm sure Jordan didn't mean to mock you, but sending someone a private message for something that is better discussed publicly is something to be avoided. I'm glad to hear you are passionate about LabVIEW, many of us here are. This document lives on another LabVIEW forum, but I think many of the points are valid here, feel free to read up on what most communities consider good etiquette https://decibel.ni.com/content/docs/DOC-40451

I'm going to try to summarize what your code is doing. On value change it will read the number of items in your listbox then run a for loop that many times. In that for loop you are setting the symbols each time, but the value doesn't change, and you are only setting one symbol, so you are turning off all the other symbols. This is because the array size is always going to be 1. If you want to set a symbol for every item, then you need to set the Symbols, with an array, whos size is the same as the number of items, right now the size of the array going into the Item Symbols property is always 1, so you are always going to only set one item to have a symbol. Attached is a new version where on value change it creates an array of the same size as the number of items, and then sets the symbols for all items using that array. Are you interested in any free training for LabVIEW? Here are a few links that I think might help you. NI Learning Center NI Getting Started -Hardware Basics -MyRIO Project Essentials Guide (lots of good simple circuits with links to youtube demonstrations) -LabVEW Basics -DAQ Application Tutorials -cRIO Developer's Guide Learn NI Training Resource Videos 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 These links come from another document that I just linked to in a different thread. Automatic symbol for items Hooovahh Edit.vi

I've used DIAdem in the past, and it is quite flexible with data formats. It supports several kinds, and then plugins can be made to support more, but with no additional plugins it works well with some Excel formats, and TDMS. I know ATML works with a plugin, which is great for TestStand outputs. That being said I have rolled my own (sorta) using the DataFinder toolkit and TDMS files. You just point DataFinder to a folder of files to index, then you can perform queries with the LabVIEW API. I made a neat interface and put it on a server so people could login and perform a search based on criteria they wanted. Like the test completed after this date, ran by this user, on this tester, in this nest location, and passed. Then my program could perform a basis Gage R&R showing how values changed between reports that met that criteria.

Have you never used a forum on the internet before? Go to lavag.org, click on the subforum most applicable, then click Start New Topic.

This post is 7 years old, and has nothing to do with the original question. The answer is to just use a property node and read the Item Names, then use the Array Size, but in the future make a new thread for your new question.

Please don't double post, I've removed the other thread. What you are looking for is the System Exec.vi. Search the palette for it. http://zone.ni.com/reference/en-XX/help/371361K-01/glang/system_exec/

So I got confirmation today that those who need to know about this issue, are aware of it. At this moment it sounds like efforts will be made (eventually) to bring it back.

Here is an article I read a while ago describing the ghost patterns, before reading it I always though the 4 ghosts just chased you randomly. http://gameinternals.com/post/2072558330/understanding-pac-man-ghost-behavior

I'd like to think us at LAVA are better than Apple, Google, and Microsoft...okay maybe not better but something.

Hey sorry if I came across a bit strong. The only time we generally get things posted here that are compiled binaries, its usually spam with some DLL to perform stuff on barcode scanners, and OCR for some reason. I haven't looked through the source much yet, but I saw a few cool things. Like embedding the audio in the VI, sure it makes it a bit larger but the sound effects were small enough, and I like using a 2D picture control that gets redrawn. I love using the picture control in ways that maybe aren't intuitive but make for a neat UI. An alternative might be involving showing and hiding objects, or even moving objects like a button that looks like a pac man around the front panel. Oh and I noticed you Exit LabVIEW when the VI stops running. A better solution might be to see if the VI is in an EXE and then exit if it is, or do nothing if it isn't. This way if you run from source when the VI stops running LabVIEW is still open. Also I do hope that no one abuses your source and posts a high score of 2^32 or something. And as for the FTP credentials, LabVIEW VIs can have password protected block diagrams, but according to NI R&D it is far less secure than you probably know. I believe the quote had something to the effect that the amount of protection the block diagram password gives you, is similar to the amount of protection you get from tissue paper. There are multiple ways to defeat this password protection, and it would give your online credentials to your FTP, to anyone who can defeat this tissue paper. Not sure if there would be a good way around this, since if you just posted a VI with no block diagram, we would be back to square one where you would have a binary blob that is doing unknown things on our system.

Run and download a random EXE from a random site, which reportedly uploads data to a central location? No thanks. But if you are willing to post the source you should, either here or possibly in the code repository.

I've seen others try to add more features to an error handing system, and embed the NI error cluster into a class, or another cluster, which can have more information like history, and more debug information. There is a lot of information on the topic. https://lavag.org/topic/10741-updating-the-labview-error-handling-core/ You can go too far one way, or the other. I mean even NI's error handling cluster could be reduced to just a boolean, Error or No Error. I think doing that goes too far and the cluster and all that goes with it, is justified by the added functionality. But I'm guessing that when the error cluster was made standard (LabVIEW 5? 3?) some thought it was more complicated than necessary, and a single boolean, or single integer would be enough. Or you could add tons of functionality and add lot of overhead, to the point that it wouldn't be worth the effort. In larger applications I generally wrap more functionality into the NI implementation by using a central error handler that keeps track of the errors, severity (which is hardly ever used), time of the error, module that it originated from, and the last 4 states the state machine went to leading up to the error. This is also logged to a temp location. So while I do use the simple error handler in smaller programs, the ones involving actors running in parallel get their own error actor.

For those more curious here is an article talking about the root loop and how the one button dialog can block an open VI reference call. http://www.labviewcraftsmen.com/blog/the-root-loop

You're welcome to do what you want with your contribution to the community, but I generally recommend code be posted in the Code Repository here on LAVA. This has version tracking, it generates a new thread for submitted code, so user discussion can be linked to the code posted, and a few other benefits like download number tracking, etc. Generally you post it as uncertified then if interest level (and time) permit it is updated to certified. Here's another link on how to submit code. https://lavag.org/topic/10351-how-to-submit-code-to-the-code-repository/ https://lavag.org/topic/10350-how-does-the-code-repository-work/

I think this might be the missing VI, it is in VI.lib and just converts row and column values into strings that the ActiveX function uses to form a cell like A1 <LabVIEW Install Director>\vi.lib\addons\_office\_exclsub.llb\Row Col To Range.vi The other missing VIs just relate to the ActiveX reference, which you can get using the Excel Get ActiveX Reference in the report generation palette.

Yes SCC is a must. In my opinion LabVIEW works best with the Lock, Commit paradigm instead of the Commit Merge. Basically the concept is that you talk to a central server and that server only allows a file to be edited by one user at a time and can't be edited by anyone else until that user is done with that file. SVN for me has been a pretty good fit for that type of work flow, and using tortoiseSVN is the most convenient way of doing that. That being said Perforce, along with a plugin allows for explorer integration. I only used Mercurial once, I was under the impression it was a merge paradigm. After SCC I'd say some kind of code review process. Have your best developer or two champion a pilot program where you run the VI analyzer on someones code, and then discuss the improvements it suggests. These developers should know the difference between perfect code in the eyes of VI Analyzer, and code that is acceptable. By that I mean ignore the errors that can be justified. That will help with some kind of standardization of code, and help train newer engineers with techniques they should be trying to use. After some time you'll notice each user will start to develop their own collection of coding nuggets. VIs they commonly use that do some task well and has been tested on several projects. After you see some ad-hoc code sharing taking place you should think about a formalized reuse library. At first you want to make it as informal as possible to encourage usage and collaboration, while not being so loose that code quality falls. VIPM is a great tool for this and honestly the only way I would want to implement a LabVIEW reuse library. You can do a bunch with the free version but pro might be needed for a few developers, or everyone depending on your usage. Virtual Machines might come next. A sandbox environment that can isolate projects from one another in a way that ensures no accidental saving of a LabVIEW 2009 in in 2015, or using DAQmx 15 on a project that hasn't been tested with those drivers. Just like reuse you can start with a basic setup with just a VM with each version of LabVIEW, or a VM for each project. There are also tons of advanced tools taking snapshots of projects keeping file size to a minimum. VMs are optional of course, but then again so is SCC to some. Depending on your needs you'll want formal documentation, and this may come at any time. A requirements document stating what the software should do, a design document made before coding begins and is updated as the design changes, and possible test documents showing that the code you wrote was what you wanted, and that the software does what it was required to. There's lots of other harder to quantify things like a good mentoring environment, clear leaders in the company like a Chief Software Architect who can plan long term goals, encouraging going to local user groups or other training opportunities, etc.