Leaderboard

I never really messed with this feature much, so I had to write some test code to see. It appears the locking of the FP occurs on static events when the event occurs, not when it is dequeued. Same goes for dynamic control references, if the register has the "Lock Panel Until Handler Completes" by right clicking the register for events. As for user events, it appears this isn't an option because user events don't involve UI controls.

As a matter of fact, I have reorganized the sources a bit, packaged them as a project, and put them under RCS here: https://gitlab.com/enricosegre/LVVideo4Linux

Search Liskov substitution principle (abbreviated LSP in OO circles). Your #1 choice above is a violation of LSP, and therefore probably not a good idea. --- Using your case study of a signal generator configuration, let's consider our design dilemma centers around the ConPane of "Configure Signal Generator.vi", which is intended to be an abstract method of parent "Signal Generator.lvclass" marked as "Must Override" for implementation by all subclasses. As you point out, this method requires different arguments (input parameters) that are specific to the subclass. This dilemma has at least 3 resolutions that are correct: Use dynamic typing rather that static typing for input/output arguments. JSON is a good choice in 2014 that provides both strong typing and dynamic typing (as opposed to weak typing and static typing). XML is your second choice. INI is a suboptimal choice. Your Own Clever Protocol (YOCP) is a significantly suboptimal choice. LvVariant... exists as a choice (with editorial value judgement reserved at this time). Use dependency injection (DI) and/or constructor injection (constructor is sometimes abbreviated ctor). But! If the constructed object you are injecting can have purely by-val semantics with no by-ref or active object requirements, this could be a code smell. Specifically, since it represents an "OO purist" idiom of circumventing dynamic typing, which represents far less syntax and bloat. (Plus, joke's still on you! You've just deferred and complicated the exact same problem, abstracting the problem of concrete input parameters to the Configuration class constructors rather than implementation methods. Said another way -- object configuration is probably not best solved with DI in LabVIEW.) Acknowledge that "Configure Signal Generator.vi" is an inappropriate abstract method of the supertype, but should instead be reserved as concrete methods of subclasses that "look and feel like they ought to conform to an inheritance relationship but just don't because they don't really IRL and i accept this". There are more incorrect resolutions. Here are some obvious ones where I have tried and failed: Bloat the superclass with subtype-specific methods. Why is this wrong? This violates LSP, enables (encourages?) incorrect usage of subclasses, and throws run-time errors rather than compile-time errors. Bloat ancestor methods with descendent-specific parameters (input and output). Why is this wrong? This violates LSP, enables (encourages?) incorrect usage of subclasses, and throws run-time errors rather than compile-time errors. Inject Signal Generator Configuration.lvclass into the Signal Generator.lvclass "ctor" method (LabVIEW does not have canonical object constructors, hence air quotes around "ctor"). Why is this wrong? I was once excited to have "discovered" this solution, and gleefully coding the Configuration classes, only to realize, on completion of this dual hierarchy of redundancy, the exact same problem existed with the ctors of the Configuration classes. Use #1 or #2 "correct" solution above, when I should have chosen #3. After doing this many times, I realized eventually LVOOP might not contain sufficiently-expressive constructs to represent object models of my application domains. Mixins (or traits), available in modern OO languages, might be a solution, and a construct we could consider rooting for in LVOOP. YMMV! Hope this helps. All bolded terms are searchable.