Shaun Hayward

I normally merge the VI's error with the node's error (with the node's error taking priority) - after all, they both are differnt things: the node's error relates to being able to call the particular VI specified, whereas the VI's error depends on the inner workings of the VI being called.

I was always under the impression that static refs loaded the linked VI & subVIs just like having a subVI on the block diagram would... This also seems logical to me as with a static VI ref you dont have to open the reference to access VIs properties... still if I'm wrong, that would make static refs even better maybe someone who knows for a fact can settle this for the both of us

or, if you want to use dynamic VIs for memory loading reasons (or some other reason where static links are not so desirable), you can always create a "launcher.vi" in the same folder as the dynamically called VI, that way the path to "dynamic.VI" will always be <launcher.vi's path><stripped 1><appended with dynamic.vi>

This means that you updated the dll LabVIEW is informing you that it is now using the updated dll - this is a good thing - dont worry about it. Once you save the offending VI you wont see the message again (unless you once again update the assembly)

You could also try opening the registry key in read-only mode - A lot of HKLM is read-only to regular users (without UAC elevation) and if your just reading a path this shouldnt be an issue. One of the inputs to the open registry key gives you an enum with things like read-key, write-key, etc - choose the one that looks the most like "read only" (I dont have a windows + LV machine around right now)

I've just added a similar comment to the idea, but I think my prefered variant would be the inclusion of VIT/CTT files on the palettes. That way when your with the rest of the VIs/Ctrls for your module/plugin/thing you could just click on the template icon and instead of dropping the VI or merged VI on the diagram, a new VI from the template would be created and placed. That way people who already know how to find the rest of your API will also by default know where to find your templates.

Another option you could use (that doesnt need opening references etc) is to have the parent class VI return an error code (ie a "method not implemented" error) - that way, any override VIs will execute normally, but any classes that do not provide this functionality will error in a known way that you can catch and handle appropriately, etc.

I had the same weird thing with the dialog disappearing - my solution was to throw together this little VI to recursively set the property on all VIs in a folder - it's a little quick and dirty but does the trick Mark as Source Only.vi

Do you have "Show Terminals" turned on? If so, try turning it off... I remember there being a bug in the NI version a while back related to that. If that solves it, then I guess it means that bug was never fixed in PJM's version.

The biggest one, especially with safety is that the Abort button will not carry out any proper shutdown routines - your application is stopped dead. In constrast a "stop" button, would property shutdown your hardware etc, making sure that the system was left in a sensible/safe state. In orhter words - abort could leave your HV on whereas stop would make sure it is turned off.

Its one of those slow days where I'm the only one left in the office (the rest are in Austin)... At least this way I can feel somewhat productive

Are you looking for something like this? To get a NaN constant, simply type NaN into any numeric constant. The "is NaN?" node will automatically adjust to give an array of booleans out if you give it an array of numerics.

Hi Again... it appears your heading down a road I've been before on more than one occasion! The way I launched Audio Properties was to use ShellExec and the command line "control mmsys.cpl" - this launches the Sound control panel. Shaun

There's a really handy couple of VIs in vi.lib\sound2\lvsound.llb: 1. Get Num Devices - this lists the number of input and output devices in your system 2. Sound Device Info - returns the *NAME* of the sound device associated with a number I normally use #1 to set N on a for loop, and populate a ring control with the names out of #2. Shaun

I thought in LV at least, a constant was something that was fixed at compile time - with a cluster constant is. The constant does not ever change, only the data you take from it to other parts of your application can change it (to me it's the wire that is the "variable", not the elements of the cluster)

I did not realize you could paste a child class's data into a parent's constant! (you learn something new every day!)

On on a mac at the moment so can't check but I'm sure there must be a SHA256 call in the .NET stuff (probably in system.security.cryptography)

Definitely! Fingers crossed..

Idea Posted: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Provide-status-dialog-for-Application-Builder-APIs/idi-p/1181125 Shaun

I haven't tried it with a 6009 but I have had issues whereby removing a DAQmx USB device mid acquisition (ie with software running etc) causes a blue screen of death (even on Windows Vista - I didnt even think that was still possible, but that's another story). (With the application idling / closed I haven't come across any problems with "unsafe removal" of USB DAQmx hardware)

For a complex application, with plugins, executables, and installers, a programatic build method (ie click GO to build the lot) has serious benefits. I've got this up and running on one of my larger projects but one of the things that has always bugged me with using the Application Builder API is this: Is there anyway to get any kind of status information out of the Build VIs? When building manually (right-click on the spec-> build...) a nice dialog pops up describing how far along the process has come etc. However, when using the App Builder API, I cannot see any way to get any feedback from within a build operation. Is there anyway to get some status information or at least display the standard dialog? Thanks, shaun

Yeah, that's what I'm doing - I just wanted to make sure that the loader didnt care what the actual filename was, just that it contained __manifest somewhere in the filename. In the end, this seems to work although I had a very odd situation for a while where it would take 30s to loop through 8 manifest VIs!!! It seemed to be something to do with the LabVIEW Image Data cluster. I couldnt find a way to actually track it down but my guess what that there was two copiees of the typdef - one inside the LLBs (which got put there by the build definition) and one in VI.lib, so Open VI Ref had to stop and think about which version to use. Either way, disconnecting the cluster from the typedef on the Manifest VIs seemed to solve the problem.

I was actually just thinking of something similar this morning (only without using VI tags, so that developers who don't know about such things dont get quite so confused ): (admittedly, this does require that someone create quite a specific VI but at least its a relatively easy to describe VI, and after all, that's what documentation is for!)

Yeah, I thought of that... unfortunately I have a trick to simplify things for my users: Each report gets "compiled" to a single "report" file - in reality, I have a build spec that puts the class and all of it's member VIs into a LLB - this makes distributing reports REALLY easy and logical for my end users. However, as LLBs cannot contain anything other than VIs, CTLs, etc, there is no way to add a text file into the mix. The LLB issue is actually why finding out info and loading only when needed is such an issue - I have to keep report templates as a compressed string constant in a VI (because LLBs cannot contain Excel / Word files, etc) and because every member VI is loaded into memory, I not only could end up with a whole load of unnecessary code in memory (some users may not use ANY of the reports) but I also could end up with a whole load of compressed Excel files in memory! This obviously adds a whole bunch of loading time / overhead, especially as the number of report options grows, and as some users may not even use a single report, I would really rather something better! I did come up with one hahe hack - I could screen for *.report files (the LLBs) and go from there. However I was ideally wanting something a little bit more generic - ie something that I could use in source code as well and ideally use in other projects (which may not necessarily use the *.report extension, etc).

Hi All, I have an architecture that uses dynamically loaded classes for providing custom reports - this way I can add/remove reports from our system without needing to recompile etc. Currently I have the logic of: (i.e. list all class files and attempt to load & cast as a Report class) This logic works but it has the problem of loading every single report class and all of its associated VIs etc into memory even if that report was never going to get used by a particular user. As such, I was wondering if there is a way of determining the inheritance tree of a lvclass file without loading the class into memory (or at least the names of the classes it inherits from)? This way I could do a simple "does lvclass file x claim to inherit from Report" without having to load a whole bunch of potentially unnecessary code. I have had a look at the lvclass XML and figure that this information is hiding in one of the binary (base64?) chunks but cannot seem to find any information of how to extract what I am looking for. To put it graphically, I would love to create this: Is this possible? Am I crazy for wanting to do this? and more importantly, anyone have any idea how? Thanks, Shaun