Neil Pate

Hi Tim, I have already cloned the repository, I just wanted to be polite before pushing back my changes. There is actually logic checking the dependency cache, its just before the case structure. If the attribute lookup is not found then it is added, this is how items get in the cache. At the moment I am totally snowed in with work, so I do not think I will get time for several weeks (probably longer) to tinker with this anymore. Unfortunately for the project I was going to use it in has several thousand VIs and performance with this is just a bit too slow, so I ended up writing my own for my particular use case. I am most interested in being able to interact with clone VIs, so I used the FGV method and add the VI names to a cache when they are launched. This works really very well for my application, so is probably about as far as I need to take it for now.

Joe, I was able to fix my issue by re-creating the single VI that was not working properly. Thankfully I have only seen this issue on one occasion, but now several others have also reported very similar problems. This is not a very satisfying situation where you no longer have faith that the code is actually going to do what you tell it to do...

Sorry Chris, never got the the bottom of it. I am glad I had read this thread before it happened to me as otherwise I would have thought I was going crazy! I have a suspicion (based only on a tiny bit of evidence) that the problems arise when renaming class VIs. I am pedantic about having the VI name match what the VI is actually doing, so will often rename a VI as my code/API iterates. Now normally this does not cause any problems, however I have seen instability when I rename a VI to something that a different VI used to be called. It's like there is some form of stale code path somewhere that gets invoked. I did not try cleaning out my VI Object cache, that may have helped... Also, in the past (LV2011) I had some success with a crashing class by erasing the class mutation history. Again I did not try this this time as it was just quicker to recreate the offending VI from scratch and move on.

I usually unbundle and then rebundle. It depends... sometimes I do but it depends on how deep in the call hierarchy the code exists in. If I have a Manager type class then I normally like to not expose the inner working (i.e. private classes) so that the "Block" class never actually gets exposed to the outside world, i.e. there is no get/set "Block" accessor in Executive Functionality. This can be a pain though as it often feels like you are writing the same method for various levels of the hierarchy.

Yeah I also think something is fishy. I know Registry IO is cheap, but I would prefer it not to be going on all the time. Perhaps will try and re-install/repair the License Manager

Didn't know about that option in the LM! Just checked it, and mine is blank (as I would expect as this PC has never been part of a volume license scheme). Hmmm....

Just curious, does anybody know why LabVIEW.exe is querying some Flexlm License Manager registry keys (which do not even exist on my PC) very regularly? See attached picture.

Hi all, If I get time I would like to refactor "Get All VIs in Memory.." that and its parent VI to remove a lot of the duplicate operations and array manipulations. For now though an easy performance boost is to cache the VI Dependencies. I have used variant attributes as a quick and dirty cache, as shown. I get approx 50% speedup for large projects (> 2500 VIs). With a bit of thought I am sure it can also be applied to the other temporary arrays that are used in this VI. Comments? The VI attached is saved in 2013. Get All VIs in Memory Including statically-referenced Reentrant Clones.vi

Today I learned you can pass an I32 into the To Upper Case prim. Did this totally by accident. Has anybody ever used this feature before?

I always put File-->Exit on every application that has a menu-bar, however my personal preference (as others have also said) these days is to handle the Panel close event so I put in both. To me the only no-no is a big fat Exit button on the GUI.

Have you tried running the executable on your PC but with the source directory renamed to something else? This can help diagnose if some VIs/classes etc are not being included in the exe but are on your disk so the built application works fine. Also try move the exe somewhere else (on your PC) as if the application has relative paths to source code VIs it should then fail.

OK point taken. I think my uses of the JKI template are much more localised (maybe the word I am looking for is specialised, but even this does not really convey what I mean, perhaps what I just mean is "simple") so my private data in the shift register is a bit more cohesive. I do not have a cluster-saurus with myriad elements.

So what do you do when you need to execute a reasonably complicated bit of code which requires various bits of "data" in this cluster (i.e. a portion of code that screams out to be made into a sub-VI, which in my opinion is virtually anything non-trivial)? Do you unbundle the specific elements and pass them into a sub VI? I know it may be frowned upon, but by having the cluster typedef'd I then just pass the whole thing into/out of a sub-VI. Of course you could pass in a non-typedef cluster but we know how that is going to end...

It would be nice if the template could include a typedef for the main cluster on the shift register, I normally end up creating one.

Just to chip in here, I recently had the same problem (2013 SP1). Bundling in a "variable" wire did not cause the class output "cluster" to be updated. Bundling in a constant (in this instance it was a string) did cause the "cluster" to be updated correctly. Probably entirely related, editing some code in this class would cause the IDE to hard-crash, so I figure I just managed to get my code in a state that was not consistent. I fixed my problem by deleting the VI that caused the crash and re-creating it from scratch. I think the inconsistency happened when I renamed a class VI to something that had previously existed in that class.

I think this is actually possible in the IDE, but not in built applications.

In LabVIEW (and perhaps all Web Services, I am not sure here) the connection string is in the form: host_address:port/WebServiceName/QueryString so it just seems to me that something is redundant here. You can infact have multiple Web Services on the same port when running in the IDE, but then I suppose there is only a single application (LabVIEW.exe) that is bound to the port. However as soon as you have built applications this paradigm breaks.

Something to add (note, this is just something I "figured" out, it is completely uneducated and could be totally wrong) on the handle vs a pointer to a handle... Dealing with a pointer to a handle is a mechanism that allows the underlying memory allocation mechanism to do stuff like defrag or completely change your memory allocation without affecting your running application. Your application has a constant "memory address" that is the pointer to the handle. Then any actual requests to memory always go through the lower level manager (i.e. LabVIEW's memory manager) which actually does the translation between the handle that your app knows about, and the actual physical memory address. No doubt I am using all the wrong vocabulary here, picture me waving my hands in the air to get an idea that I only have a vague notion that I know what I am talking about.

Sure, your comments pretty much echo my internal dialogue. I can't figure out what the point is then of naming the web service? If all traffic to the IP address and port gets directed to the single instance of the web service why bother identifying it by name?

This NI document confirms my suspicions.

I was being a bit facetious, but I did not know about it only being TLS, so I forgive you. I have a ten week old at home, I didn't get to sleep with anybody last night

Just tried out something that I would have expected should work, but doesn't. As a Web Service is identified by a name I would have expected I could run several of them on the same system with the same port. This does not work, whichever service is started first works, the other does not. Moving the second Web Service to a different port works properly. Am I being unreasonable with my expectations here? I know enough about ports to be dangerous but that is about all, is there some underlying restriction of the OS (Windows in this instance) that only allows one application to bind onto a port? The reason I am doing this is to try and create a test environment so that I do not affect my production Web Service application.

It's a good thing NI never got around to making an SSH toolkit

So, most of you here are probably aware of the Heartbleed bug in OpenSSL. How seriously is everybody taking this? Seems like a good time to change my password; "12345" was probably due for an extra digit on the end by now ;-)