[Lazarus] Some thoughts about the global 'Application' instance.

[Joost van der Sluis]

Op maandag 22-06-2009 om 00:39 uur [tijdzone +0200], schreef Mattias
Gaertner:
> On Sun, 21 Jun 2009 22:26:15 +0100
> Martin Friebe <lazarus at mfriebe.de> wrote:
> 
> >[...]
> > The beginning of this thread was, that 2 applications existed,
> > because the developer was *forced* to included "interfaces":
> > 
> > Jost wrote in the initial mail of this thread:
> > > I always thought that an application always had one
> > > Application-instance from the TCustomAppliction class. But at this
> > > moment this is not the case for fcl-web applications, or
> > > daemon-applications which are using Lazarus-forms.
> 
> Whoever wants to continue this thread: Please give an example for a
> fcl-web application or daemon-application which is using Lazarus-forms.

Ow, that's easy: all those using WebModules and are streamed using the
Lazarus-streaming system.

> > ....
> > > But nowadays we are forced to include the 'interfaces' unit, which
> > > uses the 'forms' unit which has it's own global Application
> > > variable. So there are two TCustomApplication descdendents
> > > initialized during the program!
> > 
> > Somehow the whole thread then picked up, the first half of this, and 
> > everyone started to discuss (at least this is the impression I got, 
> > apologies, if I overlooked anything) , how you could avoid having the 
> > application from the Forms unit, even if you use that unit (because 
> > apparently you have to). So the forms unit would have to detect the 
> > presence of another application....
> 
> And this is what I don't understand.
> What part of unit "forms" is needed that does not require the
> widgetset?

LResources. That's the only thing I need, nothing more. 

So actually only the Lazarus-streaming-mechanism is used. TWebModules
are in fact TDataModules which you can use at design time to setup all
kind of components. At run-time, those components are read from a
resource and further nothing is needed.

But now with the new link-optimisation I'm forced to use the interfaces
unit, and thus also the forms unit, which includes a widgetset, which I
don't need. Using the nogui widgetset indeed solves this.
 
> > But all this only means work around the consequences, instead of 
> > tackling the cause.
> > 
> > If I understand correctly, Interfaces now needs to be there, because
> > of the smart-link - linker-alias trick used to reduce the exe size.
> 
> No. Unit interfaces was needed since the beginning. 
> Before the change it was possible to avoid interfaces if:
> - you use only constants and utility functions of the forms/controls
>   unit.
> - or if you use only the most basic things of TApplication, which
>   already exist in TCustomApplication.

And when you only needed LResources. (And fileutil is also very usefull)

> Please give at least one good practical example before starting
> theoretical discussions how to restructure the FCL/LCL.

Avoiding two Application-instances was only a side-effect of what my
real intention was. 

The reason I started about a global CustomApplication in CustApp was
that you can refer to the current Application-class, without knowing
what type of application you are in.

For example: if you have a unit which is used in a daemon, web and
Lazarus/GUI application you can call CustomApplication.HasOption() by
just adding CustCgi to the uses.

I now think that I can add this without causing any problems for
fcl-web/fcl-daemon/Lazarus and mseide if I just add a global variable in
custapp:

var CustomApplication: TCustomApplication;

At first this will change nothing. But all frameworks which use the
TCustomApplication-setup can set the global variable, so that it is
accessible thoughout the whole program.

That way Lazarus/mseide/etc can choose how to use it (or not to use it)

But it would be nice if I could use LResources again, without using
forms, but that's another story.

Joost.