Are control events implemented in other units?

[yazigegeda]

Unit1:

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
9.  
10. type
11.  
12.   { TForm1 }
13.  
14.   TForm1 = class(TForm)
15.     Button1: TButton;
16.  
17.     procedure FormCreate(Sender: TObject);
18.   private
19.  
20.   public
21.  
22.     procedure Button1Click(Sender: TObject);
23.  
24.   end;
25.  
26. var
27.   Form1: TForm1;
28.  
29. implementation
30.  
31. uses
32.   Unit2;
33.  
34.  
35.  
36. {$R *.lfm}
37.  
38. { TForm1 }
39.  
40. procedure TForm1.FormCreate(Sender: TObject);
41. begin
42.  
43. end;
44.  
45.  
46.  
47. end.
48.  

Unit2:

Code: Pascal  [Select][+][-]

1. unit Unit2;
2.  
3. {$mode ObjFPC}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs;
9.  
10. type
11.  
12.   { TForm2 }
13.  
14.   TForm2 = class(TForm)
15.     procedure FormCreate(Sender: TObject);
16.   private
17.  
18.   public
19.  
20.   end;
21.  
22. var
23.   Form2: TForm2;
24.  
25. implementation
26.  
27. uses
28.   Unit1;
29.  
30. {$R *.lfm}
31.  
32. { TForm2 }
33.  
34. procedure TForm2.FormCreate(Sender: TObject);
35. begin
36.  
37. end;
38.  
39.  
40. procedure TForm1.Button1Click(Sender: TObject);
41. begin
42.     // TForm1 button click event again implemented
43. end;
44.  
45. end.
46.  

I want to put the implementation of the button click event of Form1 in other units, I don't know if it is feasible, help me :'( :'( :'(

[Handoko]

No.

The correct solution is, write a new unit, put the code that needed to be shared in that unit. And then in both the first and second units' uses clauses put the name of the new unit there.

[VisualLab]

Example of solution in the attachment.

Code of Unit1:

Code: Pascal  [Select][+][-]

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
9.  
10. type
11.   {TForm1}
12.   TForm1 = class(TForm)
13.     Button1: TButton;
14.     Button2: TButton;
15.     Label1: TLabel;
16.     procedure Button2Click(Sender: TObject);
17.     procedure FormCreate(Sender: TObject);
18.   end;
19.  
20. var
21.   Form1: TForm1;
22.  
23. implementation
24.  
25. uses
26.   Unit2;
27.  
28. {$R *.lfm}
29.  
30. {TForm1}
31.  
32. procedure TForm1.FormCreate(Sender: TObject);
33. begin
34.   Label1.Caption := 'Form 1 created!';
35.   Button1.OnClick := @Form2.Button1Click;
36. end;
37.  
38. procedure TForm1.Button2Click(Sender: TObject);
39. begin
40.   Application.CreateForm(TForm2, Form2);
41.   Form2.Show;
42. end;
43.  
44. end.
45.  

Code of Unit2:

Code: Pascal  [Select][+][-]

1. unit Unit2;
2.  
3. {$mode ObjFPC}{$H+}
4.  
5. interface
6.  
7. uses
8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls;
9.  
10. type
11.   {TForm2}
12.   TForm2 = class(TForm)
13.     Label1: TLabel;
14.     procedure FormCreate(Sender: TObject);
15.   public
16.     procedure Button1Click(Sender: TObject);
17.   end;
18.  
19. var
20.   Form2: TForm2;
21.  
22. implementation
23.  
24. {$R *.lfm}
25.  
26. {TForm2}
27.  
28. procedure TForm2.FormCreate(Sender: TObject);
29. begin
30.   Label1.Caption := 'Form 2 created!';
31. end;
32.  
33. procedure TForm2.Button1Click(Sender: TObject);
34. var
35.   LName: String;
36. begin
37.   {click event handled by button on the TForm1}
38.   LName := '';
39.   if Sender is TButton
40.    then LName := (Sender as TButton).Name;
41.   ShowMessage('Clicked: ' + LName);
42. end;
43.  
44. end.
45.  

However, I do not recommend this approach. With more event handlers it will get messy. A better approach is (your choice):

- calling functions defined in a separate library module (own library) from event handling procedures, or
- "connecting" library procedures to events.


EDIT:

Handoko posted his answer right before me Yes, his answer is the best way to approach this issue.

What I provided is only to show that it can be done. But that doesn't mean you should do it!

[Handoko]

You've just taught the TS how to write spaghetti code.

https://en.wikipedia.org/wiki/Spaghetti_code

[VisualLab]

You've just taught the TS how to write spaghetti code.

https://en.wikipedia.org/wiki/Spaghetti_code

I would say that it is rather a "tangled ball of ropes" (so, probably an even worse solution than "spagetti"). But yes, I completely agree that this solution should not be used. The example was intended to show the questioner that:

- you can do something similar to what he wants,
- you shouldn't create code this way.

Perhaps it would be worse if the questioner came to a working solution on his own. But then no one would explain to him why this was a bad idea.

[Joanna from IRC]

You can an event code implemented just about anywhere that is in scope of the button. I agree with other posters that the button event should be implemented in the form that owns the button.

[yazigegeda]

You can an event code implemented just about anywhere that is in scope of the button. I agree with other posters that the button event should be implemented in the form that owns the button.

Thank you, the code you provided fulfilled my needs!

[VisualLab]

Thank you, the code you provided fulfilled my needs!

So you think that using methods like "taking your pants off over your head" is a good idea? It was an ANTI-EXAMPLE!

Just because something can (technically) be done and seems like a good idea, doesn't mean it should be done. Objects can be combined with each other. But they should not be interwoven! Interlacing is advisable when producing fabrics. In other cases this should not be done.

[Joanna from IRC]

@visuallab I think he was mocking me for not providing code.
Also pants that remove overhead As ridiculous as it may sound are Very common for baby clothes