Re: [fpc-devel] LocalReferenceFixup
On Wednesday, 6. October 2010 13.49:59 José Mejuto wrote: Hello FPC, 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 ? 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 ___ 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
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
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[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] 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: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 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, 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
