Yair

I don't expect that this would help, but it could be worth a try - go into the WindowsPrefetch folder and muck about. Delete the relevant file. Delete all files. Go crazy (actually, scratch that. You should probably not go crazy, and you probably also want to be careful. My understanding is that nothing bad will happen if you delete stuff there, but I'm not a Windows expert by any stretch of the imagination). I have no reason to believe this will help, but it's the only mechanism I can think of which is affected by the EXE name, and maybe it caches some kind of dependency which screws things up? You might want to keep the original file so that it can be analyzed.

Yeah, well, no system is perfect. Just to be clear, the point wasn't to be a snob and say "I only want CLAs here". The point was to say "you have to be this tall to go on the ride", meaning have at least a basic understanding of LV. The questions wouldn't require a brain the size of a planet to answer.

I can't answer the second question, since I don't use Linux or IMAQ (although I would suggest using a license other than GPL if possible, such as BSD), but I can answer the first question with "yes" - there are absolutely no restriction on which code you post here, as long as it's your own code. You can post tools, demos, ideas, experiments or just ask questions. Certainly any tool is welcome. If you want to add the tool to the LAVA code repository or the LV tools network there are some rules you have to follow, and those are documented in the relevant places. I'm fairly sure that code insanity isn't one of those requirements, though .

I tried suggesting something like this some years back to "keep out the riff-raff" and let the As in LAVA have at least some semblance of meaning. The suggestion wasn't met with too much enthusiasm.

I think that "mark reply as solution" or "mark this as the solution" are reasonable (the second is clearer but longer).

I noticed that recently LAVA added a feature where people can mark posts as solutions, but I also noticed that too often posts which are clearly not the solution are marked as the solution and while I don't really care about the actual result, that just bothered my inner UX designer enough to go and look at one of my own threads to see why this happens. It turns out that on your threads every reply now has a button with a check box icon that says "Mark Solved". I think the problem is that people don't realize that the button refers to a specific reply and simply click it to say "sure, it's solved". This could probably be made better by changing the text to "mark as solution" or "mark this as the solution". Michael, is this a change you can make on your own or is it something built into the IPB code? I see that the text is plain HTML.

