GregSands

There's nothing built-in that I'm aware of, but I've had success using the code provided here: https://decibel.ni.com/content/docs/DOC-43009 This is only on Windows, but worked well and quickly enough, though I wasn't trying to do it in real time.

Just to add to the description of the problem, it does work ok if going through the right-click menu and Selecting a VI(M) - i.e. not on the palette. Hope it can be fixed as the possibility of using Type Enabled Structures in VIMs is extremely appealing!

You should be able to use the OwningVI property (and then VI Path/Name or similar) wired to the XNode ref in an OnDrop Ability VI. It won't work in Initialize which is called before the XNode is dropped, so the VI is not known then. Also, no VI name/path is known if the VI is not already saved, which could be common. You may be able to check the Library of the OwningVI for it's project/class which may be helpful.

I don't think multiple projects will work if using Network Shared Variables (ok, I know that using them is the main mistake, but they seem to work well and easily for my code). But the difficulties in working with classes or reuse code on more than one target at once are challenging at the moment. There's an old suggestion on the Idea Exchange relating to this, also detailing some of the issues in fixing it - I'm sure a few more kudos wouldn't hurt, though they may not help.

Also, most of the Array functions could be rewritten as .vim macros, which solves both the issues of polymorphism and inlining.

This library is obviously not heavily used any more, as I've just noticed that the Build Array primitive routines both have the wrong object created.

Well what do you know, it appears to be ok now For example in this post, my attachment had not been showing as a link (it showed something like [attachment:11623 ...]), so I reattached the file using the editor, and the file link showed along with the "[attachment ...]" text, but today they're both showing as links. All good!

Seems like any files previously attached to posts are no longer attached. Is there a script that can run through and relink them all? I like the new look too.

OK, I think I'm not fully understanding what you're trying to do, or even what a "collection" is. Your data is not in a Variant, not in a cluster, not in a class, perhaps not even in a LabVIEW type. Is it just a sequence of bytes, and you're using the format string to tell your Formatter how to interpret those bytes? In which case, going back to your first post, it seems to me that you do have to write your own implementation, though you can choose how general or specific you want to make it. But there's no advantage necessarily in being tied to the LabVIEW format syntax - your requirements may be substantially less, or greater, than what it provides. The code you originally provided seems entirely reasonable then, with the small adjustment of interpreting raw bytes rather than a variant. I guess you may also want to consider the option of sending the formatting only once (essentially defining the String representation of your data "object"), and reusing it for all of the data, especially as it sounds as though your producer is providing a lot of data very quickly, too fast to do the formatting itself. That sounds sortof like registering an object with your Formatter, and then just telling it the following data is of that type.

OK, so here's a very quick-and-dirty XNode to do what I think you're wanting. Don't use in any code you care lots about, though it should be ok if you always wire it up properly - i.e. errors are ignored, not handled FormatCluster.zip FormatCluster.zip

OpenG has a similar function in its String library for formatting a Variant into a String, though not for splitting up a multi-variable format. Like you, they've chosen to implement a subset of the possible formatting commands. Alternatively, you might have success with an XNode which effectively scripts the wiring between Unbundle (assuming your data is in a cluster) and Format.

Can you just do the formats one at a time and then concatenate?

Answer: Or even better:

Of course I forgot to check after 2 years, but it's coming up 3, so where are things at (tweaking the tail once more)? Well my cosmetic Errors idea has actually pulled ahead of Darin's useful property node idea 176-168, thanks to a surge mid-last year for some unknown reason. Despite that, the chances of either actually being implemented is still about the same, which is probably best approximated by .

They don't ignore structure boundaries - click on them, and there is a transparent terminal. Not sure how they loop without feedback nodes though, I guess the wires have some special flags set? What's also interesting is that the wires are colored from both directions (this one shows a mis-match in types):

