Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 07/06/2010 in all areas

  1. I wouldn't bother with individual controls, even if you're going to do this fairly often. It should probably not take long to execute if you defer updates. Based on your description, I would say you should get the references to all the controls on the FP once (using the Controls[] property or, if you have nested controls, using <vi.lib>\utility\traverseref.llb\TRef Get All FP References.vi) and then build the controls you don't want to reset into an array and remove them from the first array using a for loop. You now have an array of all the controls you want to reset which you can go over in a for loop. You can call the reinit method for each one.
    1 point
  2. You can make Object methods reentrant. If you configure the reentrancy to allow instances to be allocated dynamically, you should be able to spawn as many versions of the VI as you need. If reentrancy is something that is new to you, I can elaborate. However, in the example you show, graphDisplay.vi runs synchronously, execution won't continue in the calling VI until graphDisplay.vi returns. Even once reentrancy is set, you still will only have one running VI showing at a time, other front panels won't be executing (might be what you want though?). If the VI needs to keep running, you'll need to create a wrapper VI that launches graphDisplay.vi asynchronously so you can have N instances of the VI spinning in memory simultaneously. Making an asynchronous call isn't too complicated, here's a screenshot from a framework I use that does exactly that: The key is to supply a value of 8 when opening the reference, which allocates the necessary data space and prepares the VI to allow multiple calls, then when using the Run VI method, to not wait until the VI is finished. Does that help?
    1 point
×
×
  • Create New...

Important Information

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