Hello FPC,

I find a problem that I'm unable to resolve, with my limited skills. In TReader when a property is a TClass it is being added to be resolved after all components are loaded, but the "Loaded" call is performed before this fixup, so when a component receive the "Loaded" signal some fields are still not completly filled in.

This is terrible in the SQLQuery (from Lazarus) as if you left anyone "Active" it always complaint in runtime with "Database not set". :(

Use
"
procedure BeginGlobalLoading;
procedure NotifyGlobalLoading;
procedure EndGlobalLoading;
"
MSEgui has
"
procedure msebegingloballoading; //recursive
procedure mseendgloballoading; //calls notifygloballoading in level 0 "
in order to simplify the task.

Martin

Hello Martin,

MS> Use
MS> "
MS> procedure BeginGlobalLoading;
MS> procedure NotifyGlobalLoading;
MS> procedure EndGlobalLoading;
MS> "

I see, but there is still a problem, I think. Let me explain:

1) Component is being read, it reads Active property, if set and csLoading then the "active" is postponed to "afterload".
2) The "Database" property is being read, but as it is a TClass it is added to LocalFixups.
3) The remaining properties are beign read.
4) Component is notified with "Loaded" signal, so it tries to active itself, but database is not set.
5) Fixups are performed.
6) Component is notified again with "Loaded" signal.

I do not know how to instruct the component to skip the first "Loaded" signal and wait for the next one, specially because if "Database" is not set (trully error) the second "Loaded" signal will not be fired. Maybe a component state like "csFixupsPending" ?

I do not have too much experience with components, but calling "Loaded" several times does not look very fine.

To the best of my knowledge: it should be called once only, after the fixups. If it isn't so, this is a bug.

Michael.

Hello FPC,

you wrote

> I do not have too much experience with components, but calling > "Loaded" several times does not look very fine.

MVC> To the best of my knowledge: it should be called once only, after the fixups. MVC> If it isn't so, this is a bug.

Extracted from "reader.inc", comments below...

------------------------------------------------------
[...]
procedure TReader.FixupReferences;
var
  i: Integer;
begin
  DoFixupReferences;
  GlobalFixupReferences;
  for i := 0 to FLoaded.Count - 1 do
    TComponent(FLoaded[I]).Loaded;
end;
[...]
function TReader.ReadRootComponent(ARoot: TComponent): TComponent;
[...]
      if Assigned(GlobalLoaded) then
        FLoaded := GlobalLoaded
      else
        FLoaded := TFpList.Create;
      try
        if FLoaded.IndexOf(FRoot) < 0 then
          FLoaded.Add(FRoot);
        FOwner := FRoot;
        FRoot.FComponentState := FRoot.FComponentState + [csLoading, csReading];
        FRoot.ReadState(Self);
        Exclude(FRoot.FComponentState, csReading);
        if not Assigned(GlobalLoaded) then begin
          for i := 0 to FLoaded.Count - 1 do
            TComponent(FLoaded[i]).Loaded;//----------------------------
        end;
      finally
        if not Assigned(GlobalLoaded) then
          FLoaded.Free;
        FLoaded := nil;
      end;
      GlobalFixupReferences;
[...]
end;
procedure TReader.ReadData(Instance: TComponent);
[...]
  { Fixup references if necessary (normally only if this is the root) }
  If (Instance=FRoot) then
    DoFixupReferences;
end;
[...]
------------------------------------------------------

