Re: [fpc-devel] LocalReferenceFixup
On Thu, 7 Oct 2010 20:30:06 +0200 Martin Schreiber wrote: > On Thursday, 7. October 2010 17.25:28 José Mejuto wrote: > > 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. > > > 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. 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
Hello FPC, Thursday, October 7, 2010, 9:21:18 PM, 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. Hm... 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. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LocalReferenceFixup
On Thursday, 7. October 2010 20.46:54 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
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) :-? -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LocalReferenceFixup
On Thursday, 7. October 2010 17.25:28 José Mejuto wrote: > 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. > 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 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re[2]: [fpc-devel] LocalReferenceFixup
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. -- Best regards, José ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TDOMDocument.GetTextContent implementation seems wrong
On 7 October 2010 13:35, Sergei Gorelkin wrote: >> > Compliance, see > http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-textContent > > specifies that textContent property should be null for Document, Notation > and DocumentType nodes. OK, thanks for the information Sergei. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net:8080/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TDOMDocument.GetTextContent implementation seems wrong
Graeme Geldenhuys wrote: Hi, The current hierarchy in the dom unit is as follows TDomNode | TDOMNode_WithChildren | TDOMDocument Now the GetTextContent() implementation for TDOMNode_WithChildren runs recursively through all child nodes collecting data. ...but the GetTextContent() implementation of TDomDocument simply returns '', without calling inherited GetTextContent; so we loose all the functionality implemented in TDOMNode_WithChildren! Why is that? Compliance, see http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Node3-textContent specifies that textContent property should be null for Document, Notation and DocumentType nodes. Regards, Sergei ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TDOMDocument.GetTextContent implementation seems wrong
Hi,
The current hierarchy in the dom unit is as follows
TDomNode
|
TDOMNode_WithChildren
|
TDOMDocument
Now the GetTextContent() implementation for TDOMNode_WithChildren runs
recursively through all child nodes collecting data.
...but the GetTextContent() implementation of TDomDocument simply
returns '', without calling inherited GetTextContent;
so we loose all the functionality implemented in
TDOMNode_WithChildren! Why is that?
So the following code (under FPC) simply results in returning nothing,
because FXMLDoc is a TDomDocument instance. :-/
I'm using FPC 2.4.3 here...
-
destructor TXMLListener.Destroy;
var
Stream: TFileStream;
S: string;
begin
{$IFDEF FPC}
S := FXMLDoc.TextContent;
{$ELSE}
S := FXMLDoc.code;
{$ENDIF}
Stream := TFileStream.Create(FAppPath + FDocName, fmCreate or fmOpenWrite);
try
Stream.Write(PChar(S)^, Length(S));
//Stream.Write(S[1], Length(S));
finally
FreeAndNil(Stream);
end;
FStack := nil;
FreeAndNil(FXMLDoc);
inherited Destroy;
end;
-
--
Regards,
- Graeme -
___
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net:8080/fpgui/
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
