Amir_Y

Two things here: 1. Strictly thinking you are right about eliminating enums and case structures, but in my opinion, you should sometimes use them to improve readability and access. Enum is easy to read. Case structure is easy to access. When you open the action wrapper VI, you know which action you are looking for. Finding it in the case structure is much easier (and readable) than than double-clicking a dynamic dispatch VI which open a dialog where you have to look for the desired action. 2. "Do Core" VIs as part of the message seems a mix-up to me. The action should be done by dynamic dispatch methods of the ATM, so each inherited ATM could preform the action differently. Message object should only transfer the message (and it will be the same to all ATMs). Amir.

Hi Aristos Queue, First of all, thank you for posting your solution. At last we can see some simple examples of LVOOP. There are two things I would have done differently, one major the other minor: 1. The (action wrapper VI) would be a method of the "ATM.lvclass". The "ATM Massage.lvclass" would only be used for transfering the massage, not for doing the action. The massage would contain typedef enum named "Action" as private data. see here. Inside the case structure I would put dynamic dispatch VIs for handling the actions, so ATMs that will inherit from a more generic ATM would override these actions if needed. The massages will remain the same for all ATMs. So, my point here is: The action should done by the ATM not by the Massage. 2. I would make the massage event data type a typedef enum. It will be more strict and readable then free text. Regards, Amir Y.

You can use the default data directory VI for both ("Dflt Data Dir.vi" located at the "File Constants" pallet) . it will return a common path like: "C:\Documents and Settings\User_Name\My Documents\LabVIEW Data".