Recent

Author Topic: [CLOSED] How to call grandsons' methods?  (Read 893 times)

egsuh

  • Hero Member
  • *****
  • Posts: 1694
[CLOSED] How to call grandsons' methods?
« on: July 23, 2025, 06:29:48 am »
I developed forms using multi-layered frames. And want to write methods for the frames enclosed as much as possible. So the actions and event handlers belonging to the frames are defined within it.
 
But how do you define the "use" links, when you want to call the actions or methods from higher-level forms? For example,


 Form1
    uses Frame 1
         uses Frame2

And  Frame2.Button1Click does something with data, available from Form1 (let's say form1.edit1).

Yes, I know that i can add form1's unit in the uses list of Frame2's implementation section.
Or I may redefine the event handler at form1.

But both approaches have weakenesses that the first approach is not possible if I want to use the Frame2 in another application. And second approach has similar problem when I change frame2 to any other frames.

Of course I'm not looking for one correct answer. Any suggestions?   interface?
« Last Edit: July 23, 2025, 09:23:27 am by egsuh »

cdbc

  • Hero Member
  • *****
  • Posts: 2467
    • http://www.cdbc.dk
Re: How to call grandsons' methods?
« Reply #1 on: July 23, 2025, 08:05:23 am »
Hi
Quote
Any suggestions?   interface?
YES Interfaces to the rescue  8-)
1) Define a CORBA interface for TForm1, with the methods and props you'll
    need to service the frames. { corba doesn't prematurely free your form }
    At best, put the interface in its own unit, that way you don't have to _use_
    the _form_ in the implementation section, just the interface unit.
2) When creating the frames, you just feed them the form's interface and
    "Puff" you've got a working reference to the form, in your frames...

With a CORBA interface, you can just borrow the form's functionality  :D ...no creation & freeing going on, just a reference.
Regards Benny
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE6 -> FPC 3.2.2 -> Lazarus 4.0 up until Jan 2025 from then on it's both above &: KDE6/QT6 -> FPC 3.3.1 -> Lazarus 4.99

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 11818
  • Debugger - SynEdit - and more
    • wiki
The "easiest" way is to hand down the part you need.

I.e., the frame-2 may not need to know about Form1 at all, just about the edit?

Code: Pascal  [Select][+][-]
  1. TFrame2 = class(TFrame)
  2.   public
  3.      property OuterFooBarEdit: TEdit write .. read ...
  4. end;

The Form can store a copy of TEdit there. Then you can work with it.

Or if you don't need to know the entire TEdit, but just trigger something small, then you can have an event (e.g. TNotifyEvent, or your own type of event there).

Multiple events (including calls to get data) can go into an interface... But then...



Then the question is: Does it have to happen on the form or frame at all.

Separate GUI from app-logic.

Have a new unit, with the logic. And do all the work there.
This unit should neither know the form nor the frame.

It gets called by either of them.
And to send its answers, it has events, or an interface that are provided by each of the GUI element as part of an initial setup connection everything.

cdbc

  • Hero Member
  • *****
  • Posts: 2467
    • http://www.cdbc.dk
Re: How to call grandsons' methods?
« Reply #3 on: July 23, 2025, 08:30:35 am »
Hi
@Martin +1 to this:
Quote
Separate GUI from app-logic.
Regards Benny
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE6 -> FPC 3.2.2 -> Lazarus 4.0 up until Jan 2025 from then on it's both above &: KDE6/QT6 -> FPC 3.3.1 -> Lazarus 4.99

egsuh

  • Hero Member
  • *****
  • Posts: 1694
Re: How to call grandsons' methods?
« Reply #4 on: July 23, 2025, 09:23:09 am »
Quote
Separate GUI from app-logic.

The program has separate units from GUIS already... I'll think over this more. Thank you for your responses.

 

TinyPortal © 2005-2018