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.

19 hours ago, GregSands said:

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.

18 hours ago, Michael Aivaliotis said:

Can you link to an example?

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?

in this program i don't want text be by row i want be column

Answer:

Probably you need to Transpose as well.

Or even better:

But if the time stamps are to be connected to the measurement values, which looks to be the case, I would bundle each time stamp with the corresponding measurement value into a cluster and then have a 1D-array of those clusters.

My suggestion was that Error Wires should be placed under other wires, and Darin suggested that the Read/Write status of property nodes should be determined by how you wire them.

... projections have my idea ahead of yours 180.12 to 151.66 after two years time. Of course that geek's predictions tend to be better when the tail is not disturbed too much.

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

To summarize, all the complaints I'm seeing are related to the representation on the BD.  Is that accurate?  

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:

 

Channels Can Create Cycles

Channels do allow for bidirectional communication as well as any more complex cyclic graph that you would like to construct.

That diagram is impossible to interpret with the Channels drawn like other wires on the BD.  

To me this seems like an incredible concept if done correctly.  Essentially a loss-less local variable that can communicate cross-platform from what I've gathered.  

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.

And now we know about VIMs. Woohoo! And I get all that (or should I say all that disappears) just by moving a wire and adding the letter m to the VI name , No code bloat. Still 16kB. Still a single VI. Whats not to like?

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

Additionally, I've built just enough XNodes (8-10 or so) to be of the opinion that VIM's are a little too underpowered to be considered over XNodes for the framework/middleware layers and below, but miiight be useful at the one-off application layer (extrapolating here, not based on battle scars and victories), where "saving development time" knob is tuned a bit higher, and "most elegant/usable syntax imaginable" is a bit lower.

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.

Sort of agree except about where they sit. Xnodes and VIMs aren't competing, but VIMs are closer to polymorphic VIs, IMO, without the code replication overhead of diagrams per instance that I always point out.. If you don't need to adapt to type for different companes, then these are the tool of choice to give adapt to type with a single diagram, single point of maintenance and no VI bloat or replication.

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

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.

Ahh. But to call yourself a LV Architect you do.

They even have special orgies every year that no mere mortals, however capable, can join in. They speak in tongues and discuss spells and other voodoo magic that no non-architect can understand or even hear without going insane. Then they go back to their local covens to plan the next act of debauchery with the new curses and sigils they have learnt.

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

1. Instead of returning the sorted indices array and searching it, you can just find the location as you create the string array, like this:
   
    
2. 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: