Stobber

Insofar as I'm using Format Into String to do the actual formatting, I don't have to implement any of the formatting commands. I just have to scrape the variable's data type so I can cast it from the Variant. If my data were a cluster, the consumer would have to know its structure (data types, data names, shape of memory structure) at compile time. That would completely undo the objective of decoupling consumer from producer. (Thanks, but if I can't use it in code I care about, what good is it? ) While this, when completely fleshed out, allows me to easily write a consumer that's correctly coupled to a particular producer at edit time, it still establishes coupling. My data producer won't always be a LV app, or even an app written by my team. I want to completely abstract the type and arrangement of the inbound data set from the consumer. It should just receive a "collection" and see that turned into a formatted string. Good point: By embedding the "format this data" algorithm into the data itself (via a method on the abstract type and data in the concrete type), I can hand abstract data to the consumer and let the data format itself. In a high-level sense, that's what I've done with my Variant implementation: The abstract data set is an array of Variants (which itself could be structure as a Variant if I wanted to get even more abstract about the structure), and the formatting algorithm is abstracted into a string provided with the data and a function (Format Into String) that processes the data. The queue is just a transport mechanism for getting the data and algorithm over to the consumer. Assuming the producer is always LV code, the queue is one of many good choices. On that note, since my producer isn't always LV code, a LV Object might limit my implementation, too. (I'd have to convert the data from another type into a LV Object, requiring knowledge of the concrete data type in the consumer.) But for LV-to-LV implementation, a queue of objects is a great way to go.

I didn't want bother implementing it for all simple data types, since my data's not in a Variant, but here's a first-pass example of how I got it done. Format Variant Array Into String LV9.vi Format Variant Array Into String LV15.vi

You're both onto what I've been working on since I posted. It's not as bad as I feared. I'll have to enforce ordered parameters, at least in the first pass, to minimize string mangling. Let me hammer on it a little more, and I'll try to upload a version that uses an array of variants for your review.

I want to decouple the producer of a set of data from the consumer which turns the data into a formatted string. The producer should run super fast, so I don't want it to spend effort formatting the data into a string; just throw the parameters (which the producer knows but the consumer doesn't) into a data structure and send that to the consumer. The consumer should be bindable to any shape of producer, so it doesn't want to know which parameters it'll get or how it should format them. This should be straightforward. I can send a "format string" along with the parameters so the consumer does whatever it's told by each producer. But LV's Format Into String primitive requires a fixed number of parameters at compile time! I'm trying to roll my own using regex or the tokenizer, but I realize I'll have to implement the whole format specifier syntax if I want it to work generically. Can anyone think of an easier solution? Preferably one that doesn't establish an external dependency on my code...I don't want to have to ship a VIPM with its own license terms or install a new .so/daemon on the cRIO.

1. This looks great! Any attempt to reinvent the crusty LV IDE is fully supported here. 2. I was pleased to find this tool instead of another package manager when I clicked the link to this thread. Any reason you called it a "code manager"? 3. Are you actively developing it to address bugs like the one you posted today? Do you intend to invite community collaboration on the plugin framework?

Oh yeah. Good idea.

Has anyone published a tool that'll copy a VI's entire dependency chain on disk with all the correct re-linking and such? I need a way to move chunks of features in and out of projects, and sometimes these features aren't nicely separated into classes/libraries/ppls, or they call into lots of scattered non-VI.lib code. I see there's a "Get VI Dependencies" method in VI Server, but it doesn't include XML files like classes, libraries, xnodes, etc. The "Duplicate hierarchy to a new location" option in the "File >> Save As..." menu does exactly what I want, I guess...but that's insensitive to code from VI Packages that don't use <vi.lib>. It'd sure be nice to extend that tool with programmatic access and a feature that scans installed packages to avoid copying their code. Edit: I realize that "dependency chain" is a much broader term than just the call hierarchy, but I'm really just interested in the call hierarchy here.

Honestly, the solution to that problem is to write a C application using the NI-RIO C API instead of LabVIEW.

Definitely sounds like another language feature hacked in to support the improvement of NI-internal APIs. I wonder if there's any intent to publicly document it better with examples of creating, say, a DLL that uses this feature to share data with a LV app. I also wonder whether the Scan Engine exposes a similar feature to NI-RIO that lets me post scanned values directly into a file!

