Hi all,

I need to pass a my custom TMainForm to a function on other unit, e.g.

main unit:

...
uses

  Classes, SysUtils, FileUtil, LResources, Forms, Controls, test;

type

TMainForm

  TMainForm = class(TForm)
    ...
    procedure FormCreate(Sender: TObject);
  private
    { private declarations }
    x:integer;
    ...
  public
    { public declarations }
    y: integer;
    ...
  end;

_______

Other unit "test.pas":

unit test;
{$mode objfpc}{$H+}
interface
uses
  third;
procedure init(...; ...; var Form: TMainForm);
implementation
procedure init(...; ...; var Form: TMainForm);
begin
...
Form.y:=0;
end;

_______

Is it possible?

PS I'm sorry for this example, maybe it is not perfect, I wrote it on the fly.

Thanks,
Kjow

Kjow wrote

procedure init(...; ...; var Form: TMainForm);

You don't need to pass Form by reference (using 'var') since class instance is pointer. This is only required if you want to replaced passed Form argument by another class instance.

Best regards,
Paul Ishenin.

uses third;

What is unit "third"? You need to refer to main unit containing TMainForm. If you don't need to use unit "test" in main unit then it works. Otherwise it creates a circular reference. (Now there is "uses ... test" in the main unit).

Juha

Kjow wrote

Is it possible?

Yes, but there is an alternative too. Very non-OOP, but Lazarus and Delphi enforce it for form creation (and requirement by form designer). In your unit with the TMainForm, there should be a lovely global instance variable called MainForm that you can access from everywhere. Also not very OOP like, all controls on the TMainForm (and any other form created with Delphi and Lazarus) is published, so they are globally accessible too.

All this is not what I call good OOP design, but hey, it's RAD convenience. :-/

Little bit OT:

Is this global var really neccessary? Normally I delete all those variables in my Delphi projects and create my forms on the fly and everything works fine.

Is this really a requirement for the lazarus form designer?

regards,

Stefan

See "When createing new forms, add them to auto-created forms" checkbox in Project Options.

The global variable is not a requirement and can be disabled by removing the "Auto create forms" in the Project Options dialog.

Published components and event handlers however are a "lazarus/delphi forms designer" requirement - which means everything you drop on a form is globally visible. I hate that design.

fpGUI's Form Designer on the other hand does not force such a design. By default all my components and event handlers for a form are private. If I want to make some element of the data stored in a component visible, I create a public property declaration for the specific data - never the whole component.

Hello Lazarus-List,

Thursday, April 15, 2010, 9:25:06 AM, you wrote:

smd> Little bit OT:
smd> Is this global var really neccessary? Normally I delete all those smd> variables in my Delphi projects and create my forms on the fly and smd> everything works fine.
smd> Is this really a requirement for the lazarus form designer?

AFAIK only for autocreated forms, in my case usually only the main form, I do not like the autocreated ;)

Yes and no
The lazarus/delphi forms designer uses RTTI for created components. RTTI is only created for published members of a class so for that they need to be published.

from a RTTI pov this seems logical since with RTTI you already have all info available. But from a class design pov it would have been nice if there was a 2nd way to tell the compiler to generate RTTI for some non-published members

Marc

An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20100415/b80e61c0/attachment.html>

Marc Weustink wrote

The lazarus/delphi forms designer uses RTTI for created components. RTTI is only created for published members of a class so for that they need to be published.

That's exactly why fpGUI UI Designer doesn't use RTTI. Down side is you need to tell the UI Designer what should be available in the Object Inspector. Up side is that the controls on the forms or properties of a component can have any visibility, and the UI Designer will still work. And as a "catch all" where you need to set a property, but it isn't in the Object Inspector, there is a 'Unknown Lines' memo in the Object Inspector that will store whatever you typed in there exactly as is, in the generated code. And it also does the reverse, when loading a form or component properties it doesn't know about, it adds those to the Unknown Lines memo.

available. But from a class design pov it would have been nice if there was a 2nd way to tell the compiler to generate RTTI for some non-published members

I guess that is where Java and .NET's Reflection is better than FPC's RTTI. With Reflection you can accesss anything information about a class (well so I hear - I don't use Java or .NET).

Graeme Geldenhuys wrote

I guess that is where Java and .NET's Reflection is better than FPC's RTTI. With Reflection you can accesss anything information about a class (well so I hear - I don't use Java or .NET).

Now you played that card, you are never allowed to complain about either binary sizes, or memory use again :-)

When visibility is really a problem, you can use TComponent.DefineProperties...

Best regards,
Fl?vio

2010/4/15 Fl?vio Etrusco :

When visibility is really a problem, you can use TComponent.DefineProperties...

Or simply use a "property types" (aka ValueType) framework, that doesn't use RTTI at all, yet you can query all properties and even add new have used this in combination with tiOPF
before and it works well.