Jump to content

JKSH

Members
  • Posts

    497
  • Joined

  • Last visited

  • Days Won

    36

Posts posted by JKSH

  1. Hi John,
     
    Are you designing a generic framework, or a specific application?
     

     

    If Actor A has a message (that in turns calls a method in Actor A) to create an instance of Actor B, then adding Actor A to a project create a static dependency on Actor B.  This makes it impossible to test Actor A in isolation with a test harness.  The recent VI Shots episode about AOP discussed the need to isolate Actors so they could be built and tested as independent 'actors'.  If Actor B also has the ability to launch Actor C, then Actor C also becomes a dependency of Actor A.  And if Actor B sends a message to Actor A, then the static link to that message (required to construct it) will create a dependency on Actor A for Actor B.  So, the end result is adding any actor in your project to another project loads the entire hierarchy of actors into memory as a dependency and makes testing anything in isolation impossible.

     

    A static dependency doesn't necessarily preclude testing in isolation.

     

    Let's say we have 2 classes (A and B), where some of Class A's actions involve launching an instance of B and exchanging messages with it. Your unit tests could look something like this:

    • Class B testing:
      1. Launch an instance of Class B from a top-level VI
      2. Let your top-level VI send a variety of messages to your B instance, and check that it reacts appropriately
    • Class A testing:
      1. Launch an instant of Class A from a top-level VI
      2. Let your top-level VI send a variety of messages to your B instance, and check that it reacts appropriately

    (For even better isolation, launch a new instance for every message tested)

     

    Yes, the Class A tests will also cause Class B to be loaded and launched, but your test harness for Class A doesn't know that Class B is involved at all. Some might classify the Class A test as an Integration test rather than a Unit test, but the bottom line is that you can still treat Class A as an isolated black box.

  2. Hi Tom,

     

    Does it help if you call TDMS Flush.vi after you write the property?

     

     

    Sharing a single reference would solve this particular problem.  It would also add more messaging overhead.  The process that closes the reference would have to notify the other processes and wait for acknowledges before it could safely close the reference.  Otherwise another process could attempt to access the TDMS file with a bad reference.  

     

    To avoid race conditions, you'd need some form of messaging/synchronization anyway: You need to ensure that your Read VI waits for your Write VI to finish writing the property first, before it tries to read it.

  3. Thanks for your answers, everyone!

    Creating a VI based on an existing template and then replacing placeholder components was a clean and easy way to do things.

     

    You can always check out NI's GDS.

    Look in VI:

    C:\Program Files (x86)\National Instruments\LabVIEW 20xx\resource\Framework\Providers\Symbio_GDS\ClassProviders\Provider_LvNativeClass\ClassWriterNative_class\CreateMethod.vi

     

    I haven't installed the GDS; I believe it will be part of LabVIEW 2014? Anyway, thanks for the lead. I'm sure there's lots of gems to be found inside when I need to dig deeper.

  4. Hi all,

     

    I'm trying to programmatically create and modify LVClasses. So far, I've managed to do the following via LabVIEW scripting:

    • Create a new LVClass
    • Save the new LVClass to disk
    • Make one LVClass a subclass of another
    • Create property definition folders

     

    My next step is to create class methods (static dispatch for now), but I'm stuck. I can't figure out how to add an LVClass control/indicator to a VI. I tried the following, but LabVIEW complained, "Type mismatch: Object cannot be cast to the specific type".

     

    TTkTrDq.png

     

    I can't find any other LVClass-related items in the list.

     

    I tried to figure out what I should pass to New VI Object.vi, by querying an existing static dispatch VI as follows:

    bTx0Goa.png

     

    Apparently, the FP elements I want are called "LabVIEWClassControl", and they have a ClassID of 102. However, "LabVIEWClassControl". isn't available in the list. When I wired 102 into New VI Object.vi, I was told "The specified object was not found."

     

     

    How do I programmatically drop an LVClass control/indicator into a VI? More fundamentally, how do I script a new static dispatch VI?

     

    Thanks in advance!

  5. Thanks, rolfk!

     

    I tested your fix with Michael's test cases (with "ignore duplicate delimiters?" both TRUE and FALSE) -- they all produce the correct results.

     

    Do you know when this will make it into the VIPM?

     

     

    SourceForge is the best starting point in addition to this forum. However the project has not developed much over the last couple of years (there are quite a lot bugs filed with no development for almost a year). You could fork the project for your own purposes and upload patches as you file bug reports or maybe become part of the team yourself (if one of the members would allow that).
    The project might be dead, if none of the developers is interested in continuing it. In that case you could still fork the project, but there is little chance that anybody would benefit from patches (unless there is a way to fork a project and upload new versions to the VI Package Network...)

     

    I'd rather not fork, to avoid fragmentation. Do you know if there's a way for non-members to submit patches?

  6. A bit late to the discussion, but I'd like to add: I use comments to document the assumptions made when writing a section of code. As a piece of software grows (or if code is copied into another project), some earlier assumptions may need to be revised.

×
×
  • Create New...

Important Information

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