Here's something ironic - I liked this post in the hope that it will make it easier for me to remember this in the future, but when someone came to me with a similar problem recently (it might have actually been before this thread started) I didn't make the connection (although, to be fair, the problem there appears rarely and I had a DLL which returns a 1097 error to suspect. In fact, I still suspect it and will need to find the source of that error regardless of the UI issue). I asked the user now to change the theme and I will see if it helps. Maybe posting this reply will help me remember it better for the next time. In case it helps with diagnosing the problem, I can say that in my case the UI only fails to responds to user input and that it always happens in the same VI. The VI itself and the rest of the code keep running (which I can see because I put a loop iteration indicator on the panel and because the VI still updates the display based on stuff which happens elsewhere in the code and isn't controlled by pressing the screen).

Yeah, there are a bunch of these users in the past few months both here and in the NI forums (although NI has deleted all of them the last time I looked. The LAVA mods haven't, from what I can see). As far as I'm concerned, this is pure spam. These people seem to be pretending to be regular users and pointing to different sites which are probably all owned by the same company (although a whois search doesn't seem to yield any actual results). The one I liked the most was when one of those users started a new thread just so that one of the other users can reply to it.

Some options: Lock the class so that only people you trust can edit it. Add a VI analyzer test that checks that each element in the cluster is only bundled/unbundled in a single VI. Encrypt the data in the cluster and put the encryption/decryption code in your locked VIs. I'm going to assume you're not going to use this one. Assuming there are no bugs or performance issues with the property node call, I think the answer to this is very simple: if the VI has more than one input/output, you call the VI, because you can't use the node. Otherwise, it's a matter of taste and personal preference. You would probably call the node if you want to do a direct DVR access or if you want to serialize calls. I often use the node if I don't want to create icons for the VIs and that API isn't one that needs them. Personally, for VIs which have properties, I almost always use the node.

Use a simple shared counter which every event must go through?

I haven't tested this, but according to what I heard Craig say in the video of Jack's presentation on events, this should no longer happen in LV 2013. I guess as part of the work done on events this was changed as well (for AQ's sake I'm avoiding the term "fixed").

If you're talking about the knob eyeballs, someone did ask about it later on the NI forums and proper answers were posted, although, like I said, I think that under the constraints of a speed coding challenge, the actual submissions were close enough to the rules to be acceptable. Here are a couple of the ones which are worth opening. Mine got Darren to endorse it as "creepy". You can't do much better: http://forums.ni.com/t5/LabVIEW/Knob-Eyeballs/m-p/2523334#M766596 http://forums.ni.com/t5/LabVIEW/Knob-Eyeballs/m-p/2522728#M766458

Some relevant links: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-Intellisense-support-to-the-property-node/idi-p/1540954 http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Quick-Access-to-a-LVOOP-Class-Library-via-the-Right-Click-Menu/idi-p/2256860 https://decibel.ni.com/content/docs/DOC-6771 I don't know if the last one has a QD replacement.

It's not. Those objects are part of the front panel window, but any definition of the FP in LV (such as in the various properties for the FP bounds) refers only to the actual edit area, not to the title, menus and toolbar. If you want, you could make an argument about the scrollbars and pane splitters, but I think that's just a matter of semantics. In general, I think that there needs to be some leeway about the interpretation of the rules (although obviously it should be limited) and that certainly seems to be the case. Like Rob said, the 100 random number challenge has already been given in a slightly different form, and even though this year it would be a little farther from the rules than it was last time, I would still have suggested the same solution I did back then - a for loop running 100 times with rnd+3 and auto indexing - it would generate 100 numbers between 1-5, but not between 2-2.99.

I have something similar to Tim's example on an FPGA - there are 64 DIs which are used as counters, so there's a reentrant VI which takes in a boolean and increments a counter in a feedback node each time the boolean changes to true. That VI is called 8 times in parallel in a reentrant "port VI" and the port VI is called 8 times in parallel for a total of 64. The results are then combined. I didn't work on this directly, so I have no idea how this compares to Tim's version (although I'm assuming it's not as efficient), but that gives another version of this type of code duplication. As for the previous example I mentioned, AQ got a cleaned up version of the code. The rest of you will have to manage without.

I have something in mind - There are three flurbs, each with a few pages worth of code, all in the same VI (they're actually called in sequence). The flurbs are similar, so the code for them is similar, but the code has many constants which are different for each flurb, as well as some actual differences in code, some of which are quite significant (to the degree of "the first half of the flurb is similar, but the second half has mutated and now has four arms"). For ease of coding, understanding and debugging, the code for the flurbs is duplicated rather than handled using other means, but that means that every change which affects all of them has to be made to all of them separately. Is that the kind of thing you were thinking of? I'm curious as to what mechanisms NI has in mind which can help with such code.

Hmmm...

Just to be clear - there are already good existing solutions. You should probably just use them. The OpenG variant config VIs which AQ mentioned are great. You should see them in the list of packages after you install VIPM. The MGI VIs he linked to are also good. I haven't tried the XML variety, but the INI ones work basically the same as the OpenG VIs, with the main functional difference being that they reset everything in the file each time, where the OpenG VIs can work on existing files and only change parts of them. Both of them basically work by name - if something doesn't already exist in the saved file, they will use the default value for it. Besides AQ's experiment, LVOOP already has this magically - it keeps the change history for each class, so you can flatten a class of version X and then unflatten it when the version is X+4 and it should know automatically how to do the conversion. I'm assuming the main reason AQ didn't suggest this is that it has some issues like resetting the history if you rename the class or being completely opaque.

OK, after a month I can say I'm pretty happy with my choice. The developer regularly and officially handles feature requests (there's a change log) and I can say that almost all of the issues I mentioned in the previous reply have already been resolved and it now has some good features which Reader didn't have. If someone else needs an RSS reader I would certainly recommend it. Just make sure you go into the settings and configure it to your liking, because some of the defaults definitely didn't match what I like.

Completely off topic, but I also sometimes go oldskool, and it can be much faster than using the UI, if you know some tricks. Tell her that if you use Tab (and Shift+Tab), the command prompt will iterate through the folders and files in the current folder (so if you're in C:, you could type "CD pr" and then tab and it should auto-complete to "Program Files" and keep iterating through the rest). That can be a great time saver when using the command prompt. She could also create batch files and place them in a folder which is listed in the path environment variable to have immediate access for common operations. For example, I have a 1.bat file somewhere that simply calls "explorer .", so if I type 1 and Enter, it immediately opens an Explorer window in that folder.

Try this - http://forums.ni.com/t5/LabVIEW/Why-does-my-LabVIEW-occasionally-display-in-Chinese/m-p/1545242#M571786

Yeah, for some reason these guys seem to spamming both LAVA and the NI forums recently with these supposedly authentic and off the street one-time posters who point to different sites which look similar, but all offer barcode utilities for pay.

Someone clearly isn't following LAVA as closely as he's supposed to - http://lavag.org/topic/16444-new-programming-language-vigil/ Of course, LV itself is already pretty strict, with the exception of that one pesky feature which will freely change wire types automatically and actually decide *at run-time* to run a completely different function from the one that's actually on the diagram. Maybe that feature set should be removed from the language.

Right click the string constant, change its display to hex mode, then type FF into it. This will create a string of length 1, where all bits are 1.

A quick test seems to indicate that this was resolved in a later version of the CCT. I didn't dig into what was actually going on, but I saw the problem in one LV version with an older version of the CCT and I didn't see it on LV versions with the newest version from the tools network (3.2.1).