Command Pattern and Serialisation

[Charles Law]

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 an thoughts, or example of how this can be implemented,
ideally in VB.NET, but otherwise in any language?

TIA

Charles

[Charles Law]

Re: Command Pattern and Serialisation

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


"Charles Law" <blank@nowhere. com> wrote in message
news:eOv2BG0nEH A.2612@TK2MSFTN GP15.phx.gbl...[color=blue]
>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
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Command Pattern and Serialisation

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 StreamingContex t 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

"Charles Law" <blank@nowhere. com> wrote in message
news:epF1dJLoEH A.3324@TK2MSFTN GP15.phx.gbl...[color=blue]
>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
>
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:eOv2BG0nEH A.2612@TK2MSFTN GP15.phx.gbl...[color=green]
>>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
>>
>>[/color]
>
>[/color]

[Charles Law]

Re: Command Pattern and Serialisation

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 StreamingContex t, 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 TransmitCharact er [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 [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:eDYiPmNoEH A.3324@TK2MSFTN GP10.phx.gbl...[color=blue]
> 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 StreamingContex t 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
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:epF1dJLoEH A.3324@TK2MSFTN GP15.phx.gbl...[color=green]
>>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
>>
>>
>> "Charles Law" <blank@nowhere. com> wrote in message
>> news:eOv2BG0nEH A.2612@TK2MSFTN GP15.phx.gbl...[color=darkred]
>>>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
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Charles Law]

Re: Command Pattern and Serialisation

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 StreamingContex t, 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 TransmitCharact er [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 [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:eDYiPmNoEH A.3324@TK2MSFTN GP10.phx.gbl...[color=blue]
> 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 StreamingContex t 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
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:epF1dJLoEH A.3324@TK2MSFTN GP15.phx.gbl...[color=green]
>>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
>>
>>
>> "Charles Law" <blank@nowhere. com> wrote in message
>> news:eOv2BG0nEH A.2612@TK2MSFTN GP15.phx.gbl...[color=darkred]
>>>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
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Command Pattern and Serialisation

Charles,
If you are you using XmlSerializer, then the StreamingContex t will not work,
it is only used by the SOAP & Binary Serializers.

Have you considered making the receiver a parameter to the Command.Execute
method, instead of a property of the Command object?

Again I have not given this a lot of thought yet.

Hope this helps
Jay

"Charles Law" <blank@nowhere. com> wrote in message
news:OZQEZxPoEH A.3324@TK2MSFTN GP12.phx.gbl...[color=blue]
> 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 StreamingContex t, 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 TransmitCharact er [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 [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
> news:eDYiPmNoEH A.3324@TK2MSFTN GP10.phx.gbl...[color=green]
>> 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 StreamingContex t 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
>>
>> "Charles Law" <blank@nowhere. com> wrote in message
>> news:epF1dJLoEH A.3324@TK2MSFTN GP15.phx.gbl...[color=darkred]
>>>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
>>>
>>>
>>> "Charles Law" <blank@nowhere. com> wrote in message
>>> news:eOv2BG0nEH A.2612@TK2MSFTN GP15.phx.gbl...
>>>>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
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Command Pattern and Serialisation

Charles,
If you are you using XmlSerializer, then the StreamingContex t will not work,
it is only used by the SOAP & Binary Serializers.

Have you considered making the receiver a parameter to the Command.Execute
method, instead of a property of the Command object?

Again I have not given this a lot of thought yet.

Hope this helps
Jay

"Charles Law" <blank@nowhere. com> wrote in message
news:OZQEZxPoEH A.3324@TK2MSFTN GP12.phx.gbl...[color=blue]
> 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 StreamingContex t, 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 TransmitCharact er [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 [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
> news:eDYiPmNoEH A.3324@TK2MSFTN GP10.phx.gbl...[color=green]
>> 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 StreamingContex t 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
>>
>> "Charles Law" <blank@nowhere. com> wrote in message
>> news:epF1dJLoEH A.3324@TK2MSFTN GP15.phx.gbl...[color=darkred]
>>>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
>>>
>>>
>>> "Charles Law" <blank@nowhere. com> wrote in message
>>> news:eOv2BG0nEH A.2612@TK2MSFTN GP15.phx.gbl...
>>>>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
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Charles Law]

Re: Command Pattern and Serialisation

Hi Jay
[color=blue]
> Have you considered making the receiver a parameter to the Command.Execute
> method, instead of a property of the Command object?[/color]

Yes, I have. The problem with that (although I may end up doing it this way)
is that commands within a macro command may have different receivers, and so
the macro must now have access to all the receivers so that it can pass the
correct one. Furthermore, the macro must 'know' which command requires which
receiver.

Charles


"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:%23yUqLaRo EHA.3460@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> Charles,
> If you are you using XmlSerializer, then the StreamingContex t will not
> work, it is only used by the SOAP & Binary Serializers.
>
> Have you considered making the receiver a parameter to the Command.Execute
> method, instead of a property of the Command object?
>
> Again I have not given this a lot of thought yet.
>
> Hope this helps
> Jay
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:OZQEZxPoEH A.3324@TK2MSFTN GP12.phx.gbl...[color=green]
>> 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 StreamingContex t, 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 TransmitCharact er
>> [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 [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
>> news:eDYiPmNoEH A.3324@TK2MSFTN GP10.phx.gbl...[color=darkred]
>>> 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 StreamingContex t 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
>>>
>>> "Charles Law" <blank@nowhere. com> wrote in message
>>> news:epF1dJLoEH A.3324@TK2MSFTN GP15.phx.gbl...
>>>>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
>>>>
>>>>
>>>> "Charles Law" <blank@nowhere. com> wrote in message
>>>> news:eOv2BG0nEH A.2612@TK2MSFTN GP15.phx.gbl...
>>>>>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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]

[Charles Law]

Re: Command Pattern and Serialisation

Hi Jay
[color=blue]
> Have you considered making the receiver a parameter to the Command.Execute
> method, instead of a property of the Command object?[/color]

Yes, I have. The problem with that (although I may end up doing it this way)
is that commands within a macro command may have different receivers, and so
the macro must now have access to all the receivers so that it can pass the
correct one. Furthermore, the macro must 'know' which command requires which
receiver.

Charles


"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:%23yUqLaRo EHA.3460@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> Charles,
> If you are you using XmlSerializer, then the StreamingContex t will not
> work, it is only used by the SOAP & Binary Serializers.
>
> Have you considered making the receiver a parameter to the Command.Execute
> method, instead of a property of the Command object?
>
> Again I have not given this a lot of thought yet.
>
> Hope this helps
> Jay
>
> "Charles Law" <blank@nowhere. com> wrote in message
> news:OZQEZxPoEH A.3324@TK2MSFTN GP12.phx.gbl...[color=green]
>> 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 StreamingContex t, 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 TransmitCharact er
>> [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 [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
>> news:eDYiPmNoEH A.3324@TK2MSFTN GP10.phx.gbl...[color=darkred]
>>> 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 StreamingContex t 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
>>>
>>> "Charles Law" <blank@nowhere. com> wrote in message
>>> news:epF1dJLoEH A.3324@TK2MSFTN GP15.phx.gbl...
>>>>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
>>>>
>>>>
>>>> "Charles Law" <blank@nowhere. com> wrote in message
>>>> news:eOv2BG0nEH A.2612@TK2MSFTN GP15.phx.gbl...
>>>>>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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>[/color]
>>
>>[/color]
>
>[/color]