Passing data from a modal form to a main form

[Relativity]

I have a main form (defined in its own unit) that shows a second (modal) form (also defined in its own unit), in which some data is gathered. The data gathered in the second form should be passed to the main one, when the second form is closed.

Should I use some public variable defined in a third unit visible from both forms ?

Thank you.

[derek.john.evans]

Just store all the data the modal form collects in the modal form.

The main form can access it after the modal form closes.

[Windsurfer]

I think there is a typo there. It should read:

Just store all the data the modal form collects in the main form.

[derek.john.evans]

I think there is a typo there. It should read:

Just store all the data the modal form collects in the main form.

Nope. That would make the modal form dependent on the main form. Modal forms still retain all their data before and after being shown.

Example: I have options/properties dialogs in my apps, with controls the user edits. I grab the values from the modal form, after it closes.

[Relativity]

derek.john.evans, you are right. Thank you.

Windsurfer, I can't store the data collected in the modal form in the main form from the modal form, because to do this the modal form should have the "use mainform" clause in its unit and this is not allowed, because I would need I circular unit reference.
From where would you store the data collected in the modal form in the main form ?

[derek.john.evans]

There are ways around the "circular unit reference", but, even so, it isn't a good programming practice. Imagine 50+ dialogs, all with their own data? Which is common in large apps.

Keep the data in the modal form.

[derek.john.evans]

BTW: Yes, multiple projects is another issue. But, then, you would have a MDI (or similar) interface.

In that case, yes you would copy the project data to the modal form, and then copy the data back to the project when the user clicks OK.

[User137]

Just example for the bad practise (and infinite loop), where you can at least see unit communications:

Code: [Select]

unit Unit1;

interface

  procedure Unit1Proc;

implementation

uses Unit2;

procedure Unit1Proc;
begin
  Unit2Proc;
end;

Code: [Select]

unit Unit2;

interface

  procedure Unit2Proc;

implementation

uses Unit1;

procedure Unit2Proc;
begin
  Unit1Proc;
end;
The calls are allowed because uses is in implementation, there will be no circular references. But this dummy example keeps calling eachother infinitely and for that stack overflow it might not even compile.

[howardpc]

Should I use some public variable defined in a third unit visible from both forms ?

It is always possible to use a global variable (visible from both forms) in this way.

However, best practice from the point of view of encapsulating and hiding data where possible, would argue against exposing data to the entire application in this manner. Also, global variables of this sort can lead to inadvertent use of stale data, when the programmer has not considered that a data value might change before it is needed again.

One way to avoid yet another unnecessary global variable would be to package the data into a parameter passed in a function call of the main form. The function call would first show the modal data-gathering window of the second form unit, passing the data back when the window was closed. For instance the data could be a custom class, or a pointer to a record (or, if you like methods with lots of parameters, a parameter for each data field needed).
The LCL itself provides good examples of this kind of coding.

The art of programming often has to do with designing the best way of managing complex data (both internal and external) as much as it has to do with coding per se.