By the way, I was always wondering why there is not TUser object and no TComputer.
For example: TUser.SettingsPath TUser.LoginID TUser.Surname TUser.Firstname and so on. And TComputer.CurrentUser TComputer.Name TComputer.SettingsPath Or does this exist already ? I only know TApplication and TScreen so far. Regards, Sam --- Martin Friebe <[email protected]> schrieb am Sa, 20.6.2009: Von: Martin Friebe <[email protected]> Betreff: Re: [Lazarus] Some thoughts about the global 'Application' instance. An: "Lazarus mailing list" <[email protected]> Datum: Samstag, 20. Juni 2009, 16:11 Joost van der Sluis wrote: > Hi all, > > 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. > > Take for example the fpcgi unit from fcl-web. (not the old one from > Lazarus) There a global variable Application is defined and initialized > and finalized. This Application should be used throughout the program. > > 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! > Hm, following the thread, there are various ideas, how the case of 2 application instances should/could be avoided. And would be avoided in an automatic (forceful) manner. The range from: - Replacing Application variable by a function, or even unit - depended initialization of Forms.Application (only if no other app...) Now for a start let's ignore the fact that Interfaces forces us to use the Forms unit. (This is a problem of it's own, which can be fixed with a moderate (or less) amount of work (imho). If a program uses both Forms and fcl-web (or any combination of 2 or more units having an application), how should those units know which application is used? More so, how does anyone but the author of the program now, that only one is used? Example: I may write a cgi-application (therefore it must have the web-fcl CgiApplication, right?), but I want to use this app to report the current screen resolution on the Server, so I do want to access the Screen object from the forms unit, which uses the application instance from the forms unit (and probably would not work weel, with an cgiApplication instance?) So there may be cases where more than one instance of different classes of Application is required. The best way to avoid it, is or the author of the program only to use units that do not instantiate an application, other than the one(s) needed. This brings me back to the original problem: 1) being forced to use Interfaces 2) Intefaces using Forms 2: can be solved: I wrote another mail on that. 1: can be looked at. You are forced to use interfaces, if you use anything that needs to access the widgetsets (btw, in which case you are likely (but only likely) to need the Forms.application). If your code does not access any widgetsets then you shouldn't be forced to use interfaces. If you use a unit containing such code, but don't need the the particular bit of code, you must use smartlinking, or the code is included. Otherwise, ther may be a case to find out why and what is using the widgetsets. Best Regards Martin -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
-- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