As you can see the "Loaded" event is called (marked with some //-----) before calling "GlobalFixupReferences", I'll try to add some writeln's here and there to catch the event sequence and post it here for further comments.

That would be good, thank you.

If we can pinpoint the issue, the solution will probably be easy and straightforward.

Michael.

Not if GlobalLoaded is set.

Martin

Hello FPC,

you wrote

> As you can see the "Loaded" event is called (marked with some //-----) > before calling "GlobalFixupReferences",

MS> Not if GlobalLoaded is set.

Yes, but it is not set, because BeginGlobalLoading is not called at all from any point in the code, nor in fpc/rtl nor in Lazarus lcl, nor in Lazarus IDE, but the IDE is not the important thing as the main problem LNet httpsvlt is calling the
"BeginGlobalLoading" unless some other call it using some kind of opaque pointer :-?

------------------------------------------------------------- F:\Lazarus>find "begingloballoading" *.pas;*.pp;*.inc /s

0 lines in 0 files

F:\Lazarus>\fpc\svn\

F:\fpc\svn>find "begingloballoading" *.pas;*.pp;*.inc /s

---- F:\fpc\svn\packages\fcl-net\src\httpsvlt.pp
      BeginGlobalLoading;

---- F:\fpc\svn\rtl\objpas\classes\classes.inc
procedure BeginGlobalLoading;
{ Free the memory occupied by BeginGlobalLoading }

---- F:\fpc\svn\rtl\objpas\classes\classesh.inc
procedure BeginGlobalLoading;

4 lines in 3 files
-------------------------------------------------------------

Is each component which must call "BeginGlobalLoading" ? or is the read logic which must decide when activate the globalloading ?

Avoid circular component references in the forms and adjust the creation order that the referencing forms are created later or use

MSEgui:
"
msebegingloballoading;
[...] create the forms
mseendgloballoading;
"

Lazarus:
"
begingloballoading;
[...] create the forms
notifygloballoading;
endgloballoading;
"
(not tested).

Martin

Hello FPC,

you wrote

> Yes, but it is not set, because BeginGlobalLoading is not called at

[...]
MS> Avoid circular component references in the forms and adjust the creation order MS> that the referencing forms are created later or use [...]
MS> Lazarus:
MS> "
MS> begingloballoading;
MS> [...] create the forms
MS> notifygloballoading;
MS> endgloballoading;
MS> "
MS> (not tested).

I think I can see your point, but from the "end user" point of view this is not a possibility. How to tell to the user, "Remeber you must call beginglobal... and notifyglobal... and finally endglobal... when you create forms with components that need a global loading link reference fixup" :-?

Moreover user can not take care of creation order, it is not deterministic (AFAIK), there is no way to change it in Lazarus and finally it defeats the drag/drop/design paradigm. I have a form with 25 SQLQuery, 23 of them are chained in some way, if I need a new one at the beginning I must delete 23, add the new one, create or paste the 23 again and relink manually again ?

So the final question, should this moved from fpc-devel to Lazarus mailing list ? Is it not considered a bug in the TReader ?

Thank you.

Maybe you mix up component creation order and form/datamodule creation order? I wrote about form/datamodule creation order.
MSEide does not create the code for loading additional forms and datamodules exactly because it is necessary that the user knows what is going on there. Please have a look into the program file of your application. I repeat:

If there are interlinked forms/datamodules either:
- Avoid circular component references.
- Create the referencing forms/datamodules after the referenced forms/datamodules.

Or:
- Call msebegingloballoading.
- Create the forms/datamodules.
- Create mseendgloballoading.

A Lazarus adept may write the necessary steps for Lazarus. If you get the exception in a single form without external component references, that would be another story...

Martin

Hello FPC,

Thursday, October 7, 2010, 8:27:23 AM, you wrote:

MS> Maybe you mix up component creation order and form/datamodule creation order? MS> I wrote about form/datamodule creation order.

The datamodule is created just in program load, before any dependent component is created, so my execution layout is:

1) Main form create (only a bunch of visual options).
2) Datamodules are being created and will keep loaded up to main form destroy.
3) When user selects an option in main form, the new form, with some SQLQuery components inside linked with the already loaded datamodule(s), is being created and the problem happends.

MS> MSEide does not create the code for loading additional forms and datamodules MS> exactly because it is necessary that the user knows what is going on there. MS> Please have a look into the program file of your application. I repeat: MS> If there are interlinked forms/datamodules either: MS> - Avoid circular component references.
MS> - Create the referencing forms/datamodules after the referenced MS> forms/datamodules.

I'm not using MSEide, but of course all referenced objects (databases in this case) are being created before the conflictive forms/components.

MS> Or:
MS> - Call msebegingloballoading.
MS> - Create the forms/datamodules.
MS> - Create mseendgloballoading.

