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!

Now in daemonapp.pp to avoid this kind of problems with several different kinds of daemon-applications (the one with lazarus and without) it is done somewhat different. The function Application is defined as a singleton and which kind of application is created depends on a variable which has to be set by units implementing descendents of TDaemonApp.

Can we move this functionality to the CustApp unit? That way you can always refer to custapp.Application and you have the 'current' application instance.

This will be a problem when forms which are loaded using lazarus resource system depend on an instance of Lazarus' TApplication-class... (But maybe that should be avoided?)

Joost

Same in Delphi

I have service and forms application in same exe file, so i have 2 application in same instance.

Zaher Dirkey wrote

Same in Delphi

Which doesn't make it correct.

Two or more Application instances just doesn't seem right.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Op donderdag 18-06-2009 om 16:11 uur [tijdzone +0200], schreef Zaher Dirkey:

Same in Delphi

I know, but can't we come up with a better design?

I have service and forms application in same exe file, so i have 2 application in same instance.

Joost.

Joost van der Sluis wrote

Can we move this functionality to the CustApp unit? That way you can always refer to custapp.Application and you have the 'current' application instance.

Without looking at the code, this sounds like a better plan. I can't remember the exact details (it was very long ago), but I do remember I hit a similar issue in fpGUI Toolkit, and instead implemented my own fpgApplication singleton, which descended directly from TComponent to overcome the issue.

Being able to go back to TCustomApplication included in FPC would be nice. Not to mention the more well known Application instance instead of fpgApplication instance.

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Which doesn't make it correct.

I Agree, but CustApp.pp belong to FPC team.

If it is done, i will like it, because i can create my custom application class then add my special properties.

I see no problem with that.

Michael.

Maybe a solution would be to remove the dependence on Forms, from the interface unit?

there are 2 methods called:
  procedure CreateWidgetset(AWidgetsetClass: TWidgetsetClass);
  procedure FreeWidgetSet;

The first one doesn't actually need to be in Forms. The 2nd (FreeWidgetSet) currently destroys all the global stuff that depends on the interface, so this destruction would have to be done in a different way.

For Example Screens or the Application Object itself. If the Forms unit included the InterFace Unit (or some TheUnitThatContainsCreateAndFreeWidgetSet) then the Forms unit could register all the objects that needs destruction on FreeWidgetSet. That should solve this.

Martin

Op donderdag 18-06-2009 om 16:29 uur [tijdzone +0200], schreef Zaher Dirkey:

>Which doesn't make it correct. I Agree, but CustApp.pp belong to FPC team.

I am from the FPC team. Question is if this won't have all kinds of side-effects I didn't think of. And I didn't discussed with the others of the fpc-team because I know they read this list also.

Joost.

Zaher Dirkey wrote

If it is done, i will like it, because i can create my custom application class then add my special properties.

Exactly what I want to do too. Including improving parameter handling so my custom application can inject it's supported parameters (and -? help output) into the CustApp ones.

eg:
TCustomApplication
|
TfpgApplication
|
TMyProjectApplication

And if you to the following from the Linux command line:

  $ MyProject -?

it will output something like:
================================
MyProject v1.0
Copyright by .....

General parameters
-? Help

fpGUI supported parameters
-display
-style

MyProject supported parameters
-l Log
-lv Log to separate window
-lc Log to console

....

================================

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Zaher Dirkey wrote

> Which doesn't make it correct. I Agree, but CustApp.pp belong to FPC team.

Doesn't matter. There are many FPC developers amongst us. FPCUnit is another console type project which is part of FPC, but Lazarus simply slapped a GUI onto it. :-)

Regards,
- Graeme -

_______________________________________________________ fpGUI - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/

Joost wrote

I am from the FPC team

:)

I like to talk, and forgive me if i be stupid.
in Forms.pas

var
   Application: TApplication = nil;

move it to CustApp.pp

var
   CustomApplication: TCustomApplication = nil;

and replace it in Forms.pas to be a function

function Application: TApplication;
begin
  Result :=  CustomApplication as TApplication;
end;

Thanks for your patience.

or default initialization

function Application: TApplication;
begin
  if CustomApplication = nil then
    CustomApplication := TApplication.Create;
  Result :=  CustomApplication as TApplication;
end;

In a redesign we also should consider the different handling of consol applications with GUI on non-Windows platforms.

Should we (also) have a Process object, for the console part of an application?

Should we have objects at all, for process/application management? When the general TApplication methods are converted into (non-virtual) class methods, these methods can be implemented and used for all application types.

We also could create a true Pascal singleton, in an Application.pp unit.

The primary question IMO is about the role which the Application object plays, in an application in general, and in specialized application types. In the best case we can press all the methods and properties into one class, and add the implementation of application-specific parts by OnXYZ handlers.

DoDi

Op donderdag 18-06-2009 om 21:56 uur [tijdzone +0200], schreef Hans-Peter Diettrich:

I'll do it slowly, step-by-step.

We also could create a true Pascal singleton, in an Application.pp unit.

