Background process with NotifyIcon using the Actor Framework

[KvZ]

I've been following the Actor Framework a while but just recently started a project where I could start to use it and I tough I share the code for feedback / as example / reuse.

My application needs  PXI_Clk10 Disciplining, which is a software control loop that runs in the background. I Implemented this in an actor with a simple UI that displays the basic status of the control loop. The Idea is that you can use this actor in a larger application but that it is also possible to build and used as an stand alone application. Since it's a background progress it did not make sense to have the UI always visible for this I used a NotifyIcon to add the application to the System Tray.

I put the general NotifyIcon code in a parent class 'NotifyIconBase.lvclass' that inherits form Actor. So I can reuse this for other Actors by inheriting for 'NotifyIconBase.lvclass' instead of the Actor. The NotifyIcon can be controlled trough protected Methods and Properties from the Child Class.

The NotifyIconBase class API allows:

- Specifying the NotifyIcon's Icon/Text/Visibility

- Showing Tip Balloons on the Icon

- Manage right click Menu & Menu Items

- Register Messages to be sent on NotifyIcon events (Using Self-Addressed Messages).

- Access to the .Net References for customization (See the MSDN library for full documentation on how to use these references.)

The NotifyIcon it self is part of the .Net Framework 2.0 and later (System.Windows.Forms.NotifyIcon). This Object is created in the NotifyIconBase.lvclass:Pre Launch Init.vi and destroyed in the NotifyIconBase.lvclass:Stop Core.vi. If the child class overrides these methods the NotifyIconBase.lvclass requires that they call the parent to ensure the NotifyIcon Object is created and destroyed during normal execution of the Actor.

Attachments:

- NotifyIcon Actor.zip

     Contains the NotifyIconBase.lvclass and a Example Actor

- PXI_Clk10 Disciplining Actor

     This contains the Clock Disciplining Actor and a copy of the NotifyIconBase.lvclass.

Software Requirements

- Actor Framework 3.0.7

- Microsoft .Net Framework 2.0 or later.

- NI-Sync 3.3 (for PXI_Clk10 Disciplining Actor)

- NI System Configuration 5.0 (for PXI_Clk10 Disciplining Actor)

NOTE: Creating LabVIEW Application that can settle in the System Tray

By default a Build LabVIEW Application keeps a root window active even when all frond panels are closed / hidden. To hide this window when all Front Panels are hidden you need to add the line hideRootWindow=True too the Applications INI file. This way the application will behave like any application that settles in the System Tray. The attached code contain build specifications in the project that show how to do this during build by using a custom ini file.

The attached Code is provided As Is.  It has not been tested or validated as a product, for use in a deployed application or system, or for use in hazardous environments.  You assume all risks for use of the Code and use of the Code is subject to the Sample Code License Terms.

[GregFreeman]

I put the general NotifyIcon code in a parent class 'NotifyIconBase.lvclass' that inherits form Actor. So I can reuse this for other Actors by inheriting for 'NotifyIconBase.lvclass' instead of the Actor. The NotifyIcon can be controlled trough protected Methods and Properties from the Child Class.

With my relatively limited OOP knowledge (and without looking at your code), I am not sure that this is the best way to do this. As far as I've always been told, inheritance should have an "is a" relationship. I'm guessing your actors inheriting from notifyicon are not some kind of notify icon. You may be better off creating a notify icon class and passing that class to your actors that need access to it.

[KvZ]

I agree, I was to focused on pure UI based objects when I implemented this part. Which actually only is true for a small number of actors if at all, come to think of it.

I was already planning a revision when I needed to intergrate the PXI_Clk10 Actor.

[Daklu]

for(imstuck) wrote:

As far as I've always been told, inheritance should have an "is a" relationship.

<hijack>

I learned this rule of thumb as well and it seems to be firmly entrenched in any discussion teaching object-oriented principles.  To be honest, I think it does far more harm than good.  People learning OOP believe they understand when to use inheritance and end up creating poor designs.  For example, everyone knows a circle "is a" form of an ellipse.  Based on the "is a" rule we naturally believe a Circle class should inherit from an Ellipse class.  This is a classic issue known as the Circle-Ellipse Problem.  More specifically, it arises when the Liskov-Substitution Principle (LSP) is violated.

New OOP developers often create class hierarchies that follow the "is a" rule but are full of LSP violations.  Because the class hierarchy follows the "is a" rule, the developer never thinks to question the design.  Working around the consequences of LSP violations causes confusing code that is hard to maintain.  In some cases people give up on OOP altogether because they never see any of the promised benefits.

I suspect the "is a" rule grew out of a desire to explain inheritance to those unfamiliar with it.  Unfortunately it goes beyond just explaining what inheritance is and does, and tries to explain when it should be used.  In my opinion it falls well short of that mark.  On the whole I think inheritance is over-emphasized in beginning OOP literature.  People would be better served by being introduced to SOLID design principles early on rather than being told inheritance is an "is a" relationship.

(Note - Don't interpret this as comments on the OP's design or code.  My intent is to steer others away from the difficulties I ran into based on the belief inheritance == "is a.")

</hijack>

[AristosQueue (NI)]

> <hijack> ... </hijack>

The "is a" is actually shorthand for one of three separate tests. The three tests are Identity, State and Behavior, and "is a" covers only Identity.

If something is a child object, it "is a" parent object. That is true. The problem is that people reverse the proposition and say "if X is a Y, then the classes should inherit." Instead it should be "if X is not a Y, then the classes should not inherit."

[AristosQueue (NI)]

PS: If the linked article from Daklu about the LSP looks daunting at the start, scroll down to the section with the title "Principle". It's very plainly written and is a very good think to know for OO.

[Daklu]

AristosQueue wrote:

The "is a" is actually shorthand for one of three separate tests. The three tests are Identity, State and Behavior, and "is a" covers only Identity.

I understand Identity, State, and Behavior are the three cornerstones of objects, but I don't understand how those translate into tests for deciding whether or not to use inheritance.  Can you explain?

AristosQueue wrote:

The problem is that people reverse the proposition and say "if X is a Y, then the classes should inherit." Instead it should be "if X is not a Y, then the classes should not inherit."

I almost wrote, "An 'is a' relationship is necessary but not sufficient for inheritence" which I think is what you're saying. I decided against it because there are times when an 'acceptable' inheritance relationship is created that goes way beyond the common understanding of "is a." For example, I can't figure out how a condiment decorator has any relationship whatsoever to a real world object like a beverage, much less claiming it "is a" beverage. The condiment decorator is what it is--a software construct used to extend the functionality of an application. Furthermore, the "is a" relationship propogates down through the class hierarchy, so each of the concrete condiments should satisfy the statement, "condiment is a beverage." Clearly that won't be true for all condiments.

So then the proposition should be, "if X is not a Y, then the classes should not inherit--except when they should."  Kinda loses its effectiveness as a decision-making tool... 

[AristosQueue (NI)]

In the decorator example, the name of the class in a more real-world example would have been "Drink with condiment added.lvclass". Ok, probably not so wordy, but that's the sense of it. David went with "Condiment decorator" to highlight which class was doing the decorating, which otherwise might get lost.

The "necessary but not sufficient" phrasing is definitely something I would say is true.