Jump to content

Clarifying doubts


dionel1969

Recommended Posts

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.

Link to comment
Share on other sites

  • Administrators

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...