Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?

Of late when I look the definition of a form, it all seems so odd to me that properties, objects etc which are not meant to be accessible to external modules are automatically visible.

I just want to check on how the form or module fits into the overall program just by looking at the public and published properties. Am I missing something about the ideas about Delphi and Lazarus which are supposed to be obvious?

Frank Church wrote

Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?

Which properties and events ? Can you give an example ?

Of late when I look the definition of a form, it all seems so odd to me that properties, objects etc which are not meant to be accessible to external modules are automatically visible.

Such as ?

And visible where ? In the code tools, or in the Object Inspector ?

Michael.

All objects that should be placed in the lfm/dfm file MUST be placed in the published section in Delphi and Lazarus, because they are only streamed if there is RTTI for them for which "published" was created. Yes, there are other approaches, e.g. fpGUI has an IDE that has the GUI creation in code and of which the IDE parses and modifies the "initialization routine" to display a designer form, and another possiblity would be - if they'd be implemented in FPC - the extended RTTI which allows you to specify that also e.g. private fields have RTTI generated and (with an adjusted streaming system) this could also be used. But neither Delphi nor Lazarus uses this approach, so you must live with that (for now).

Regards,
Sven

I am referring more to the source code itself. After adding lots of forms, data modules etc, I look at a datamodule or a form (more relevant with datamodules) and ask myself "What does this module do?" and find myself staring at procedure after procedure in a bit of confusion. I'd prefer to look only at the public section and say, Oh, this is what it does for the program's other modules. Whatever isn't there is not relevant to the rest of the application.

I understand that it comes from a Delphi legacy as RAD tool dating from a time when the principles underlying object orientation had not properly sunk in. It makes me wonder whether I've got my whole approach to object orientation and encapsulation with Object Pascal wrong or misconceived as a result of that. I guess it is more obvious if you start using Lazarus of FPC more on the non visual areas.

You can already do this by changing the way you are programming. Just write a class which only publish the needed methods and properties to the outside.
Don't let the Application create and control your forms, move this to your class. So, your class hides the forms, datampdules and other stuff.

hth
Michael

I remember this aspect form asking a similar question some time back. What of the event handlers, is it the nature of the form designer which requires them to be visible as well? It is possible also to set an eventhandler to a routine in other file, but ideally shouldn't that be something the develop can choose to expose only when he requires it?

I am now considering placeing an intermediate classes between the consumers and producers in order to hide those details, so that instead of some form calling a data module directly, it calls an intermediate class that accesses the data module through the methods and properties of that class..

This is what I have been considering.

That's what I do too.

unit appforms;
type
   TBaseMyForm = Class(TForm)
     // Define public interface
   end;
   TBaseMyFormClass = Class of TBaseMyForm;
Var
   MyFormClass : TBaseMyFormClass = Nil

And then somewhere:

Type
   TForm = TBaseMyForm;
   TMyForm = Class(TForm);
    // Regular lazarus definition of form
   end;
initialization
   MyFormClass = TMyForm;
end;

And then, whenever I need an instance of TBaseMyForm:

F:=MyFormClass.Create(Self);

You could even substitute the complete TMyForm form with another one, depending on configuration options.

Michael.

If you want to set event handlers through the object inspector, then you need to have them published as well, because only then "MethodAddress" which is used in the streaming will return something besides Nil.

This is maybe one of the better approaches you can do.

Regards,
Sven

Do you have a good working sample of this approach?

Yes, all my they are not open source :/

It's really not much more than what I wrote above.

Just one large unit with a lot of 'base form' definitions and class pointers for each of them.

Michael.

Is it meaningful or possible to change the visibility or the properties and events in a form or datamodule, ie make the private or protected?

Then derive from TCustomForm instead of TForm. As for most TCustom... classes, TCustomForm declares all essential properties as protected, and only TForm publishes those properties, which shall be editable at design time (in the OI).

DoDi

Frank Church wrote

properly sunk in. It makes me wonder whether I've got my whole approach to object orientation and encapsulation with Object Pascal wrong or misconceived as a result of that. I guess it is more obvious if you start using Lazarus of FPC more on the non visual areas.

Indeed. Using tools like Lazarus IDE and Delphi IDE to build OOP apps is the worst possible way of doing it. Simply because those two IDE's rely on streaming via RTTI, which is hugely limited to Published properties only - thus everything ends up being publicly visible. Yes the new Delphi now has improved RTTI, but they haven't change the "everything must have visibility of Published" to work.

I'm a huge believer of true OOP, and that is why I refused to create fpGUI's Form Designer the way Delphi and Lazarus IDE works. Making every single thing you drop on a form published visibility is just wrong! That is a far cry from how OOP software are supposed to be written. Thus the reason I believe that using Delphi and Lazarus in such a way, is only good for prototyping applications - not for the real implementation. fpGUI's form designer makes everything you drop on a form private by default - you then later make things more visible (via properties for example) when really needed - this is how OOP applications are meant to be written.

Other's viewpoints will indefinitely vary from mine, but that will not change my thoughts on the subject.

That's might be mostly because one of the important aspects of Delphi is backwards compatibility (yes, I know that there was the switch from AnsiString to Unicodestring, but there is a saying in Germany: exceptions confirm the rule ;) ). The aspect that it costs time (aka money) without a "real" benefit (while I take your critic serious the guys at Embarcadero might just laugh at you) might also be an important one. In theory one should be able to implement a GUI framework based on the concept of the extended RTTI. With quite some work it might even be possible to switch something like the LCL to such an approach (though then the famous Delphi compatibility comes in ^^) once FPC has support for the extended RTTI (where noone is working at currently).

Regards,
Sven

Will I be able to develop TMyForm in the Object Inspector as usual, although TForm has been redefined as a class of TMyForm? Will the unit in which TMyForm defined still use the Forms unit, or will that be inherited from the inclusion of the unit appforms (in your example)?

Is there some place in the Free Pascal or Object Pascal docs that the principles are explained?

Any updates? Does any one else have some examples?

In code: yes.
If you remove properties: they still will be visible in the object inspector . This can be remedied by registering TMyForm in the IDE, using the custom forms package.

Will the unit > in which TMyForm defined still use the Forms unit, or will that be > inherited from the inclusion of the unit appforms (in your example)?

You must use the Forms unit for many property type declarations, but the one from appforms will be used.

> > Is there some place in the Free Pascal or Object Pascal docs that the > principles are explained? >

Not to my knowledge. I do have an article about the custom form registration in the IDE.

Michael.

Hi Michael, could you help me clarify how the units are linked.

From reading your code I get the impression that I create TMyForm

separately then copy all of its code into appforms.pas. It is not a matter of adding the unit or TMyForm in appforms? Or is the other way round in which the unit of myform.pas has appforms included in its units?

The first option also implies that I must include the .lfm file of myform in appforms.

So in a nutshell does it mean I create TMyForm in the usual manner, using the IDE then copy all its contents into appform, then add TForm = TBaseMyForm to the top of its type definition?

I know I've got to brush up on my Object Pascal concepts, but some help here would be really welcome

No ?

It is not a matter of adding the unit or TMyForm in appforms? Or is the other way round in which the unit of myform.pas has appforms included in its units?

It is the other way round.

Yes, this is what you should do.

I know I've got to brush up on my Object Pascal concepts, but some help here would be really welcome

Hope the above helps. If not, ask away.

Michael.