Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 08/30/2016 in all areas

  1. Because the XNode features of LabVIEW require a special license by NI, these properties and methods won't be listed on the XNode, or XNode Library class, but these functions do work. I made a post about this a while ago, and showed how to create these functions in vanilla LabVIEW if you use scripting, or use the QuickDrop function and know the name of the property or method you want. The code I posted also can create a new VI, or place the hidden property or method in your clipboard. I also posted a VI with all the properties and methods that scripting can make which you can use and copy into a VI and use.
    1 point
  2. You can also wrap the dedicated inits in a polymorphic VI to give the appearance of a single init (with different inputs-unlike a class) and maintan the design time polymorphism of the class.
    1 point
  3. I spent many hours trying to solve similar problems only to come to the conclusion that the solution I'm looking for makes no sense logically. Asking for Dynamic dispatch to take care if which VI to call is only valid if the connector pane in invariant. As soon as the connector pane is no longer invariant, then Dynamic Dispatch alone cannot know what to do. You can either move to a generic dat ainput type (A solution I personally am not fond of) or you can implement some VIs to pass in arguments BEFORE calling "Initialise" (as others have pointed out). The second version has the advantage of allowing a new "Initialise" to be called ont he object whenever you might want that as all of the parameters are internalised. I wouldn't do this as it doesn't solve your problem, it actually only makes it worse because instead of casting from Variant to whatever data you require in your ACTUAL Initialise funciton, you are trying to cast objects which is (AFAIK) less efficient. Doing this with classes versus variants brings nothing new to the table. You can still wire in the wrong configuration class and get run time errors. The option with internalising the parameters into the object before calling "Initialise" can at least catch type errors (even if it can't catch missing VIs to set certain properties). Of course the other option is to have a dedicated "Initialise" method for each class and ditch Dynamic Dispatch for this function altogether. By designing an "Initialise Device X" and "Initialise DEvice Z" methods independently of each other, you can then have the connector pane exactly as you require it with inputs declared required and strict typing. Of all the methods mentioned here (assuming re-initialisation is not a big need) I would simply create non-dynamic dispatch initialise VIs.
    1 point
  4. You should be able to use the OwningVI property (and then VI Path/Name or similar) wired to the XNode ref in an OnDrop Ability VI. It won't work in Initialize which is called before the XNode is dropped, so the VI is not known then. Also, no VI name/path is known if the VI is not already saved, which could be common. You may be able to check the Library of the OwningVI for it's project/class which may be helpful.
    1 point
×
×
  • Create New...

Important Information

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