Shaun Hayward

I am under the impression that Static VI Refs do not load the VI into memory but they "link" to the VI (i.e. you do not have to include them in Dynamic VIs in the build spec)?

Or is there some memory hit I am unaware of? (I know Darren says he doesn't trust 'em)

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.

Hello PJM,

I used to be able to click on the eraser function and then hold the mouse button down while dragging the pointer across areas I needed to erase. Now with v1.7, I have to click on each individual pixel to erase it. Could you return this function back to the click-and-drag method?

Thanks,

Ron

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.

Just get a numeric constant and type NaN inside.

(Curses! Foiled by Shaun again!) Don't you have a job?

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 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)

I know that some work arounds have been presented, but it'd still be nice to be able to look at a method's inheritance without having to load the whole class.

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

One thing to note is that because the manifest VI can't belong to the class (if it would, opening it would load the entire class) you have to be careful not to load two of them at the same time, or you'll get a conflict.

One generic way of working around this would be to embed the info in the VI's name (e.g. call it "Report_Manifest___XXXXXX", where the Xs are the details you want). That way you don't even have to open the VI.

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

Are any VIs that include the Xcontrol (either as a variable, or on the front panel) loaded and/or open? If so, try making sure all other VIs are closed before you build - this solved an error that I had that looked similar (I cant remember the exact code).

Shaun