Report Interfaces and actor framework in Object-Oriented Programming Posted October 6 13 hours ago, peper said: EDIT: re-reading your answer I am not sure I'm following you on this: "Also., from a design perspective, your Controller should NOT be implementing (inheriting) the updateStatus capability - that rests with the Writer." Could you elaborate? I misread and misinterpreted your usage of the 'UpdateStatus' message in the Writer - I thought that you were looking to 'write' the status value of the Reader's UpdateStatus into the TDMS file using the Writer's UpdateStatus message. Looking at the pictures above; the code samples, and re-reading your OP, it's clear now that you want both nested actors to apprise the caller of their respective status. My comment is totally invalid. Regarding your primary issue though, You could break up UpdateState.vi into the names you already indicated. E.g. Acquiring.vi; Writing.vi, etc. This way, the messages will not have any additional inputs in the connector pane; and the Controller will know exactly what to do when it receives a specific status message, without the need for case-structuring. (With UpdateState, I assume that you would need to case out your next action in the Controller based on the input state value.) From a reusability perspective, one could end up with a similar, if not same, problem if multiple nested actors of the same class are sending their status to the Caller. E.g. If using multiple Writer actors to write to TDMS files concurrently, how would the Controller know which nested Writer is reporting its status; unless the status message includes some form of identification of the nested actor (say nested-actor's enqueuer). I encountered a variant of the problem you posed, whereby I made various instrument actors (PowerSupply, Chiller, VacuumController, etc.) implement a Connectable interface with messages for connect and disconnect. That was easy. But, when I wanted to convey their status - connected and disconnected - to the caller, I was stuck. I ended up following a bit of advice from another post (can't find it now). The gist (as I understood it): the caller 'trusts' that the nested actor has performed the requested action. If the nested actor has not, it will send a well-defined error report. Exception handling is then done according to the problem domain. As a result, I didn't use 'connected' and 'disconnected' type state messages any more.