dionel1969 Posted June 7, 2011 Posted June 7, 2011 Hello: Normally, in most applications that I make, I do not auto-create forms, just rather in the moment I need them. With this the application loads a little faster. Even in the case of modal windows I create them at the time that the client is going to edit that data and later I destroy them. So I use the following code: function EditData: Boolean; var Dlg : TAnyDialog; begin Dlg := TAnyDialog.Create(Application); Result := (Dlg.ShowModal = mrOk); FreeAndNil(Dlg); end; In this case "ShowModal" is a function that returns ModalResult (mrOk, mrCancel, mrYes, etc...). The result of the function I use to refresh data in mrOk cases, or other things. In the case of TUniForm "ShowModal" is a procedure and do not works as cycle waiting for the end of modal state, no in the case of WEB interface, in the Windows interface works as expecting. So my question is: I have to call "ShowModal" and then make a cycle by myself waiting for change of ModalResult property???? Or, what???? If you could explain how works ShowModal in the WEB interface will be good for me. May be this is caused by my lack of knowledge on web interfaces. Quote
Administrators Farshad Mohajeri Posted June 7, 2011 Administrators Posted June 7, 2011 In webmode ShowModal calls aren't blocking. Due to nature of web we can't block a web request thread. In this sense a uniGUI web application like any other web application should work in a completely event-driven and non-blocking manner. Here is the solution: Caller Form: procedure TMainForm.UniButton2Click(Sender: TObject); begin UniForm2.ShowModal; end; Called form will handle the modal result in Form OnClose event: procedure TUniForm2.UniFormClose(Sender: TObject; var Action: TCloseAction); begin If ModalResult=mrOK then begin // Handle OK end; end; In future we may develop better mechanisms to handle modal results. Quote
cvjcvj Posted June 9, 2011 Posted June 9, 2011 In webmode ShowModal calls aren't blocking. Due to nature of web we can't block a web request thread. In this sense a uniGUI web application like any other web application should work in a completely event-driven and non-blocking manner. Here is the solution: [...] In future we may develop better mechanisms to handle modal results. We already have a good mechanism: anonymous methods. I have writed a "Confirmation" dialog that, when OK, calls a reference to a method. It is way better than a callbak. MyConfirmationDialog('Are you a good programer?', procedure(AResult: Integer) begin // handles AResult end); works like a charm. When I have more a more complex scenario, than I use a Interface. Is a better approach that making a DataModule changing variables of main form. Quote
thecrgrt Posted June 10, 2011 Posted June 10, 2011 We already have a good mechanism: anonymous methods. I have writed a "Confirmation" dialog that, when OK, calls a reference to a method. It is way better than a callbak. MyConfirmationDialog('Are you a good programer?', procedure(AResult: Integer) begin // handles AResult end); works like a charm. When I have more a more complex scenario, than I use a Interface. Is a better approach that making a DataModule changing variables of main form. Good Idea Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.