Jump to content

todd

Members
  • Posts

    335
  • Joined

  • Last visited

  • Days Won

    13

Posts posted by todd

  1. ... i'm doing some slow code (100ms) before I execute the call to parent in the actor core ...

    Are you sending the nested actor's VI ref to the parent for insertion into the subpanel? If so, I suppose the caller's insert method doesn't do anything else? Even so, is there a chance the caller is busy with other methods and doesn't get to the Insert in a timely fashion?

     

    If i had slow code in pre-launch init, then it would slow down launch actor. However, in my case, both actors had identical pre-launch inits.

     

    I tried putting config file reads in pre-launch init, for a while - then I stopped doing that. My pre-launch inits are very lightweight, now.

     

    Lately, I send the subpanel ref to the actor in its class data before calling launch. If the nested actor sees that it's a valid subpanel, it inserts itself. Otherwise, it opens its FP - or remains headless. A subpanel ref can be sent in later, if needed.

  2. A gentle reminder: sending in reports when the NI Error Reporting dialog pops up helps us make future versions of LabVIEW more stable!

     

    You should have several from me from last night :).

    2012 kept crashing, then hanging. Forcing recompile on each Actor Core.vi, saving all, mass-compiling (for good measure), and restarting LV eventually got it working again. I think the troubles began when I changed some reference controls in a STD that is part of the private data in one of the actors. (I can submit this project to NI, if that's useful. Maybe if I get a repro, first.)

  3. Theory and simple example code complement each other. Maybe one way to go is to show a simple implementation of a particular concept in each AOP style: AF, AA, QSMLH (queued-state message-loop handler).

     

    As to the multiple choice question: all of the above. :)

     

    Actually:

     

    2.a+e: A few simple sample actors, where each one has a different type of helper loop: no loop, self-messaged loop, free-running (timeout) loop, etc.

    2.c+d+b: A few simple message types: raw-queue producer-consumer (data only), queued message (command + data), AF message. MAYBE self-addressed messages: pass a notifier with the queued element, etc.

     

    Have I used the word "simple" enough? :)  Keeping the code simple makes it easy to understand quickly. Then, switching between the different methods allows the theory to stay in my mind. After seeing Jack D's events presentation, I understand why people were saying such good things about him. He showed many ways to make things happen, and they were all simple. The cooler example is too involved to quickly understand - the theory would get lost under the wires (unless one already knows AF, in which case simple code can teach the theory just as well as more complex code).

     

    If you want, I'd be happy to code up some simple AF examples that correspond to the functionality of some AA examples (maybe AgAc, instead?). Plenty of people can do it better than me, but I can handle simple!

  4. "The biggest problem with showing example code is people fixate on the implementation details instead of the principles being taught."
    "My perception is most people learn LV largely on their own."
    "... I do sometimes worry about the consequences of teaching my competitors how to be better programmers."

     

    These statements have convinced me to not ask for code. This morning I was thinking, "Well, how will these lone-rider developers learn to manage their breathing on long shots if they're busy shooting snakes from the hip." (Then I had some coffee.) I learned LV on my own (if reading info-labview and lava during 6i counts as alone). Theory was great, but example code was golden. Only after seeing the data flow through the wires did the theory turn into something useful.

     


    "I put that quote in my sig because I thought it was funny."

     

    It is funny. When I mentioned it earlier, I was whining (on the inside) about Staab not sharing his presentation. He posted a top-level actor launcher, once, that I learned a lot from (read: totally stole). I haven't provided anything to the community, so I'll quit waiting for other people to show me how to code.

     


    "Believe it or not I don't hold back information I think would benefit other developers in the community."

     

    Lapdog taught me a lot, too (thanks!). Presentations are all about the audience. Talking theory is useful, unless I don't know how to turn it into wires.

  5. Just watched the video, Dave. I liked it! It is a good summary of the terms and thought processes that you and others have discussed here on Lava over time. It made me feel good to be able to understand what you were talking about. As for improvement, I agree with Neil that examples would do a lot of good for spreading around "proper" AOD.

     

    Thank you for allowing the talk to be published. I'm a bit oblivious to the job-security aspect of "Never tell everything you know." I'd rather work myself out of a job by doing it well or by teaching someone else to do it.

  6. Any event generated will reset that timer so if a user spams the keyboard where the event structure handles key down, the timeout may never happen. This functionality slightly changed in 2013. I haven't tried it but I heard the timeout isn't reset with dynamic events anymore.

    Point of clarification: an event that is registered with an ES that DOES NOT have a case in the ES (unhandled), will not reset the timeout. In 2012, events that were registered but unhandled would reset the timeout.

  7. Aha! jlo got (at least) one in. Is it above or below the attribution?

    http://zone.ni.com/reference/en-XX/help/371361K-01/lvupgrade/labview_features/

     

    Application Builder Enhancements Automatically Selecting NI Software for Installers

    noloc_ico_idea_exchange.png  When you build an installer in LabVIEW 2013, LabVIEW automatically selects installers for the drivers and other software components required by the built application. Use this feature to reduce the possibility of building an installer without the right components. To disable this feature, remove the checkmark from the Automatically select recommended installers checkbox on the Additional Installers page of the Installer Properties dialog box for the installer.



    [idea submitted by NI Discussion Forums member jlokanis]

    Creating Directory Versions in Build Specifications

    In LabVIEW 2012 and earlier, if you create a build specification, LabVIEW does not include the build version number in the directory path on disk. In LabVIEW 2013, you can use tags in the build destination path so LabVIEW automatically includes the build version in the directory path. You can include the [VersionNumber] tag in the Destination path field on the Destinations page or the Destination directory field on the Information page of the build specification properties dialog box.

    • Like 1
×
×
  • Create New...

Important Information

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