http://zone.ni.com/reference/en-XX/help/371361L-01/lvscript/datavalrefnum_isexternal/ I just found that by accident while clicking around in a class typedef that contains a DVR. What does it do?

I'm walking through a LVRT Project using the VI Server API, trying to find a particular build spec on my FPGA target. I can get the target ("FPGA Target") by name and use that ref to find the build spec by its name, but the reference returned can't be cast to type ProjectItem:BuildSpecification. If I probe the reference wire, the only interesting thing I see is the type GUID... {F4C5E96F-7410-48A5-BB87-3559BC9B167F} Does anybody know of a way to deduce the VI Server object type from this GUID so I can perform a downcast on it?

There were no "what's new" sessions at the CLA-A summit. I can't recall when there ever were. I recommend just reading the help docs anyway, as most of the info you need is put there with every release.

That looks like the kind of red flag this graph is intended to show. Find the ribbons without pointy tips and fix your dependency chains so they all have pointy tips again! Edit: Also, a good rule-of-thumb is not to nest libraries (or classes within libraries). It slows the editor down badly and creates dependency hells like the one you have there.

The pointy end of the ribbon (or "leaf") connects to the dependency.

Mrmas, the link drjdpowell gave above will help you tell the API where your SQLite library is. You'll have to install SQLite using NI's opkg server. if you want to use the very latest version of SQLite instead of the one NI's currently distributing, you can follow these instructions.

Ah, that makes more sense!

That seems like the kind of thing that should be added to a wrapper or extension to the library's classes, not to the library itself. As someone who never uses ASP.NET (or any of hundreds of other frameworks, services, and tools I can choose from for a new project), I don't want to lug that VI around in my code base.

You should go sniffing around for a STIL API. If there's none native to LV, look for one in another language that can be built into a DLL (C++) or called from the command line (Python).

You want to manipulate STIL data using a JSON API? Sounds like turning a screw with a hammer... Can you get your vector generator (or whatever test equipment you're using) to output STDF instead?

Nice, thanks! Mind re-posting them here with a more friendly license?

I haven't looked at the Character Lineator, but my impression from forum chatter is that it's a monster that runs slowly. Is it worth use in production software these days? That said, I still don't know whether jdpowell's suggestion is the right way to implement an app-specific ser/des protocol. I feel like that's a different code module than this one, maybe using this one as a dependency with the existing API.

Caution: a framework keeps all the assumptions but provides none of the code. If you don't handle a lot of the work for the user (making assumptions about how to do so), I don't see what help your new classes will be. All you'll do is give people the opportunity to make your code package a critical dependency of their project. If anything, I recommend using the Strategy pattern to provide a default Serialization Behavior that people can override with their own.

I think you mean "objects" everywhere you say "classes". To that end, I once created an "INI Serializable" class that did what jdpowell suggests. In addition to providing overridable protected methods for "Serialize" and "Deserialize" actions, it had infrastructure to generate a GUID for the object to be serialized and all the objects that composed it. The objects' GUIDs were the names of sections in the INI file, and their private data were written to keys in that section. A key was added for each object composing the one being written, and the composing object's GUID was assigned to that key. In this way, the Deserialize method could build up an object's simple-datatype members, then look up any sub-objects by their GUID, build those up, and insert them into the owning object. i.e. the output of "Child of INI Serializable.lvclass:Serialize.vi" would be: # Flattened object [5FF01668-0B7A-4EAF-9CF7-B09754EB4A07] __class = "Child of INI Serializable.lvclass" __object1 = "64F7B537-BC57-48BE-B425-8C4197D51925" __object2 = "79C1503B-4745-41FF-B3D9-3B2DCD3B079D" number = 1.0 string = "Hello World" [64F7B537-BC57-48BE-B425-8C4197D51925] __class = "Behavioral Strategy.lvclass" [79C1503B-4745-41FF-B3D9-3B2DCD3B079D] __classs = "IO API.lvclass" visa name = "ASRL2::INSTR" I wish I'd kept the code, but it's lost to the ages. You could recreate it in a day and probably add stuff for handling variants in the same way, since they amount to key-value dictionaries anyway. Edit: This still required that every serializable class override the serialize and deserialize actions to manually output a VCluster of their private data and later accept that VCluster, parse it, and build up its own private data again.