I'll check this approach, but just to circunvent the problem. A different thing is that maybe the bug/problem is in SQLQuery, in TReader, in Lazarus logic or in any other piece of code.

MS> A Lazarus adept may write the necessary steps for Lazarus. MS> If you get the exception in a single form without external component MS> references, that would be another story...

I'm not sure 100%, changed the database connections to datamodules to keep forms a bit cleaner, but I'm quite sure that the same problem happends using a single form with all needed components in the form (as in the past).

As you are the only one replaying (a lot of thanks) this makes me think that other developers think that this behavior is OK in TReader, so I'll try to post a simple form code in the Lazarus list and ask for feedback about how it should work.

Thank you again for your support.

Aha. In MSEgui application.createform()/createdatamodule() must be called in order to allow component linking with already loaded modules, t*form.create() is not enough. I don't know how this works in Lazarus.

Martin

Hello FPC,

Thursday, October 7, 2010, 8:30:06 PM, you wrote:

MS> Aha. In MSEgui application.createform()/createdatamodule() must be called in MS> order to allow component linking with already loaded modules, t*form.create() MS> is not enough. I don't know how this works in Lazarus.

Thank you, I'll try to gather more information from Lazarus list, but if that's the case it completly defeats the advantages of a datamodule and/or the presence of a published Active property in the SQLQuery (as it is only valid if it is false at runtime) :-?

José Mejuto wrote

Thank you, I'll try to gather more information from Lazarus list, but if that's the case it completly defeats the advantages of a datamodule and/or the presence of a published Active property in the SQLQuery (as it is only valid if it is false at runtime) :-?

No, no, in MSEgui it works OK if you call
application.createform(t*form,*forminstance);
 instead of
*forminstance:= t*form.create();

I assume in Lazarus it works too.

Martin

Hello FPC,

you wrote

> Thank you, I'll try to gather more information from Lazarus list, but > if that's the case it completly defeats the advantages of a datamodule > and/or the presence of a published Active property in the SQLQuery (as > it is only valid if it is false at runtime) :-?

MS> No, no, in MSEgui it works OK if you call
MS> application.createform(t*form,*forminstance);
MS> instead of
MS> *forminstance:= t*form.create();
MS> I assume in Lazarus it works too.

Hmmmmm... I was not aware that both modes does not end in the same functionality... (I allways use "n:=TNewForm.Create(Self)") I'll check it. Thank you again.

In Lazarus both use the same loading mechanism. Referenced
datamodules are automatically found if they already exist. The main difference is that CreateForm sets the variable (e.g. Form1) before it creates and loads the form, while Form1:=TForm1.Create(nil) sets Form1 after creation and loading.

It is up to the programmer to create the forms and datamodules in the right order. If you have circle dependencies, follow Martin's advice and enclose the creation of datamodule and forms in Begin/Notify/EndGlobalLoading.

Theoretically the IDE could do this, but this would be quite some work to implement.

Mattias

Hello FPC,

you wrote

> Aha. In MSEgui application.createform()/createdatamodule() must be called in > order to allow component linking with already loaded modules, t*form.create() > is not enough. I don't know how this works in Lazarus.

MG> In Lazarus both use the same loading mechanism. Referenced MG> datamodules are automatically found if they already exist. MG> The main difference is that CreateForm sets the variable (e.g. MG> Form1) before it creates and loads the form, while MG> Form1:=TForm1.Create(nil) sets Form1 after creation and loading. MG> It is up to the programmer to create the forms and datamodules in the MG> right order. If you have circle dependencies, follow Martin's advice MG> and enclose the creation of datamodule and forms in MG> Begin/Notify/EndGlobalLoading.

I'm not aware about any cycle dependency, but I'm not completly sure as I do not know which kind of dependency (from the technical point of view I think) you are talking about, so I'll explain a layuot to try to narrow the source of the problem (my design or library design):

I have a very simple application, 2 forms and 1 datamodule. The first form is a simple "select your option" which will load all forms on demand. When this main form is loaded the datamodule is being created also, but not the second form.

