BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  Modeless dialog in MVC          BorlandTalk.com Forum Index -> Delphi OO design View previous topic :: View next topic   Author Message George Newton Guest Posted: Tue Jan 18, 2005 10:19 pm    Post subject: Modeless dialog in MVC I'm using a variation of MVC. My app has many dialogs and they are all modal - so far. Now I need a modeless dialog and I don't understand how to accomplish that using my current controller scheme for modal: TctlrDlgMyModal = class(TctlrDlg) // derived from TComponent private FDlgMyModal: TDlgMyModal; // derived from TForm ... protected ... public ... property DlgMyModal: TDlgMyModal read FDlgMyModal write FDlgMyModal; ... end; procedure TctlrMyMain.OpenMyModalClick(Sender: TObject); var ctlrDlgMyModal: TctlrDlgMyModal; begin ctlrDlgMyModal := TctlrDlgMyModal.Create(Application); try if ctlrDlgMyModal.DlgMyModal.ShowModal = mrOK then begin ... end; finally FreeAndNil(ctlrDlgMyModal); end; end; If I design the constructor of TctlrDlgMyModeless to create the form, and add an OnClose to caFree the form, then the event below will create the form, but it does not make 'sense' to me: The Modeless form stays open (as it needs to), but the controller with all of it's events for the form has been freed. procedure TctlrMyMain.OpenMyModelessClick(Sender: TObject); var ctlrDlgMyModeless: TctlrDlgMyModeless; begin ctlrDlgMyModeless:= TctlrDlgMyModeless.Create(Application); try ... finally FreeAndNil(ctlrDlgMyModeless); end; end; How might I design this so that ctlrDlgMyModeless is not freed until the form/dialog is closed? Also, my understanding is weak about creating multiple instances of these dialogs with ctlrDlgMyModeless (or anything else) using only a local variable. Any help understanding this will also be appreciated. -- George Newton Back to top Guenther Wimpassinger Guest Posted: Wed Jan 19, 2005 11:26 am    Post subject: Re: Modeless dialog in MVC "George Newton" <georgen (AT) xthis (DOT) pobox.com> schrieb Quote: If I design the constructor of TctlrDlgMyModeless to create the form, and add an OnClose to caFree the form, then the event below will create the form, but it does not make 'sense' to me: The Modeless form stays open (as it needs to), but the controller with all of it's events for the form has been freed. procedure TctlrMyMain.OpenMyModelessClick(Sender: TObject); var ctlrDlgMyModeless: TctlrDlgMyModeless; begin ctlrDlgMyModeless:= TctlrDlgMyModeless.Create(Application); try ... finally FreeAndNil(ctlrDlgMyModeless); end; end; The form is still available because you don't free it in the destructor of TctlrDlgMyModeless, guess? You can pass the instance of ctrlDlgMyModeless to you form and in the OnDestroy of the form you also free the ctlrDlg (but then you are not allowed to free form in the destructor of ctlrDlg) and creatin will be just begin TctrlDlgMyModeless.Create(Application); end; Yor Form declaration TMyDlgModeless = class(TForm) .... procedure FormDestroy(Sender:TObject); private fController : TctlrDlgMyModeless; public constructor Create(AOwner:TOwner;AController:TctrDlgMyModeless);override; end; constructor TMyDlgModeless.Create(AOwner:TOwner;AController:TctrDlgMyModeless); begin inherited Create(AOwner); fController := AController; end; procedure TMyDlgModeless.FormDestroy(Sender:TObject); begin fController.Free; end; Your controller declaration TctlrMyDlgModeless = class(TObject) .... fDlg : TForm; public constructor Create(AOwner:TOwner); end; constrcutor TctlrMyDlgModeless.Create(AOwner:TOwner); begin inherited Create; fDlg := TMyDlgModeless.Create(AOwner,Self); fDlg.OnEvent := NotifyMethod; .... end; do not know, if this is a preferable design. I fell uncomfortable about creating and freeing objects with this approach. HTH Guenther p.s. typed in directly in newsreader, compiled only by brain ;-) Back to top Igor Jese Guest Posted: Thu Jan 20, 2005 2:43 pm    Post subject: Re: Modeless dialog in MVC What kind of MVC variation do you use? I'm trying to find a good example for Delphi. Thanks! On Tue, 18 Jan 2005 14:19:49 -0800, George Newton <georgen (AT) xthis (DOT) pobox.com> wrote: Quote: I'm using a variation of MVC. My app has many dialogs and they are all modal - so far. Now I need a modeless dialog and I don't understand how to accomplish that using my current controller scheme for modal: TctlrDlgMyModal = class(TctlrDlg) // derived from TComponent private FDlgMyModal: TDlgMyModal; // derived from TForm ... protected ... public ... property DlgMyModal: TDlgMyModal read FDlgMyModal write FDlgMyModal; ... end; procedure TctlrMyMain.OpenMyModalClick(Sender: TObject); var ctlrDlgMyModal: TctlrDlgMyModal; begin ctlrDlgMyModal := TctlrDlgMyModal.Create(Application); try if ctlrDlgMyModal.DlgMyModal.ShowModal = mrOK then begin ... end; finally FreeAndNil(ctlrDlgMyModal); end; end; If I design the constructor of TctlrDlgMyModeless to create the form, and add an OnClose to caFree the form, then the event below will create the form, but it does not make 'sense' to me: The Modeless form stays open (as it needs to), but the controller with all of it's events for the form has been freed. procedure TctlrMyMain.OpenMyModelessClick(Sender: TObject); var ctlrDlgMyModeless: TctlrDlgMyModeless; begin ctlrDlgMyModeless:= TctlrDlgMyModeless.Create(Application); try ... finally FreeAndNil(ctlrDlgMyModeless); end; end; How might I design this so that ctlrDlgMyModeless is not freed until the form/dialog is closed? Also, my understanding is weak about creating multiple instances of these dialogs with ctlrDlgMyModeless (or anything else) using only a local variable. Any help understanding this will also be appreciated. -- Regards, Igor Back to top Joanna Carter (TeamB) Guest Posted: Thu Jan 20, 2005 4:07 pm    Post subject: Re: Modeless dialog in MVC "Igor Jese" <igor (AT) jeseonline (DOT) com> a écrit dans le message de news: [email]opskwojlql8xfw4l (AT) igortp2 (DOT) home[/email]... What kind of MVC variation do you use? I'm trying to find a good example for Delphi. Have you taken a look at the articles on MVP on my website www.carterconsulting.org.uk ? Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top Igor Jese Guest Posted: Thu Jan 20, 2005 8:40 pm    Post subject: Re: Modeless dialog in MVC Yes, thank you for the hint! I'm still optimistically trying to find a compromise, example would be MVC that uses clientdataset for model (dirty but coud work). On Thu, 20 Jan 2005 16:07:30 -0000, Joanna Carter (TeamB) <joanna (AT) nospam (DOT) co.uk> wrote: Quote: "Igor Jese" <igor (AT) jeseonline (DOT) com> a écrit dans le message de news: [email]opskwojlql8xfw4l (AT) igortp2 (DOT) home[/email]... What kind of MVC variation do you use? I'm trying to find a good example for Delphi. Have you taken a look at the articles on MVP on my website www.carterconsulting.org.uk ? Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker -- Regards, Igor Back to top George Newton Guest Posted: Sat Jan 22, 2005 3:31 am    Post subject: Re: Modeless dialog in MVC Quote: What kind of MVC variation do you use? I'm trying to find a good example for Delphi. Basically I thought about the concept of separating the various functions, in terms of my own needs, into objects, which mostly is about a whole series of controllers for each form. The following concept was of great help in my thinking, and I must thank Mark Richter for posting in this group a few years back: DelphiMVC.dpr =============================================================== program DelphiMVC; uses Forms, ProcessUnit in 'ProcessUnit.pas'; {$R *.RES} begin Application.Initialize; ApplicationProcesses.MainThread; // instead of Application.CreateForm() Application.Run; end. So, I took the concept of Model and devised a Process unit of class methods, and then a DataModule unit. In my version, the class method of Process ApplicationProcesses.DataThread comes first, creating the DM, then ApplicationProcesses.MainThread. The Process unit (not an object because it's not instantiated) knows about the controllers and about the datamodule: C-P-DM The Views know about nothing but themselves. There are various graphical objects which need to be instantiated, and which graphically depict data which starts from the DM, but which requires a great deal of additional processing. So the Process unit of class methods also creates the various different types PcssAGphObjs. I doubt that my design is especially sophisticated in terms of patterns, etc., but it keeps everything cleanly separate, and keeps the constant evolution of all the different units and objects 'out of each other's way' ... In terms of conceptualization, I found that the word/idea of "Process" made things more clearer for me than "Model" and once I got the handle on making my Process a unit of class methods (i.e., not everything needs to be an instantiation) my needs began to come together. It may not be the purest form of OOD but after three years into the design revision, I'm still getting what I need and not stepping all over myself. Now... ....isn't there anybody out there using a controller object for a modeless dialog/form ??? Back to top George Newton Guest Posted: Sat Jan 22, 2005 3:35 am    Post subject: Re: Modeless dialog in MVC Guenther, thanks for your contribution. It's not coming through too clearly for me though. I've been living in my own very narrow OO world for the last years. I'll think about your idea. Back to top Joanna Carter (TeamB) Guest Posted: Sat Jan 22, 2005 1:51 pm    Post subject: Re: Modeless dialog in MVC "George Newton" <georgen (AT) xthis (DOT) pobox.com> a écrit dans le message de news: [email]41F1C91F.997BEBBE (AT) xthis (DOT) pobox.com[/email]... Quote: The following concept was of great help in my thinking, and I must thank Mark Richter for posting in this group a few years back: <snip> Quote: In my version, the class method of Process ApplicationProcesses.DataThread comes first, creating the DM, then ApplicationProcesses.MainThread. Thank you, thank you, thank you; this is one of the final missing pieces to my MVP framework !!! Quote: ...isn't there anybody out there using a controller object for a modeless dialog/form ??? In return, I can let you know how I manage forms in MVP : The constructor of the Presenter takes a Value Type which is usually a business object of some description; the reasoning being that I am creating a Presenter for an object. Now I use interfaces for everything, so things may not be identical without due to no ref-counting, but the priciple should be similar. The Presenter then creates the View form, passing itself to the form's constructor. This then means that when the form closes, it decrements the refcount on the Presenter which then instigates the destructor of the Presenter which in turn releases the form. This may sound complicated; it certainly took some effort to get the ref-counting bit right; but what you may need to do is to simply have an event handler in the Presenter that catches the Form close event and then calls its own destructor which releases the form held in the Presenter. Other than that freeing the Presenter externally will also free the form. Does this make sense ? If not, let me know and I will try to make it clearer. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top George Newton Guest Posted: Sun Jan 23, 2005 12:47 am    Post subject: Re: Modeless dialog in MVC Joanna, I'm pleased that you find Mark's idea (or whoever's, if he got it somewhere) so helpful. The Presenter is not clear to me, and I'm not sure if I best delve into your in-depth approach just yet. I'm hip deep in my own design for now, so perhaps you might comment on a thought I have: Gunther triggered this thought, and your comments have brought it to mind again. Wouldn't it be simple to add an Observer to the Modeless Form, and notify the controller? The only issue that I have no experience with would be asn issue with the controller's destructor. If I have an event myController.ObserverUpdate that gets notified from within MyModelessForm.OnClose, does it make sense to call myController.Free from within myController.ObserverUpdate? Is it safe to call an objects own Free method from within one of its own events (myController.ObserverUpdate) ? -- George Newton Back to top George Newton Guest Posted: Sun Jan 23, 2005 1:44 am    Post subject: Re: Modeless dialog in MVC Actually, I wonder if I need the Observer at all: since ALL of my Forms events are passed to events rewritten in the controller when it is created anyway - including the Form's OnClose, then why not: procedure TctrlDlgMyModeless.DlgMyModelessClose(Sender: TObject; var Action: TCloseAction); begin Action := caFree; // "self" here referring to the controller: TctrlDlgMyModeless Self.Free; end; This seems to work, although I haven't checked for memory leaks. Any comments anybody? -- George Newton Back to top Bob Dawson Guest Posted: Sun Jan 23, 2005 2:12 am    Post subject: Re: Modeless dialog in MVC "George Newton" wrote Quote: since ALL of my Forms events are passed to events rewritten in the controller when it is created anyway I'm hesitant about that 'ALL' part. IOW, I tend to have methods like procedure TClientForm.UpdateFormFromObject(aClient : TClient); procedure TClientForm.UpdateObjectFrom Form(aClient : TClient); and it's up to the form to take care of all internal business (coordination of verious visual controls, etc.). In your system does the controller know the exact class and structure of the form it controls? Would it manipulate individual controls (TEdits, TListBoxes, etc. directly? If so, then what does this externalization of the form's business buy you? bobD Back to top Joanna Carter (TeamB) Guest Posted: Sun Jan 23, 2005 11:18 am    Post subject: Re: Modeless dialog in MVC "George Newton" <georgen (AT) xthis (DOT) pobox.com> a écrit dans le message de news: [email]41F3017F.3D7BC169 (AT) xthis (DOT) pobox.com[/email]... Quote: Actually, I wonder if I need the Observer at all: The problem with handling anything emanating from the form, whether that be an event or an Observer notification, you cannot free the form, if it is passed to the handler, from the handler, otherwise you invalidate the pointer passed to the event. Quote: since ALL of my Forms events are passed to events rewritten in the controller when it is created anyway - including the Form's OnClose, then why not: procedure TctrlDlgMyModeless.DlgMyModelessClose(Sender: TObject; var Action: TCloseAction); begin Action := caFree; // "self" here referring to the controller: TctrlDlgMyModeless Self.Free; end; This seems to work, although I haven't checked for memory leaks. There should be no problem in calling Free from within an object because all it does is check for nil and then call Destroy. In fact you can call Destroy directly because you have to be in a valid object to be handling the OnClose event. The caFree should take care of the form as long as you ensure that no subsequent code in the destructor of the controller calls the form. Joanna -- Joanna Carter (TeamB) Consultant Software Engineer TeamBUG support for UK-BUG TeamMM support for ModelMaker Back to top George Newton Guest Posted: Sun Jan 23, 2005 8:15 pm    Post subject: Re: Modeless dialog in MVC Quote: since ALL of my Forms events are passed to events rewritten in the controller when it is created anyway I'm hesitant about that 'ALL' part. IOW, I tend to have methods like .... and it's up to the form to take care of all internal business (coordination of verious visual controls, etc.). In your system does the controller know the exact class and structure of the form it controls? Would it manipulate individual controls (TEdits, TListBoxes, etc. directly? If so, then what does this externalization of the form's business buy you? Yes, all properties of the "view" are set from the controller, with the first field FMyThisTypeDlg: ThisTYpeDlg; As far as what it "buys" me, I don't claim to have done an exhaustive analysis of my scheme. However, I do know that for a very large app, the procedural approach becomes irrevocably unmanageable - not in building it, but in its capacity to evolve. I also have a "User" object which stores all of the properties which might pertain to the common needs of forms and dialogs and the preferences of an individual user which the Process unit needs knowledge of from time to time (my app uses time, so the locale needs to be 'processed'). The events Have To Be Written anyway, whether they're in the form's unit or in the controller's. The only added "effort" is first the mindset of reassigning every form event (and ListBox, etc) to the controller in its Create: MyForm.ComboBox1.OnChange := MyCtrlComboBox1Change; That one line for each event buys the Whole package of object independence. As the app evolves down the road, there is this whole insurance of independence acquired which allows whatever changes you need without a host of little dependencies and gotchas lurking in the closets and under the bed sheets... ;) It might not seem so apparently helpful in terms of just the relationship between the form and the controller, but when you have your Model, or as I prefer your Process, totally separate, you always know where the changes you're making are focused and the boundaries of their relationship. It does seem almost like a trivial matter to have these forms with so little in their units, but the mindset and discipline of this type of housekeeping keeps for a more restful sleep, and as the complexity evolves, a narrower range of focus for your contemplated changes and evolutions. At least that is how I have found it to work for me. I do not regret one bit the two years I took to change everything over from a procedural approach to this type of object model, and designing my Process unit totally as a unit of class methods. On the other hand the countless small programs I need rarely employ this approach because there is so little to them. In the end, I think the major benefit come with the simplicity of conceptualiztion when I need the app to evolve. I'm tickled that it seems that my first need for a ModeLess dialog seems to be easily solved by this approach as well. I have little idea how well my schemme will work for anyone else. I don't use ClientDataSet yet - my app is desktop w/Firebird. If and when it evolves to a web or true c/s I'll explore that. -- George Newton Back to top George Newton Guest Posted: Sun Jan 23, 2005 8:19 pm    Post subject: Re: Modeless dialog in MVC Quote: There should be no problem in calling Free from within an object because all it does is check for nil and then call Destroy. In fact you can call Destroy directly because you have to be in a valid object to be handling the OnClose event. The caFree should take care of the form as long as you ensure that no subsequent code in the destructor of the controller calls the form. Thanks for reviewing this for me. -- George Newton Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> Delphi OO design All times are GMT Page 1 of 1   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.