No, I think there's a semantic issue as well with calling them "wires". The BD representation is ok given that there's no other place for them to currently be represented, but I think my (and possibly Shaun's) argument is that they shouldn't really exist on the BD at all. They're in another dimension. And even more so if you want to show the links between VIs, or across platforms. Even more so with statements like this: That diagram is impossible to interpret with the Channels drawn like other wires on the BD. I might be wrong, but as far as I can tell, Channels don't (yet) enable anything different to what can already be achieved, but provide a new visual representation. AQs post (read the whole message again) sums it up really well: "The goal with channels is to provide a visualization of the asynch communication code paths". So they're a way of seeing/probing links between different sections of code that are connected by a queue/notifier/event/global/... Channels are just a higher-level box that encompasses all async communication. And by "just", I don't mean "merely" - like you, I think these could be incredibly powerful and useful. It's already possible to implement a loss-less cross-platform communication using Network Streams, but I think Channels might eventually give the ability not only to do that more easily, but to be able to directly see/follow that link.

IMHO, Channel Wires are definitely not Dataflow. But that's not necessarily a bad thing - LabVIEW has not been a pure dataflow language for decades (when did queues/notifiers/... first appear? Anyone still alive from back then?) And I can even see the point of having them - they provide a visual representation of that non-dataflow, and the various types of Channels just describe the transport mechanism. The issue for me is in calling them "Wires" at all - that's where the confusion arises. They seem more like "Portals" - something that connects two locations without traversing the space in between. In that sense, I don't like that the Channels are sitting on the block diagram, and perhaps that's where a 3D view could be more useful - I can more easily see them existing in a hyperspace that sits outside of the block diagrams. One more thing - the existing Queue wires could be thought of as Channels/Portals, right? The data doesn't flow along the wire, it teleports to other locations, and you can even do away with the wire altogether with named queues. So the Real Problem is that LabVIEW has been calling things wires that are not wires, and now perhaps there's a chance of changing that, and giving a robust framework for understanding non-dataflow. One last thing (I promise!) - I would think Global Variables (and Shared Variables?) are essentially part of this too, but they're more like a Quantum Portal, where each end is "entangled" - i.e. there is no underlying transport mechanism in between.

Can you attach a VIM version of your Queue VI? I can't see how the Dequeue function works without wiring the output type into the VIM. It would be different if you wired the Queue itself between VIs, but you expressly restrict that (for good reasons).

I've created 30-40 XNodes, and while I haven't done so, I think almost all of them could be replaced by VIMs. But most of mine are pretty simple, roughly equivalent to the OpenG Array XNodes, which I think could also probably all work well as VIMs. Knowing that VIMs are just generic XNodes is kindof reassuring - while they have a few issues, they seem to me to be a lot more stable and usable than say XControls. I've got pretty high hopes for VIMs, just no time to do anything with them at the moment. Yes, this makes sense, as most of my existing XNodes are essentially polymorphic replacements, which is why they seem to be good candidates for VIMs. However, what does blow my mind, even more than VIMs existing, is that AQ had no knowledge of them! All my preconceptions are demolished! Hopefully this is like feeding a mouse to a tiger - it only makes him hungrier...

What? Been there since pre-8.2? Who's been laughing at us flailing around with locked-down multi-VI XNodes (or multi-multi-VI polymorphics) for years? This seems to answer 99% of my (and everyone elses) requests for a simple type-adapting VI. Looks like a very simple XNode without any type-checking (e.g. wire a Boolean to the Delay input and it generates the code but breaks the calling VI). But if the programmer can be trusted, it looks incredibly useful. I would presume it has the same caveats as using an XNode, but if it's now "released" (thanks jkodosky, who I imagine has some mandate to do so) it would be good to know anything to be aware of. BTW, this is certainly not the same as the buggy, non-supported Generic VI that was dangled in front of us some time ago.

FTP is: ftp://ftp.ni.com/evaluation/labview/ekit/other/downloader/

The main problem with the System controls is that the color cannot be changed, nor parts made transparent (this can also be a benefit, depending on your point of view). I quite like the frameless Silver controls which are clean and fairly customizable. Here's an example creating numeric tables with different Array enclosures: As another example, I made a group of cluster arrays in this thread on the dark side.

That's the most precise definition of LVOOP I've seen! Well, your definition anyway...

Just thought of a couple more ideas for you which use less memory and may be quicker (I haven't benchmarked them): Instead of returning the sorted indices array and searching it, you can just find the location as you create the string array, like this: If you know that the original list is sorted, then there's no need to sort the whole array again - it's easier to delete the current element from the array, then determine directly where to insert it: This also lends itself to easily adding new elements (just eliminate "Delete From Array"). (I fluked the string comparison - hadn't realised it would work, but I guess it just treats the string as a byte array).

I would use the OpenG Sort Array function, or similar, like this: