Leaderboard

You can have an abstract class that implements some concrete logic. Since it is functionally irrelevant from a compiler perspective the important thing is to communicate the intent of the class to other developers. One technique I use in this scenario is to alter the class icon to a wire-frame cube (rather than a full cube) using GDS which indicates that the class is not intended to be instantiated but exists only to specify a common interface for concrete children and implement some common behavior.

I would say putting common logic in the parent is desirable behavior. And I don’t mind if some children will want to override the default parent behavior. For example, I have a project at the moment that uses cameras and “lockinâ€, the extraction of a periodic signal in the image. Most concrete camera types just override the "Get Image" method, and the parent’s "Get Lockin Image†method uses "Get Imageâ€. But one camera model has a built-in lockin mode, so I override “Get Lockin Image†in that case.

You aren't really "breaking" any good-practice rules in OOP design. There is nothing inherently wrong with have common functionality in an abstract parent - as long as you are comfortable that this will always reasonably be the case for all child implementations. If you come up against scenarios where children are over-riding methods just to inhibit parent behavior then you are definitely seeing a code smell - your hierarchy is making assumptions about behavior that are not true for all children. One of the most important guidelines for OOP design is to favor composition over inheritance for exactly this reason - inheritance enforces behavior that isn't always appropriate. The guideline encourages small, focused hierarchies of classes and then using composition where needed to add functionality without impacting the hierarchy. Unfortunately OOP development in LabVIEW is cumbersome compared to other languages, so we can all be forgiven for taking a short-cut where it is simply more expedient. EDIT: If you are new to OOP development, I encourage you to read through these if you haven't already: http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod http://javarevisited.blogspot.co.nz/2012/03/10-object-oriented-design-principles.html

Yup. The NI installer is kinda limited. So I usually wrap the NI install, into an Inno Setup installer for when I need more cusomization. This can do things like have Full, or Custom installs, and of course installation location control. I usually use ISTool to make, making one of these easier.