Jump to content

Mike Ashe

Members
  • Posts

    1,626
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by Mike Ashe

  1. I think this would be great. But what would happen is probably this: NI will still be making their compiler and sell it. They will probably only support exactly the features they want that suits their hardware. So there will be two versions of LV, the NI version, a commercial compiler specially targeted for NI hardware, and the open version. Then, who will be the users of the open version?

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

  2. I have been thinking about multi-lineness, but am not sure how to implement it.

    I can think of the following items:

    original path:

    c:\dataandstuf\somemorestuff\somedeepstuf\Reeldeepstuff\foo.stuf :D

    Mullti-line 1

    c:\dataandstu

    f\so...\foo.stuf

    Multi-line 2

    c:\dataan...\

    so...\foo.stuf

    ...

    What do you think?

    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.

  3. Thanks! I agree about the "\" before the file name. I added that, but I won't post another version here quite yet so as not to clutter the site with too many revisions.

    Another note: Although the internal code should all be platform independent, the logic assumes a Windows path syntax...

    Regards,

    Dave

    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:

  4. Hit Ctrl-C with the Search Results window active, and it will format all the entries in the listbox and you can paste/save it however you want. This was broken in 8.0, but worked before 8.0 and works again in 8.2. Is this what you mean?

    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?

  5. Gory details and/or downloadable examples, please! Yes it's comforting to see that great minds have blazed this path before - but it'd be even more comforting to have everything handed to me on a silver platter. ;)

    And now you see why my avatar is a pest ...

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

  6. 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 :book:

    post-45-1159825121.png?width=400

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

  7. (it's like when I was in the air force
    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. :P
    - no one asked supply for a blue short-sleeved shirt, we all requested a shirt short-sleeved blue :) ) It makes a lot of sense when categorizing your code.
    I'm also a fan of the dot model, so your example would become project.Toolkit.Filename.vi

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

  8. PS: I passed Jim while he was writting his book, so that doesn't count ;)

    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.

  9. I think it is amazing they even got it that far.

    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.

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

  11. Therefore, LabVIEW Project Explorer = StarTrek, and a more mature Project Explorer = Battlestar Galactica... (but even BattleStar Galactica had to start somewhere - look at the awesome improvement from the old 80s series to the new one - crikey!)

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

  12. Of course not! Active X is based on OLE which is a proprietary MS technology and there

    has been no working replacement for ActiveX on non-Windows platforms (and even if

    there would be LabVIEW for Linux does not support it). ...

    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.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.