Search the Community
Showing results for tags 'dynamic dispatch'.
Found 4 results
-
I've run across an interesting difference in how LabVIEW 2016 works with dynamic dispatch VIs compared with 2015. If you put the class wire on a shift register of a loop and then have an event structure inside it and in one of the event cases instead of wiring the shift register through, you wire whatever value was originally put into the shift register through (you might do this if you're making a dialog to configure the class and want to let the user cancel it without affecting any changes) it breaks your VI - it doesn't consider this to be a "good enough" way of wiring your dynamic dispatch -
I am trying to wrap my head around something i've been dealing with lately: I want to implement a "Messenger" Class for facilitating a switch of communication interfaces in my programs. Basically my current thought process is that I have: - A parent class called "Messenger" with the methods: initialise(?), connect(), [U8] recieveData(), sendData([U8]), disconnect(), that I can use in my code. - A child class "TCP Messenger", which overrides the methods: initialise(IP, Port, Timeout, DVR, ConnectionType), connect(), [U8] recieveData(), sendData([U8]), disconnect(). - A child class -
Hello All, Long time reader, first time poster. I have learned a lot from lavag, and really appreciate what you all do here. I am building an LVOOP architecture that sort of straddles the line between AMC and AF. One of the most frustrating things I have run across (as with most AF type architectures) is debugging shared clones. I've run into some behavior that I did not expect and wanted to see if anyone knew what was going on. First some definitions: Behavior A: Opening a Shared Clone Reentrant subVI from the block diagram of a running VI opens the original, "uncloned" VI, r
-
Hi, Here comes a rather basic question but which I'm always struggling with since you can often argue both ways. Hopefully some of you have a few nuggets to share here... 1) A parent class should have no knowledge of any child class' concrete type, i.e. only data and methods that is inherently common to all decendents of that parent should be defined by it. 2) For dynamic dispatching to work the parent class must define virtual methods for dynamic dispatchees to work from. Those two rules often contradict each other. Methods vetted against 1) will often eliminate the possibility
