Hi Jay
I appreciate your response. If I understand the pattern correctly, it is
usual to provide a reference to the receiver when the object is created.
Because I am deserialising the commands from an xml file, I cannot
provide the receiver at the time the object is created.
There are three receivers, and any one command will (probably) only
require one of these candidate receivers.
I'm not familiar with the StreamingContext, but I could not deserialise
the receivers if that is what you mean.
I am loathe to use a singleton in this case because it is really just a
global by another name. I am wondering if there is a technique within the
pattern for setting the receiver at a time other than at object creation.
What is going to happen, in practice, is the user will select a task from
a list, and then set the task running. The task here is composed of a
number of steps, or commands, which are defined in the xml file. A
trivial command would be Wait, where the task sleeps for x milliseconds,
defined in the file. The user can change the number of milliseconds just
by editing the file. A less trivial command might be TransmitCharacter
[out of the serial port]. In this case, the response has to be tested,
and if it is not the expected response the user needs to be alerted and
asked whether to continue. Again, the user can edit the file and change
the character to transmit, and the response. The commands may even be
re-ordered, or others added. These commands make up the task, and success
or failure of the task will be determined by success or failure of the
individual commands.
Charles
Jay B. Harlow said:
Charles,
I've left this thread unread, hoping to find time to give it some
thought.
What do you mean by "passing a receiver" in? Is there going to be a
single receiver or multiple?
What kind of serialization?
Can you use either the StreamingContext in System.Runtime.Serialization
or a singleton to "set" the receiver? It may mean you will need to
implement ISerializable.
Just remember I have not really taken the time to think about this yet.
Hope this helps
Jay
I was hoping that someone might have some views on this. It would be
nice to at least discuss possibilities for the way forward.
Another problem I am facing is how to handle responses from the
commands, or success and failure of commands. It might be that a
subcommand (within a macro) fails and the user needs to be prompted
whether to continue. Would this be best accommodated using an event, in
the style of the Observer pattern, or is there a better established
method? And what if the Execute method returns a value, would that be
passed on the same way?
Thanks anyone.
Charles
I am implementing the command pattern in VB.NET, where the commands
have been serialised. That is, I have several classes that all inherit
from my base Command class, that implements ICommand (standard stuff).
The commands, however, are deserialised at runtime, so the idea of
passing a receiver in the constructor does not work in this case.
In addition, I am implementing the MacroCommand extension, and each
command in a macro could require a different receiver.
Does anyone have any thoughts, or example of how this can be
implemented, ideally in VB.NET, but otherwise in any language?
TIA
Charles
