Hi all!!

I'm creating a new form class with some extra features, derived from TCustomForm. But when I override the procedure CreateWnd to register the new instance of my form class as the main form of the application, I receive a warning talking that my form class (TSecureForm) and TForm are not related. The CreateWnd code is:

procedure TSecureForm.CreateWnd;
begin
  if (Applicationnil) then
    Application.UpdateMainForm(TForm(Self));
  inherited CreateWnd;
end;

So, I take a look into TApplication.UpdateMainForm and I see:

procedure TApplication.UpdateMainForm(AForm: TForm);

My question is: The parameter AForm should be of type TCustomForm instead of TForm?

[...] My question is: The parameter AForm should be of type TCustomForm instead of TForm?

No.
Why can't you derive from TForm?

Mattias

"Mattias Gaertner" wrote

No. Why can't you derive from TForm?

Because TForm publishes some properties that I want keep in protected section.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160217/e2efe12a/attachment.html>

Fabio Luis Girardi wrote

Because TForm publishes some properties that I want keep in protected section.

That would have been my answer too. I fully agree, classes or methods should use the lowest possible class in the hierarchy, thus any descendants are usable too.

Regards,
- Graeme -

Why do you need a MainForm?

Mattias

There is a functionality difference between TCustomForm and TForm in the LCL.
See e.g. TCustomForm.GetRealPopupParent (uses Screen.ActiveForm) or TApplication.UpdateVisible (uses Screen.Forms).

So this is wanted and by design. It is also coming from Delphi. Every "normal" form that you use has to be a descendant of TForm if you like it or not.
Descendants of TCustomForm are special forms like hint windows etc.

Ondrej

Ondrej Pokorny wrote

So this is wanted and by design. It is also coming from Delphi. From what I remember (Delphi 7 and earlier), any TCustomXXX is used for

descendants and component writers. The "final" class without the "custom" part in the name is simply a empty class, but with the properties Published.

I know the Delphi form designer used TForm for descendants - I always thought that to be wrong (from a design point of view). I understand why Delphi did that though - to overcome the Delphi Form Designer limitations, where it uses RTTI get read and set properties, and thus needs published properties.

TApplication is not a component you can drop on a form though, so should not be grouped with the same limitations as the Delphi Forms Designer.

My argument is exactly the same as why many components use TStrings as a property parameter, instead of TStringList.

Regards,
- Graeme -

Your argument is valid for TStrings/TStringList, TCustomEdit/TEdit etc. but not for TCustomForm/TForm. This is a historical relict Lazarus has inherited from Delphi. Normal forms (that you put controls on and work with them normally) have to be inherited from TForm or you will be facing strange effects (like wrong PopupParent on ShowModal etc.). It's the same in Delphi.
There could be another design chosen but Delphi chose this one. You have to live with it.
As I said before, it's by design so your arguments are nil here.

Btw. Delphi 7 has no PopupParent property - it was introduced in Delphi 2006 (maybe 2005 but who cares about it).

Ondrej