Datamodule
----------
In datamodule I have 1 firebird connection and 1 firebird transaction. The connection is at design time linked with the transaction via property and proper connect data is filled in.

Secondary form
--------------
It have a simple SQLQuery, linked with the firebird connection in the datamodule. Transaction property is automagically filled with the firebird connection transaction. The "Active" property is set to true and at design time if I drop a grid I can see that data is being retrieved.

Relationship
------------

Main Second form Datamodule
+------+ +----------+ +---------------+
| | | SQLQuery |+---> SQLConnection --+
|Button-->| | || | | |
+------+ +--------+--+---> Transaction <---+
+---------------+

Creation order
--------------
1) Create main form
2) Create data module
3) Wait in main form for user input
4) Create second form

I had put some writeln in the source code at the property sets of active and database of SQLQuery and the expected sequece is:

------
qryGroupClientsWatch set active to: -1
qryGroupClientsWatch set to database
qryGroupClientsWatch set active to: -1
------

First line receives the "Active:=true", but as csLoading is present it sets a flag to activate after complete loading, second line sets the database property and the third line should came from the "Loaded" event which checks the flag and if not csLoading is present try to open the dataset. This layout must work.

But the layout that I receive is:

------
qryGroupClientsWatch set active to: -1
qryGroupClientsWatch set active to: -1
------

First line is the "Active:=true", as csLoading is present the activate is delayed. The reader reads the database property, as it is a tkClass it add it to LocalReferenceFixups and do not set the property (so no call to property set), and them the "Loaded" event is fired and as csLoading is not present it tries to open the dataset raising the "database not set" exception.

I hope I had explained it in detail.

application.createform() or t*form.create()

2) Create data module

 application.createdatamodule();

3) Wait in main form for user input 4) Create second form

application.createform() or t*form.create()

Such a scenario works in MSEgui.

Hello FPC,

you wrote

> Creation order > -------------- > 1) Create main form

MS> application.createform() or t*form.create()

> 2) Create data module

MS>  application.createdatamodule();

> 3) Wait in main form for user input > 4) Create second form

MS> application.createform() or t*form.create()
MS> Such a scenario works in MSEgui.

------------
Application.Initialize;
Application.CreateForm(TfrmWorkbench, frmWorkbench);
Application.CreateForm(TdmCharting, dmCharting);
Application.Run;
------------
------------
procedure TfrmWorkbench.BitBtn5Click(Sender: TObject);
var
  r: TfrmReportByFile;
begin
  Application.CreateForm(TfrmReportByFile,r);
  r.Show;
end;
------------

Does not work in Lazarus almost up to date SVN, and fpc 2.5.1 July 2010

But if my memory serves me, it does not work at least since Lazarus 0.9.26 and the related fpc version.

I had not reported it before because I think that the problem was the missing datamodules, so I converted everything to use datamodules, but the problem remains.

Zitat von José Mejuto :

Please provide an example.
Either you are misusing the sql components or there is a bug in the sql components.

Database components should work independent of the owner class.

Mattias

Hello FPC,

Friday, October 8, 2010, 2:44:33 PM, you wrote:

MG> Please provide an example.
MG> Either you are misusing the sql components or there is a bug in the MG> sql components.

Attached is the example. One form that load a "menu" which opens a new form which display a table in a grid. You will need to change the password setup, and maybe database (I'm using aliases instead full path), and of course the sql line.

Example is an small Lazarus project.

> I had not reported it before because I think that the problem was the > missing datamodules, so I converted everything to use datamodules, but > the problem remains.

MG> Database components should work independent of the owner class.

At the first try, it works using all components in a single form, once moved to a datamodule, it starts to fail, but I'm quite sure that usually it also fails with all components in the same form.

I converted the example to MSEgui, works OK.

Martin

Hello FPC,

MS> I converted the example to MSEgui, works OK.

So or the problem is in LCL or I'm suffering some kind of poltergeist. Thank you taking the time to perform the test.

José Mejuto wrote

MS> I converted the example to MSEgui, works OK. So or the problem is in LCL or I'm suffering some kind of poltergeist.

Or in SQLDB. MSEgui has a forked SQLDB which has completely rewritten parts.

Martin