Jump to content

lvb

Members
  • Posts

    209
  • Joined

  • Days Won

    7

Posts posted by lvb

  1. Thanks for another great BBQ! Had a great time meeting some new people. I think Justin was disappointed to find out I am a guy. Must have thought BrianAFischer was BrianaFischer... I updated my username to something a little less confusing. :-)

    One suggestion for prizes though: please give TSA carry on luggage friendly prizes! I was the proud winner of a Swiss army knife, but could not bring it home in my luggage. I donated it to a hard working NI employee in hopes that he can "carve" out one or two of my suggested LabVIEW features.

    (null)

  2. That is different than what I got. It did tell me that the number I put in from the NI email couldn't be found, but it successfully found my number via my email. Perhaps try a different address?

    Still no luck, trying to be patient! :angry:

  3. I would suggest that anyone currently working with SVN install TortoiseHg and use it as a client to Subversion. You don't have to convert your existing SVN repositories. TortoiseHg can be used with your SVN repo instead of TortoiseSVN. This also allows "offline commits" with your SVN repo.

    http://mercurial.sel...ki/HgSubversion

    http://mercurial.sel...gWithSubversion

    Just hg clone with the "svn+" prefix. For example:

    hg clone svn+http://svn.python.org/projects/python python-hg

    After you get acquainted to Hg, make the jump to Hg repos...

    • Like 1
  4. OK, now it has more sense! I have prepared an improved version; it works fairly well, but I still detecting problems with some objects when several versions are installed blink.gif . If anybody discovers something else, please tell me.

    I hate to resurrect old posts, but this tool is not working on my Win7 32-bit system with LabVIEW 2011 SP1. Norm/Aitor - What version of LabVIEW and Windows did you have this working on?

  5. I have already jumped into scripting this tool. :book:

    Wrapping the properties and methods should be easy. However, any suggestions on how to script the selection of a Type Library? It would be nice if the native Select Object From Type Library dialog could be launched, but I don't see much in scripting related to ActiveX and Automation Open functions.

    I found this related post on LAVA, but it does not create the ActiveX ref. It creates an array of I16.

    post-4274-0-92881000-1342012853.jpg

  6. PPLs are not a part of the LabVIEW language. They're just packaging for functionality, no different in many ways to a .zip file. The PPL is not a presentation layer or any other formal aspect. It's just a tool for getting VIs to load faster. When you ask for changes to scope, that addresses language features, which means changes to the run time behaviors that would impact dev environment and run time environment alike, regardless of packaging.

    It sounds like this would be a major addition (or would never happen), but it would be nice if the lvlib supported a presentation layer

  7. Why isn't protected scope sufficient hiding?

    Because the VIs are still visible in the Packed Project Library (they are not hidden):post-4274-0-22364700-1334843698.png

    Since they shouldn't be used, the user will question why they are visible.

    That would be unusual among the world's OO languages. I'm not saying it's a bad idea, but when none of the major OO languages that I know of do it, I always have to ask why. Scope is not one of those areas that is impacted by dataflow.

    Isn't this a feature of the Packed Project library (that does not exist in other languages)? The PPL is used for "interface" and it would be nice to separate the "presentation" from the class itself. This would reduce a whole lot of "busy work" wrapping classes.

    Thanks,

    Brian

  8. To control what is visible, set the access scope. The dynamic dispatch VIs can be set to protected, which is the only other meaningful scope for dyn disp -- it doesn't make sense to have a dynamic dispatch method that cannot be overridden by children.

    Hence the reason for my post. Dynamic dispatch VIs seem like a catch 22 with lvlib scope. You are forced to wrap the class to hide just a single VI.

    There is a valid use case for creating a wrapper class that has a reduced set of methods that wraps an inner class. This is done a lot in various programming languages to create a read-only version of the class, so the wrapper class only has methods for reading values, not writing them. You would then hide the core class inside the packed project library (making it private to the library) and expose your wrapper class only.

    For large projects, this seems like a lot of work to hide one or two dynamic dispatch VIs. It would be nice to control what VIs are visible/exported in the lvlib properties.

    Any thoughts? I may put this into the idea exchange...

  9. There are several types of responses (streaming and immediate). In my current code, I use several LV2 globals to hold the most recent 5 minutes of each type of data. In a particular test, I can retrieve the most recent value, all values, the next new value, etc.

    WIth AF, I can't figure out a good way to replace the LV2s. In the attached zip file, the main code is in "main.vi" and "SerialDevice.lvlib Actors Sim.lvclass Actor Core.vi".

    Any advice or analysis is appreciated. Note that some inheritance is there since the protocol can (and does) change often, and I need to maintain backwards compatibility.

    Where are the LV2 globals used in your code? How many of these devices will exist on a system?

    My advice would be that LV2 globals do not scale well to a system with "n" instruments. If it would be acceptable to store a fixed number of elements (rather than time-based), I would suggest using lossy queues.

  10. Paul_at_Lowell, on 09 February 2012 - 12:47 PM, said:

    OK, plug-ins, then.

    See this thread (http://lavag.org/top...5567#entry85567), where I think we concluded the best options are source distributions (yuck!) or packed-project libraries using the method mike_nrao describes. (There is a link to the solution in that thread, post #9).

    Thanks for the advice Paul, I share the same sentiments with source distributions... :angry:

    I am aware of the packed project library method from mike_nrao. I have been trying to avoid packed project libraries because I feel there are too many rough edges at this point. I just posted my concern regarding support in future versions of LabVIEW on the community page...

    For now I will stick with my work-around of generating path constants at build time...

×
×
  • Create New...

Important Information

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