GregSands

As I pointed out in the previous thread as well, you can use the Sign function to convert R (the remainder of the integer division) to 0 or 1, instead of the three functions you use here. Also, this value R gives you already the number of padding characters required, which could be added to the Input String before processing - depending on the memory effects of doing this. Doing all that could simplify the diagram somewhat. What is the reason for outputting the Last Character? Is there an obvious use for this?

I think you need to use sign( R ) like this:

Some years back, the OpenG palettes were scattered through the categories - OpenG Array routines under Programming/Array and so on - rather than collected under a top-level category. I think that was incompatible with some new version of LabVIEW, so everything changed to the top-level OpenG palettes. I'm with Bob on this - if I'm looking for an array function, I don't care whether it's OpenG or MGI or whatever, I really want to look in just one place for it. Quick Drop makes this somewhat easier (there's no connection to any palette here) but it's not so usable for browsing for a half-forgotten routine that you're pretty sure someone had written somewhere...

Magic is not a bad word for it all. Really useful tool, thanks for the silver update.

Without being demanding have you thought of creating a "Silver" style expansion pack? How much effort would required in getting that working?

My experience with .lvlibs is that it is very straightforward to move VIs into them, but very difficult to change anything later. I once (and only once) made the mistake of splitting a large .lvlib into several smaller ones, thereby moving VIs into new namespaces. It was a real headache relinking all the code that called those VIs - there doesn't seem to be a way to automatically find them in a new namespace. Very nearly rolled it all back - though I do now appreciate having the smaller libraries, as loading any one VI from a .lvlib loads the whole library. (If any does know how to do this, please tell me -- I'll feel silly for 5 minutes, then really appreciate it!). So, yes, in my opinion it's worth doing, but you have to do it right the first time. OpenG is probably defined well enough that this won't be an issue.

Another "major change" that may be worth considering at the same time is whether to put the OpenG packages into .lvlib libraries. Pros and cons?

First up, it's not that I don't like Front Panels! Rather, the idea comes from the recognition that, as evidenced by a fair number of ideas in the Idea Exchange, FPs often add unnecessary work to developing VIs. I was trying to pull a number of different ideas together into a solution, sparked by reading this idea which suggests adding yet another layer to a VI - and questioning whether we can reduce complexity instead of increasing it. There's been some discussion on how to limit the FP to show only what's needed for the user interface (e.g. here). Having unneeded (from the interface point-of-view) controls and indicators on the FP means we need to work around issues such as edit-vs-run-time displays, setting up tab orders, rescaling controls (but only some of them) as panels change size, disabled code, and so on. The basis of my suggestion is not that we shouldn't have FPs, but that FPs should only contain what is needed to be seen by the user. Secondly, the data that needs to be seen during development or debugging is often very different again. When we use a Probe, we essentially create a virtual indicator. Take the Probe Window slightly further in its development, and we now have a second FP, which contains another set of controls/indicators for showing, or setting, the data during execution. Also, for many VIs, the variables that are passed through the conpane interface are not required to be shown in the user-interface - Error clusters for example. It makes sense to be able to link the conpane directly to BD controls, and therefore there is no need for the controls/indicators to appear on the FP at all - many subVIs without user interaction wouldn't need an FP defined at all. To me, the conpane has a much stronger link to the BD than the FP, as it is there to provide the programming interface to the code. The downside would be that it is perhaps more difficult to find terminals on a crowded BD, but that could be enhanced (e.g. mouse-over the conpane, and everything fades except for terminals). Perhaps there would even be the opportunity to see the FP as a virtual cluster. The LV paradigm presumably arises from the concept of Virtual Instruments, where the controls/indicators are what you define your instrument by - and much early code was all contained within one VI! This idea suggests that LV has perhaps grown past that stage, with far more emphasis now on subVIs, classes, libraries, etc which are maybe more like patch panels or breadboards (still thinking as an engineer!) - things that are hidden from the end-user. I don't see it as such a radical change - more a response to the way that LabVIEW is being used anyway - to make that process easier and more transparent.

This is a shameless plug for a new idea I've submitted to the Idea Exchange suggesting that by default, a VI should not have (or need) a Front Panel. Connections to the con-pane are defined from the Block Diagram - after all that's where the data is used, and the subVI interface to that data should be specified. One (or more) Front Panels can then be added which provide a user interface to the BD data (controls/indicators). Perhaps one is the standard run-time view, and another is a debugging view (like an enhanced Probe window). Or for many subVIs, there may be no FP at all. Kudos (or critique) welcome!!

Perhaps it would be a good opportunity to evaluate whether a non-recursive implementation would be better (i.e. simpler, faster, clearer, lower memory etc). For example, Write Key (Variant) could use a queue rather than a recursive call - what are the pros and cons of doing it that way? For a single Key (which is not a Cluster or Array) I imagine there would be a significant cost in creating the queue, but that is quickly traded off against the cost of setting up a recursive call. Perhaps the queue only gets created inside the Cluster/Array case. But if recursion is retained, then the native approach is certainly cleaner.

