Mike Ashe

This doesn't seem to be much different from the current situation with C/C++/C# in that you can get both free, open source compilers, tools and IDE's and you can also get several variations of commercial products. The norm in any market eventually tends towards a dominate player that controls about 80% of the market and everyone else splitting up the remaining 20%. There are lots of exceptions to this, but in general it is a pretty good rule of thumb. I would love to see NI release the source code for the basic G language, along with documentation and to have them sponsor or take the lead in a community effort to create "ANSI/IEEE Std G", but I will be pleasantly surprised if they do so any time within the next few years. Whether they do, or whether Open Source G is developed completely independent of NI, I am sure they will be the dominant version of G for a long time to come. Interesting questions to ask at NIWeek 2007 ...

I think by "multi line" we would mean listboxes or tree controls fed by an array of paths, not a multi line string control. The tree control is an especially difficult problem since you might have to retruncate for different branches which might have more or less room. List Boxes or Multi-Column Listboxes are next. Given an array of paths and a reference to the control, and a column number (if MCLB) read the available column width, then convert and truncate the strings and populate the rows of the control. For a real bonus you could detect a mouse up event on the listbox, then check if the user resized a column and if so, rerun the truncation VI.

Hello, welcome to LAVA. Glad to have you here. As for the avatar, it is the Hammer of Thor, is it not? :beer:

I did the quick scratch version as an act of mercy literally between gulps of coffee on a very short break. I should have read your post closer, or, more accurately, your sign off block. I was in such a hurry I didn't register the name. I agree with the slash before the filename. I might also suggest for your final version you give thought to LV 8.2 and also an older version like 6 or 7. Lots of people still using those. Another thought would be to make it a bit more generic is to take a generic reference and figure out what type of control it is: string? listbox? path? and size from there. This would be really useful in a lot of multi column listboxes. Bye the way, nice clean code :thumbup:

15 years at this and you learn something new every post! Gosh I love this forum. Well, this is close, on one aspect of the request. I should have been a little more specific. I asked for the text sort of as a, "gee, if we can't have "X" then could we at least have "Y" please?". I have to admit that what I'm really after is programmatic access to the Find functionality. Yes, I know we can do a lot of this now with scripting, but that cookie jar got moved to a higher shelf recently. The Find API, even just the DLL functions might be a step in the right direction, but what I'd really like is a few VIs that let me search for items, put them and their paths in my own listbox, do my own followup queries/tests, etc. Where this request comes from is that I have had several recent projects where the client's code is an archeology dig that really needs an enormous cleanup along with the extra functions they've asked for. Programmatic FIND would help in this effort. Could you or someone else pull back the curtain a little and expose more of Mr. Oz?

This kind of reply, to someone like Ben, who has been a pretty consistent and outstanding contributor to this forum does not show why your avatar is a pest, ... it shows that you have the wrong avatar. We all like code-on-a-platter at times, but your demanding attitude is pretty out of place here, especially since you didn't tell us where and how you searched these forums for possible or partial solutions to your problem, nor did you post any VIs showing how you had tried to solve or begin to solve the problem yourself. Asking for a shrink wrapped solution isn't always a bad thing if it is accompanied by a little more humility and helpfulness. So far, you have shown neither.

Bless you Sir! Hey Michael!, can we get this one added to the library of clickable smilies please?

A project I worked on about a year and a half ago did this, but without the iteration. If a path was going to be beyond "x" characters i used the path to array, indexed the drive, first directory and the VI name. It then inserted an ellipsis string ("...") in the array just before the VI name and rebuilt the path from the string. Can't seem to find it, so I just did a quick version.* No iteration, that is an exercise left to the student And here is the VI: Download File:post-45-1159825177.vi * For the regular's, yes the coffee is good at the moment ... (Hey, we need a coffee cup emoticon!)

A wing-washer huh? Us squids in the silent service used the same basic nomenclature, but you forgot the "one, each" at the end of the order. I personally like the dot model, a lot, but I have been burned a couple of times bringing in a plugin manager and dynamic loading of code to a new client only to have their code and mine not play nice together initially because some of their code was based on replacing what they thought were suffixes like .log or .vi with something else and they didn't anchor their regular expressions to the correct end of the string / VI names, they just split & replaced at the first period they found, argghh ...

Hey, I was reviewing Jim's book when you blew past me, does that mean you're still behind both of us :laugh: Seriously though, thanks. This forum has been my favorite for a while now. Hopefully around christmas time I can raise my S/N ratio.

I agree. I didn't meant the NQRFPT as a criticizm, just recognition that, like many new features we get over the years, the first version or two still needs some smoothing out. I said elsewhere that the new DLL stuff is one of my favorite features of the new LV version.

Obviously paths and permissions become much more of an issue with linux. We tend not to think of such things much in the Windows world, but you'll probably have to add some management for those items in your linux version.

Got to have some type of local stack, but that starts to get a little away from the stateless. I think what is needed is something that does not store data or state between successive calls at the same level of call hierarchy, but drilling down and answering up is okay as long as once the call is done everything gets flushed.

That's cool. I'm passing it around my current client's group. Hey, while we're on this, could someone post an example of the Flash Player code to embed videos like that here at LAVA? Thanks!

Another option might be to add a terminal point to the left side shift register and if you want it to initialize only the first time you wire in a "First Call?" primitive.

How would you suggest implementing the recursive function? Using the existing Call VI node or a new type of primitive, specifically for recursive calling of oneself?

[quote name='Lars-G

Hmm, guess they (Bristol) still offer Wind/U. Bristol Technology - Wind/U They are also the authors of HyperHelp, with is pretty common in the linux/unix world

Can you embed that last one in a VI with an activeX browser control. Would make a great "I'm Busy" screen to show during those long test runs ...

If we get that much improvement in the next NI version of LabVIEW Explorer I will publicly kiss the carpet after the NI R&D team walks over it at the next NIWeek ... (Is there any way NI could add a help avatar to the Explorer, ... and make it Boomer?)

So close, but NQRFPT yet. Maybe in 8.5 or 9.0 ...

A Shift(y) [eyed] Register ...

We're not zealots, we're spelunkers and archeologists ...

Correct me if I'm missing something, but isn't that the same avatar as you've been using for some time now?

Actually, the product WindU, from Bristol Technologies, used to do just that, but Bristol never got NI to implement it into the linux version of LabVIEW. A shame, since now that OSX is unix based as well, NI could probably get ActiveX commonality across all three platforms. Sadly, linux and Mac keep getting the short end of the LabVIEW stick.