I'll leave that to the framework-developers. I'll simply add the global variable. Then Lazarus could make a Application.pp unit. And I'll add them for the different daemon and fcl-web applications.

Joost.

Application can be either a variable or a unit, but not both.

When Application is a unit, Application.XYZ refers to XYZ in unit Application.

DoDi

About previous comments.

Application cannot be a unit because this is backwards incompatible.

Application cannot be a function because this is backwards incompatible.

It could be tested if CustApp may have a global variable, for example CustomApplication and somehow link it to the Application variable in forms. Probably if CustomApplication = nil then LCL creates it's application and set's it to CustomApplication too, if not, it just uses whatever is already in CustomApplication. Not sure how to keep both the same if CustomApplication changes, then Application needs and update and vice-versa

About previous comments. Application cannot be a unit because this is backwards incompatible.

How that?

The current application classes and objects are under full control of the library, not of the user. Changing the implementation of the application classes will not break the interface nor other code in the RTL or LCL.

DoDi

Hans-Peter Diettrich wrote

How that?

unit Application;
...
end.
program Felipe;
begin
  DoSomethingWithApp(Application);
end.

FPC: Error in Line X, cannot pass a unit as a parameter

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

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 schrieb am Sa, 20.6.2009:

Von: Martin Friebe
Betreff: Re: [Lazarus] Some thoughts about the global 'Application' instance. An: "Lazarus mailing list"
Datum: Samstag, 20. Juni 2009, 16:11

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

Martin Friebe wrote

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.

MSEgui has tapplication and tguiapplication which both inherit from tcustomapplication. tcustomapplication implements the base funcionalitiy, the eventloop functions are abstract.
tapplication implements a GUI independent eventloop, tguiapplication a GUI eventloop and further GUI application functionality. tcustomapplication is defined in unit mseapplication, tapplication in msenogui, tguiapplication in msegui.

In a GUI application add msegui to uses of the mainprogram, in an application without GUI dependency add msenogui to uses of the mainprogram. In a unit with GUI use msegui.application, in a unit without GUI dependence use mseapplication.application.

msenogui registers tnoguiapplication in initialization:
"
initialization
 registerapplicationclass(tnoguiapplication);
"
msegui registers tinternalguiapplication and returns a tguiapplication
instance in application function:
"
function application: tguiapplication;
begin
 if appinst = nil then begin
  tinternalapplication.create(nil);
 end;
 result:= appinst;
end;
"
in order to avoid circular unit references in msegui it is a little bit
complicated. ;-)
tinternalapplication.create() sets msegui.appinst variable:
"
constructor tinternalapplication.create(aowner: tcomponent);
begin
 appinst:= self;
 inherited;
"
The inherited tcustomapplication.create() sets mseapplication.appinst which is
actually a copy of msegui.appinst:
"
constructor tcustomapplication.create(aowner: tcomponent);
begin
 if appinst  nil then begin
  raise exception.create('Application already created.');
 end;
 appinst:= self;
"
mseapplication.application returns a tcustomapplication instance:
"
function application: tcustomapplication;
begin
 if appinst = nil then begin
  if appclass = nil then begin
   raise exception.create('No application class registered.');
  end;
  appclass.create(nil);
 end;
 result:= appinst;
end;
"

Martin

Samuel Herzog wrote

By the way, I was always wondering why there is not TUser object and no TComputer.

There are several reasons to avoid doing this in cross-platform ways. There might devel an shear infinitely complex matrix of dependancies, and permission requirements to gather and access the info.

Those are defined by Delphi and thus needed for compatibility.

As a side note:
CGI applications are actually non-GUI applications. Which also means they can run on for example a Linux server that doesn't have a GUI running or even installed. So including Forms unit or any GUI units for that matter is going to causes that CGI application to fail or report errors on startup anyway because they cannot find the DISPLAY environment variable or open a connection to the running X11 server. I have first hand experience with this and had to rework the core tiOPF framework units to be truly non-gui, at which point my CGI apps and console based unit test suite started working correctly.

Windows users never detect this problem, because you don't get Windows severs without a GUI (though I believe Microsoft is working on such a Server release now).

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

As far as I know, Windows server 2008 is supposed to be able to work without GUI.

Michael.

True, but not the point, sorry.

The point I was trying to make, is that a developer may, for whatever reason, under whatever conditions and assumptions *intentionally* add more than one unit wich creates an application. And this developer may access all of those created applications for different scenarios. This may not be common, this may be rare indeed, but possible.

So the question I was raising was: Is forcefully avoiding any multi-app scenario the right solution?

The problem was started due to being forced to use a unit, that the developer didn't want. IMHO this must be solved, the rest is responsibility of the developer.

Best Regards
Martin

Martin Friebe wrote

True, but not the point, sorry.

I know and understood that. I just wanted to make it clear that by pulling in "gui" units into a CGI (non-gui) application is not a good idea.

So the question I was raising was: Is forcefully avoiding any multi-app scenario the right solution?