Yes, I'd noticed that too. A fairly easy way to fix it would be to pass the unencoded strings into the recursive calls, rather than the encoded ones. It does seem a little unusual that this VI was written to be called recursively - I would have thought that creating a queue of keys would be a simpler way to go, though perhaps a little more overhead in the case of only having a single key.

Well, here we go: https://decibel.ni.com/content/docs/DOC-15706

I think the problem is that doing so breaks the Create Accessor dialog for classes. But Brian has not replied with how to get other icon editors to work without breaking this. My guess is that NI will need to provide an unlocked lv_icon.lvlib (not .lvlibp) which any alternative editors would need to be programmed into. It does make the whole thing less straight-forward than it used to be.

So is there a legit way to use a different icon editor?

I see there is already an option in the "New Content" page to see new blog content. Seeing as the settings at the left of this page are retained, it would be great if multiple content types could be selected - for example, I'd choose to see all new forum, code, and blog entries all on one page. Perhaps it gets a little difficult with the various sections within some of the content types, but if the default was, say, forum+blog entries, that would do a lot to ensure the visibility of blog posts.

I'm also a fan of this editor (though I wish its text abilities were used in the default editor). It is possible to get this working in LV 2011 -- you just need to delete/rename the lv_icon.lvlibp file in the resource\plugins directory, which now contains the lv_icon.vi file. It would certainly be nice if there was an easy way to swap between editors while editing an icon.

I guess it depends on the visibility, and therefore interaction, and whether there are any advantages over simply posting to the forums. Similar to Ton, I could imagine a few things that might make useful blog posts (i.e. they don't fit naturally into any of the forums), but whether that translates into an ongoing stream that is actually interesting is another matter.

Then why leave so many useful VIs off the menus then? The suggestion of copying them elsewhere makes sense, although then it becomes easy to miss if VIs are updated in a good way (as opposed to making things break). I could probably name a dozen VIs/libraries from the Utility directory that seem to me to be similarly core functions (for example, the Range and Ratio VIs I mentioned above) - I guess someone found it easier at the time to just put them unnoticed into the Utility directory, and they've never migrated to a more useful place. Yep, I did give you credit for that first up. (Thanks by the way!)

Seeing this mention of the Binary Search Pt-by-pt VI, which I would never have found, I was wondering if anyone has a list of all the vi.lib VIs that are not contained on any of the default menus? Even better, menus that expose them? Or add them to Quick Drop? Certainly in the Utility directory there are an endless number - some I've used are: Variant Data Type Library (menu here) High Resolution Relative Seconds.vi Range and Ratio.llb libraryn.llb - the Librarian VIs which are mostly exposed as part of the OpenG File package (though not Create Directory Recursive or Delete Directory Recursive) Any others which are particularly useful?

Nice clean layout - I like! took a while to find the "Mark as read" button - now down the lower right - but now that I have, it's all good.

Well, here's one: the Generic VI. And just last week, this was posted: https://decibel.ni.com/content/docs/DOC-16905 Not "NI-internal" as such, but not exactly fully supported either. Hmm, wonder if those are related at all.... Having written a few XNodes lately, I really appreciate having that functionality available, even in a completely unsupported way. But I'm still struggling to master the techniques that are available (XControls, LVOOP - I'm looking at you!) without worrying too much about what else might be under the hood - apart from that Generic VI - that really would be useful.

So does anyone have any idea why these come up in recent versions of LabVIEW only (or not in 8.6 in any case)? Nice spotting - I hadn't checked for that. Here's a new version which seems to cope with arrays (of any dimension) inside the ClusterArray. It does just pad with the default value, same as auto-building any multi-dimensional array. There do still seem to be other bugs that arise when the ClusterArray is changed after wiring some outputs. It would probably need a more sophisticated system of keeping track of element names in order to handle this properly. Unbundle Cluster Array v1.1.zip

Darin.K made the suggestion of being able to extract sub-arrays by specifying the start and end of the subset, rather than the start and length as LabVIEW allows. I had written this XNode a while back, so have just tidied it up. ToDo: - Accept 2D (and greater) arrays - Make growable for multiple subarray outputs (would also be useful for the builtin Array Subset) Requires: LabVIEW 8.6.1+ Gavin Burnell's Scripting Tools (invaluable!) Index Array Subset.zip

I get this behavior randomly on some project files - and I think only for LabVIEW 2010, not 8.6.1. I've never managed to track down why it happens, or how to cause it or prevent it.

I've had a few evenings to work on another XNode, this time to unbundle an array of elements from a Cluster Array (as per this Idea). As much as possible, I've tried to mimic the functionality of Unbundle Cluster by Name. There were a few tricky things to get this to work, and I'd be interested if I missed an easy way to achieve any of them: traversing a cluster hierarchy to build the pop-up menu not permitting the XNode to be shrunk past any connected wires correctly wiring outputs again if the XNode is extended upwards Comments welcome! Requires: LabVIEW >8.6.1 Gavin Burnell's Scripting Tools (thanks again!) OpenG LabVIEW Data and String Libraries Unbundle Cluster Array.zip