Jump to content

Jim Kring

Members
 View Profile  See their activity

  • Posts

    3,905

  • Joined

  • Last visited

  • Days Won

    34

 Content Type 

Posts posted by Jim Kring

  1. Visual Indication of VI access scope (On the VI Itself)

    in LabVIEW Feature Suggestions

    Posted

    QUOTE (Aristos Queue @ Aug 30 2008, 01:27 PM)

    I didn't say that being able to see the scope while looking at a subVI is a bad thing -- I think it would be great and I support that feature. My take home point is that (and, maybe I'm just an old-timer, but) I think that most LabVIEW users interact with VI's, primarily, and with projects (.lvproj) and libraries (.lvlib), secondarily (especially in the context of debugging). As such, having ways to identify and modify VI settings (and, yes, I realize that this is an lvlib setting associated with a VI) easily from the VI, itself, is important -- especially, when the setting impacts the way that the application, as a whole, will run (or not run).

    If LabVIEW is going to limit feature visibility and access to the project/library environment, then it needs to do a much better job of allowing LabVIEW users to quickly get to the project/library from the context where they are programming their applications. For example, how come it is so hard to locate a VI inside of the project/library/class from a VI's front panel or block diagram? How come there is no way to open a class from the class hierarchy window? I think that there are several usability roadblocks with respect to libraries/classes and PJM's suggestion stems from trying to bridge them.

    That's why I don't think Philippe's request is "strange" (as you suggest). While it might not make sense, theoretically, it does make sense in practice. And, those of us who echoed support for PJM's request spend a lot of time practicing LabVIEW.

    That reminds me of a great quote I read today in http://www.codinghorror.com/blog/archives/001166.html' rel='nofollow' target="_blank">Jeff Atwood's blog article on deadlock:

    QUOTE ("Jeff Atwood")

    In theory there is no difference between theory and practice. In practice there is.

    Cheers,

    -Jim

  2. Visual Indication of VI access scope (On the VI Itself)

    in LabVIEW Feature Suggestions

    Posted

    QUOTE (Aristos Queue @ Aug 30 2008, 11:01 AM)

    True, but whether the VI is private or public makes a huge difference to how a caller (calling VI) will behave when you try to run that calling VI. For example, if the caller is not a member of the same lvlib as the callee, then the scope of the callee (e.g., if it's private) can cause the caller to be broken. When one is trying to debug and resolve this problem by opening up the VIs in question, there is neither a graphical indicator of the problem nor an easy way to resolve it, without going through the (relatively painful*) process of locating the callee in it's lvlib and changing it's scope.

    * Note that the http://wiki.openg.org/Ogedit_file_locate_in_project' rel='nofollow' target="_blank">OpenG Locate File in Project tool makes this somewhat less painful.

  3. Visual Indication of VI access scope (On the VI Itself)

    in LabVIEW Feature Suggestions

    Posted

    QUOTE (Aristos Queue @ Aug 29 2008, 08:21 AM)

    [Writing as G progammer, not as LV R&D developer]

    Strikes me as a strange request. Why do you care when you're writing the function what the scope of the function is? I can understand being interested in that when *calling* a function (ie, an annotation on the subVI call), but not when writing it. I don't know of any programming language that has that sort of notation in its code nor any language's IDE that provides that kind of visual feedback when writing the function.

    To me, the "I am Reentrant" glyph is a more useful request since a reminder that this VI is reentrant changes what I might write on this VI's block diagram (ie, don't use that control on the front panel as a storage location since it won't be the same control the next time you're called).

    AQ,

    I don't find PJM's request (making the access scope visible somewhere on a VI's FP window) strange at all. LabVIEW isn't like other programming languages/IDEs. When one interactively develops and run a LabVIEW application, they often have their VI front panels and block diagrams open. Knowing the access scope of VIs is very important, in this respect.

    Based the argument you provided, it would follow that LabVIEW users shouldn't care which Application Context a VI is in (when they're writing it), either, so why doe LabVIEW show the context name in the lower left corner of each VI? The answer is that this information is useful during and after development, when one presses the run button and needs to know (beforehand) in which context the VI will run. Similar utility would come from knowing the access scope of a VI when looking at a VI's FP or BD.

    Other programming languages don't give developers a tangible way of interacting with functions, the way that LabVIEW does. LabVIEW is different and special. Things that don't make sense for text-based environments, might make great sense in LabVIEW.

    Thanks,

    -Jim

  4. Setting up reusable vi's without crosslinking woes

    in Development Environment (IDE)

  5. Setting up reusable vi's without crosslinking woes

    in Development Environment (IDE)

    Posted

    QUOTE (HChandler @ Aug 28 2008, 03:24 PM)

    AQ's advice about splitting out your reusable VIs into a separate project is a good one -- when you create something that's reusable, you need to start treating it like a separate software product (with versions, customers, etc.).

    Putting your reuse VIs into an lvlib can certainly help avoid cross-linking, but it won't help you manage your reuse library's software life cycle or aid in managing projects that use the reuse library.

    As others have mentioned, VIPM exists to help you take control of your reusable VIs. And, you asked the question at the right time -- you haven't yet lost control. I recommend that you download VIPM and try to make a VI Package, by following our Package Building Guide.

    Oh, another great benefit of using VI Packages for your reusable VIs, is that you can add them to the LabVIEW palettes (and customize the layout).

    Thanks,

    -Jim

  6. XML File reader with Validation

    in Database and File IO

    Posted

    QUOTE (Val Brown @ Aug 28 2008, 06:50 PM)

    OK, thanks for the clarification. I'll look at it now. I don't use OpenG -- NOT because I don't think it's good. As I've said elsewhere, it's a wonderful set of tools which I have also recommended to others. It's just that, in my environment, I need to stay with as much native LV as possible.

    Hi Val,

    When you say that you "need to stay with as much native LV as possible", does that mean that you don't use VIs and only primitive functions? Nearly all the OpenG VIs are written in "native LV" (a.k.a., "Pure G"), with the exception of the zip library that makes a call into a DLL.

    I'm not trying to make light of your requirements, but to understand your environment and use cases.

    Thanks,

    -Jim

  8. Color generator

    in User Interface

  9. What is the best way to replace a member VI in a LVOOP Class

    in Object-Oriented Programming

    Posted

    1) Make sure that connector panes of old VI and new VI match

    2) Add new VI to class (so that it is a member) and save the class and new VI

    3) close LabVIEW

    4) on disk, rename Old VI as New VI and rename New VI as Old VI (meaning swap names on disk)

    5) open LabVIEW and your class -- it should relink the way that you want

    6) remove the VI that you don't want from the class (it will be named "New VI", but it's really the Old VI) and save your class -- you can also remove this VI from disk.

  10. Interview Questions

    in LAVA Lounge

  11. Interview Questions

    in LAVA Lounge

    Posted

    QUOTE (crelf @ Aug 19 2008, 01:18 PM)

    I'm not sure what the standard off-topic of off-topic of off-topic... level of recursion is permitted in standard etiquette, but I'd suggest that we've probably exceeded it :D

    I know this is off topic, but I think you're right ;)

  13. The Paper Chase

    in Certification and Training

    Posted

    Welcome, Tom, to the LabVIEW blog community. It's very interesting how the certification topic generates such passionate debate and discussion!

    I'll reiterate my perspective on certification, which is that certification is an important part of sharpening the tool, both for the individuals getting certificated and for the organizations that encourage the practice. As crelf alludes to, most work comes from having great solutions, created by skilled engineers, and a track-record of success. Making sure that your team and organization stay sharp is what enables this process.

    Certification might not be a great value for every team, but it sure is for ours.

    Cheers,

  14. Any known issues with OpenG code in 8.6?

    in Development Environment (IDE)

    Posted

    QUOTE (MrFURioUS @ Aug 14 2008, 06:12 PM)

    Hello MrFURioUS,

    http://jkisoft.com/vipm' rel='nofollow' target="_blank">VI Package Manager is the only way to go!

    Thanks,

    -Jim

    PS - Any other legacy stuff (OGPI, OpenG Commander) is not supported and might not work. Plus VIPM is way cool!

  17. Article - Delivering Sold-out NIWeek Presentations

    in NIWeek

    Posted

    [cross-post]

    Hi All,

    It was great seeing so many of you at NIWeek 2008. I can't wait for next year! We got a lot of good feedback on the JKI presentations and I wanted to share some tips that our team uses to create a great "user experience" for the audience (it's not unlike creating a great software user experience, in fact). Here's a blog article with some of our tips:

    If you have ideas about how to deliver great presentations or have feedback on our NIWeek 2008 presentations, don't be shy! We want to hear what you have to say and comments are always welcome :)

    Thanks,

    -Jim

  18. SCC software

    in Source Code Control

×
×
  • Create New...

Important Information

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

  I accept