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 <[email protected]> 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. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