Well me being someone that loves OO design and all things to do with design patterns have the following thought - my opinion only. ;-) The Application variable, as introduced in the Forms unit encapsulates an application. Seeing that you also only create one application per executable, there should in theory only be one Application variable/instance/singleton. To me, this should apply to GUI or non-gui (console or cgi/web based) applications.

The problem was started due to being forced to use a unit, that the developer didn't want. IMHO this must be solved,

Correct, and exactly the same problem I had to resolve in the tiOPF framework. Many non-gui functionality units pulled in GUI units. The biggest culprit was the Forms unit as well. And seeing that all my applications are non LCL or VCL based, I did not have a Forms unit in fpGUI Toolkit, so quickly discovered the problem. Reworking the tiOPF frame was required and a few abstractions implemented to separate the gui and non-gui code.

Regards,
- Graeme -

________________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Please give an example.

Unit interfaces adds a LCL widgetset into you program. Unit forms requires some LCL widgetset.
These both units are interdependent, you can not get one without the other. If you want to use forms in a non gui application, use the nogui widgetset.
Creating a second application instance is not portable. It is not enough to create two Application objects.
For example cgi+gui makes no sense under linux, and widgetsets like gtk and qt are more than gui frameworks.

Mattias

True Interfaces and forms unit are closely linked, infactneither makes sense without the other.

But unless I misunderstand the beginning of this whole thread: That is not the issue here.
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:

....

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....

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. I haven't verified this. I would normally assume this should only be needed, if you do use anything that uses the widgetset, and I did hope that if you do not touch anything widget related, you should still be able to compile without even using interfaces.
However the whole last sentence may be taken once more to the test, if for some reason you do not smart-link your application.

In any case. as far as I am concerned there is no point in having any checks in Forms, or any other unit, to detect a multiple application situation. It comes down to *not* using units that would cause this.

And if indeed there is a situation where dependencies force you to do so (which is what I thought the initial mail suggested, despite my disbelieve), then the discussion should go how this dependencies can be broken. So no one is forced to use anything they do not want or need.

Best Regards
Martin

Whoever wants to continue this thread: Please give an example for a fcl-web application or daemon-application which is using Lazarus-forms.

And this is what I don't understand.
What part of unit "forms" is needed that does not require the widgetset?

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.

There are some LCL units which do not require the widgetset. Forms was never one of them.
See the unit alllclunits for the dependencies.

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

Mattias

The problem was started due to being forced to use a unit, that the developer didn't want. IMHO this must be solved, the rest is responsibility of the developer.

Other compilers have apptype specific startup code. The same could be achived by a global $define, e.g. APPTYPE, which forces the right app object(s) to be created. Then using units (e.g. Forms) must not necessarily cause the instantiation of another application object.

DoDi

Op maandag 22-06-2009 om 00:39 uur [tijdzone +0200], schreef Mattias Gaertner:

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

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.

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.

Joost van der Sluis wrote

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

I took a quick look, but i don't see how adding LResources add a dependency on forms.

I created a new program (not an application), added LResources to the uses section and LCL as requirement. It compiled without linking errors.

Vincent

Op maandag 29-06-2009 om 16:43 uur [tijdzone +0200], schreef Vincent Snijders:

Hmm. I can't test it now, because Lazarus doesn't even link at all at the moment.

But in my experience, if linking fails or succeeds is more something I would call 'luck', than anything logical. ;(

I think it also has something to do with the debug-information. One of my theories is that when you have compiled Lazarus with a rtl with debuginformation, and thereafter the debuginformation is removed from the rtl, you have to make clean and recompile Lazarus completely.

And the same holds for parts of the fcl and such.

But this theory fails on me as Lazarus is not linking now at all... Maybe an old .ppu somewhere which is not cleaned properly...

Joost

Webmodules are not lazarus forms (TForm/TFrame), are they?

As Vincent wrote: LResources does not use unit forms (not even indirectly). See the lcl/alllclunits.pp for units that do not use unit forms.

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.

TDataModule is part of unit classes, not of the LCL.

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.

Indeed, you don't need it, so don't use it. You are not forced to use forms nor interfaces.

fileutil is independent of forms too. Again: see lcl/alllclunits.pp

Yes. That is useful.
But having two apps in parallel is not.

:)

I hope this story has now happy ended.

Mattias

Please try to reproduce the bug and give the FPC team at least some hints.
See here for one of those spooky linker errors
http://bugs.freepascal.org/view.php?id=13840

Yes. Golden hint: if it does not link, try a 'make clean all'.

Mattias

Op maandag 29-06-2009 om 17:12 uur [tijdzone +0200], schreef Mattias Gaertner:

I've tried it and it works. But I'm sure I didn't add interfaces just for fun. But maybe those problems were completely unrelated linker-issues.

Thanks,

Joost.

Op maandag 29-06-2009 om 17:17 uur [tijdzone +0200], schreef Mattias Gaertner:

I'll try.

Or fix this:

http://bugs.freepascal.org/view.php?id=14079

Joost.