How Interactor spawn others?
Marcos
it works.
I have see that: (correct me if I'm wrong please)
There are a interactor (TopLevelInteractor) that Handle application of
main form. ou would be any form? I think that would be of any form. This
interactor presumably handle events like onFormclose, ondDeactivate,
OnMouseXXX, OnKeyXXX, etc...
If the user click into a button the TopLevelInteractor will spawn the
MouseInteractor and the last one will spawn Buttoninteractor.
If I press a button shortcut the TopLevelInteractor will spawn the
KeyInteractor and the last one will spawn Buttoninteractor.
How the TopLevel knows wich Interator (mouse or key) spawn?
How the MouseInterator knows wich Interator (ButtonInteractor,
EditInteractor, ListViewInteractor, etc...) spawn?
A sample would be very good!
Thanks
Joanna Carter (TeamB)
429e...@newsgroups.borland.com...
> After many reads I think that the worst thing about MVP is discover as
> it works.
I did say that it wasn't simple :-))
> I have see that: (correct me if I'm wrong please)
> There are a interactor (TopLevelInteractor) that Handle application of
> main form. ou would be any form? I think that would be of any form. This
> interactor presumably handle events like onFormclose, ondDeactivate,
> OnMouseXXX, OnKeyXXX, etc...
>
> If the user click into a button the TopLevelInteractor will spawn the
> MouseInteractor and the last one will spawn Buttoninteractor.
>
> If I press a button shortcut the TopLevelInteractor will spawn the
> KeyInteractor and the last one will spawn Buttoninteractor.
>
> How the TopLevel knows wich Interator (mouse or key) spawn?
> How the MouseInterator knows wich Interator (ButtonInteractor,
> EditInteractor, ListViewInteractor, etc...) spawn?
From my research, it should not be necessary to have a top level Interactor
for the form if it is just to handle Buttons. Each of the buttons on a form
should be wired up directly to a Command in the Model for the object being
displayed on the form. In my MVP framework, Buttons implement the
ICommandGuiObject, as do Menu items. Due to the simplicity of anticipated
interaction between the Button and its related command, there really is no
need for the complexity of an Interactor. Any Button or MenuItem should use
the Observer pattern to detect when a Command is enabled/disabled; other
than that, there is only the need to hold a reference to a Command in the
Button and override the Click method of the Button or MenuItem to call the
Execute method of the Command.
But when it comes to handling of Edits, Lists, etc; this relies on the
Interactors that are listening to the controls also surfacing events or
being Subjects that are observed by the Form's Interactor.
If you try to pass interaction from a top level Interactor to
sub-Interactors, then this, I believe, is the wrong way round. Interactors
are reactive, not proactive and only listen for Gestures rather than
generating them, which is what passing control to sub-Interactors from a top
level Interactor would imply.
Now, within any Interactor system, there needs to be the ability to start an
interaction from one control to end in another, as in drag-dropping from a
control on one form to a control on another form. This involves the use of a
ScrapItem which is passed to an application scope "Scrapboard" (clipboard)
by the Interactor of the originating control and then picked up by the
Interactor of the target control when it detects a MouseOver message with
the mouse button pressed.
I think you are trying to design how to detect when a Control gains focus,
either by mouse or keypress.
Mouse activation is accomplished by using the Interactor attached to the
Control receiving focus to detect the mouse click; this Interactor also
publishes an event picked up by the Form's Interactor, which then sets focus
to the clicked Control.
Using the Tab key to move between Controls means picking up the Tab keypress
in the currently focused Control and publishing this as an event which is
picked up by the Form Interactor.
You also have to bear in mind that most Windows controls already have a
mechanism for handling control focus change and interfering with this could
be more hassle than it is worth. It would be better to activate a Control's
Interactor on a SetFocus message and deactivate it on KillFocus message.
Do these ramblings answer your questions, or am I missing your point ?
Joanna
--
Joanna Carter (TeamB)
Consultant Software Engineer
TeamBUG support for UK-BUG
TeamMM support for ModelMaker
Marcos
> I did say that it wasn't simple :-))
> From my research, it should not be necessary to have a top level Interactor
> for the form if it is just to handle Buttons. Each of the buttons on a form
> should be wired up directly to a Command in the Model for the object being
> displayed on the form. In my MVP framework, Buttons implement the
> ICommandGuiObject, as do Menu items...
Here I see a problem to my approach because I don't want derive the VCL;
> But when it comes to handling of Edits, Lists, etc; this relies on the
> Interactors that are listening to the controls also surfacing events or
> being Subjects that are observed by the Form's Interactor.
Good point. Then I do not pass interaction from top level interactors to
sub-Interactor, but the sub-Interactors stay listening interactors of
superior level and when it receive the notification they treat in
accordance with. I understand! :)
> I think you are trying to design how to detect when a Control gains focus,
> either by mouse or keypress.
> Mouse activation is accomplished by using the Interactor attached to the
> Control receiving focus to detect the mouse click; this Interactor also
> publishes an event picked up by the Form's Interactor, which then sets focus
> to the clicked Control.
But the windows do this for us already! I will have to intercept wndproc
of controls in this case?
> Using the Tab key to move between Controls means picking up the Tab keypress
> in the currently focused Control and publishing this as an event which is
> picked up by the Form Interactor.
I think that we will need get the kill focus. People have a constume of
not use tab key to pull controls.
> You also have to bear in mind that most Windows controls already have a
> mechanism for handling control focus change and interfering with this could
> be more hassle than it is worth. It would be better to activate a Control's
> Interactor on a SetFocus message and deactivate it on KillFocus message.
good!
> Do these ramblings answer your questions, or am I missing your point ?
:) U forgot samples, but I think that I can translate this letter for
code. Ah! U forgot the 8th article in your MVP serie :)
They are very good! Light me!
Joanna Carter (TeamB)
429e...@newsgroups.borland.com...
> yes, but i'm persistent!
As well as your data is ? <vbg>
> Here I see a problem to my approach because I don't want derive the VCL;
Then write wrapper/adapter classes that are created by the Commands when
they link up to a standard Button or MenuItem.
> Good point. Then I do not pass interaction from top level interactors to
> sub-Interactor, but the sub-Interactors stay listening interactors of
> superior level and when it receive the notification they treat in
> accordance with. I understand! :)
I think I disagree here, let me see, this should be...
Control Interactors are usually activated by the SetFocus message.
Form Interactors listen to Control Interactors not the other way round.
> But the windows do this for us already! I will have to intercept wndproc
> of controls in this case?
That's why I wrote the next bit...
> > You also have to bear in mind that most Windows controls already have a
> > mechanism for handling control focus change and interfering with this
could
> > be more hassle than it is worth. It would be better to activate a
Control's
> > Interactor on a SetFocus message and deactivate it on KillFocus message.
>
> good!
Joanna
Marcos
> Control Interactors are usually activated by the SetFocus message.
> Form Interactors listen to Control Interactors not the other way round.
Could you show us a piece of code or the interactor to get the focus of
control? I thought that the SetFocus (WM_FOCUSED) was perceived by Form
Interactor and this was spawn to control interactor.
Stephane Fillon
> should be wired up directly to a Command in the Model for the object being
> displayed on the form. In my MVP framework, Buttons implement the
> ICommandGuiObject, as do Menu items.
Bonjour Joanna,
Please correct me if i am wrong :)
Model
CommandSet
Commands
A Command can be bind to a TButtonView: class(TButton,
ICommandGuiObject,...) in the Presenter->BindCommands
This means that we should be able to retreive a Command from the
CommandSet by its name and same for the Button.
EX:
procedure TCustomerPresenter.BindCommands; (override)
var
bCommand: ICommand;
bView: IContainerViewCapability;
bGui: ICommandGuiObject;
begin
View.QueryInterface(IContainerViewCapability, bView);
if bView <> nil then
begin
bGui := bView.GetPropertyView('btnEdit') as ICommandGuiView;
bCommand := Model.CommandSet.GetCommandByName('EditCommand');
bGui.SetCommand(bCommand);
.... if we have more MenuItem/Buttons...
end;
end;
TButtonView = class(TButton, ICommandGuiObject, IObserver, IMVPView)
private
FCommand: Pointer; // Keep a reference of the Command
protected
// ICommandGuiObject
procedure SetCommand(const pCommand: ICommand);
procedure Click; override;
procedure Update(...); //Observer
...
end;
procedure TButtonView.Update(..)
begin
if Assigned(FCommand) then
Enabled := ICommand(FCommand).Enabled; // as pSubject should
always be FCommand
end;
procedure TButtonView.Click;
begin
if Assigned(FCommand) then
ICommand(FCommand).Execute;
inherited Click;
end;
I don't really like by BindCommands, but I can't see how to do it in
another way. I can't bind it in the Model as the Model will then be
coupled with the View.
Any suggestion :) ?
Stephane.
--
___________________________________________________________________
Stephane FILLON - mailto: fill...@yahoo.com.au
39 Balaton Street, Westlake QLD 4074 - Australia
Tel/Fax: +61 (07) 3279 7929
AACS: #3022270 - ICQ: #85420907 - Skype: graal72
GMT +10H