Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.58:26 Michael Van Canneyt wrote: On Thu, 3 Apr 2008, Martin Schreiber wrote: You used my copyrighted code, the sources look exactly the same. ;-) A strong case against all these copyright suits... :-) And we made the same error, see attachment. It is a little bit more complicated. I hope I got the coding style right. ;-) Martin --- home/mse/packs/standard/svn/fp/trunk/rtl/objpas/classes/.svn/text-base/writer.inc.svn-base 2008-04-03 11:06:35.0 +0200 +++ tmp/svndiff.tmp 2008-04-04 11:51:29.0 +0200 @@ -595,10 +595,15 @@ begin Dummy:=0; Flags := []; - If Assigned(FAncestor) then -Flags:=[ffInherited]; - if csInline in Instance.ComponentState then -Flags:=Flags+[ffInline]; + If (FAncestor nil) and + //has ancestor + (not (csInline in Instance.ComponentState) or + //no inline component + (csAncestor in Instance.Componentstate) and (FAncestors nil)) then + //the inline component is inherited +Flags:=[ffInherited] + else If csInline in Instance.ComponentState then +Flags:=[ffInline]; FDriver.BeginComponent(Instance,Flags, Dummy); WriteProperties(Instance); WriteListEnd; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ The next problem is childpos handling: http://bugs.freepascal.org/view.php?id=11102 Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Fri, 4 Apr 2008, Martin Schreiber wrote: On Thursday 03 April 2008 10.58:26 Michael Van Canneyt wrote: On Thu, 3 Apr 2008, Martin Schreiber wrote: You used my copyrighted code, the sources look exactly the same. ;-) A strong case against all these copyright suits... :-) And we made the same error, see attachment. It is a little bit more complicated. I hope I got the coding style right. ;-) Not quite, I adapted it, no big deal. It's like I said when I fixed the original issue: for inherited forms with inline forms, the original patch was not tested. Anyway, I applied your patch with a slight modification, thank you very much ! Revision 10601. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Fri, 4 Apr 2008, Martin Schreiber wrote: On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ The next problem is childpos handling: http://bugs.freepascal.org/view.php?id=11102 I've never understood what this is about, so some additional information would be welcome... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Fri, 4 Apr 2008, Martin Schreiber wrote: On Friday 04 April 2008 13.56:45 Michael Van Canneyt wrote: On Fri, 4 Apr 2008, Martin Schreiber wrote: The next problem is childpos handling: http://bugs.freepascal.org/view.php?id=11102 I've never understood what this is about, so some additional information would be welcome... It is used in order change the widget stacking order in an inherited form for example: In ancestor form streaming- child- and creation-order is twidget1, twidget2, twidget3 what means (in MSEgui, I don't know for Lazarus) twidget2 is over twidget1, twidget3 is over twidget2. Now you do 'Bring to Front' for twidget1 in a inherited form which changes the child order to twidget2, twidget3, twidget1. Bweeh :( That means I must compare original and new child order. OK, thanks. I'll try to fix this ASAP. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Zitat von Martin Schreiber [EMAIL PROTECTED]: On Friday 04 April 2008 13.56:45 Michael Van Canneyt wrote: On Fri, 4 Apr 2008, Martin Schreiber wrote: The next problem is childpos handling: http://bugs.freepascal.org/view.php?id=11102 I've never understood what this is about, so some additional information would be welcome... It is used in order change the widget stacking order in an inherited form for example: In ancestor form streaming- child- and creation-order is twidget1, twidget2, twidget3 what means (in MSEgui, I don't know for Lazarus) twidget2 is over twidget1, twidget3 is over twidget2. Now you do 'Bring to Front' for twidget1 in a inherited form which changes the child order to twidget2, twidget3, twidget1. The new child order must be written and read back while streaming the descendent. It is done with ffChildPos filerflag and a following integer. Repositioning of the inherited children is done by TComponent.SetChildOrder IIRC. Same for lazarus. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Fixed; There is no test to see what happens when you stream a descendent of a form with an inline form; if you have such a case, please test it. Argh, I just made it too! OK, I'll update from trunk and test it. There are interesting cases with inlined inherited components and the like. Thanks, Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Fixed; There is no test to see what happens when you stream a descendent of a form with an inline form; if you have such a case, please test it. You used my copyrighted code, the sources look exactly the same. ;-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thu, 3 Apr 2008, Martin Schreiber wrote: On Thursday 03 April 2008 10.42:02 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Fixed; There is no test to see what happens when you stream a descendent of a form with an inline form; if you have such a case, please test it. You used my copyrighted code, the sources look exactly the same. ;-) A strong case against all these copyright suits... :-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Fixed; There is no test to see what happens when you stream a descendent of a form with an inline form; if you have such a case, please test it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 20.48:23 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. OK, So: Form1 = TForm1 Frame1 = TMyFrame [inline comes here somewhere] end end When Frame1 is streamed, where do I find TMyFrame ? It's Ancestor is not being streamed ? It is like streaming of an inherited form. Lookup the ancestor and write the property differences. On reading TMyFrame is found by TReader.FindComponentClass (normally by GetFieldClass) as with non inlined child components. TMyFrame.Create loads the TMyFrame instance with the initial form resource data. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Mon, 31 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 20.48:23 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. OK, So: Form1 = TForm1 Frame1 = TMyFrame [inline comes here somewhere] end end When Frame1 is streamed, where do I find TMyFrame ? It's Ancestor is not being streamed ? It is like streaming of an inherited form. Lookup the ancestor and write the property differences. Nono, when streaming an inherited form, the IDE provides the ancestor instance when the streaming starts, because it calls writedescendent. When you have a frame inside a form IDE, the IDE cannot provide the ancestor of the frame: the streaming code must look for the original instance of the frame by itself. My guess is that this is done by setting the OnFindAncestor callback ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 20.42:13 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: I'd like to second Colins wish. Please use the same resolving order as Delphi. MSEide+MSEgui compiles with Delphi7 so the reversed order is an unnecessary complication and error source. It's not a complication. Resolving order is and must be irrelevant. Until 'Loaded' is called, you're not supposed to make any assumptions about what property is and what property is not set, and hence also not about the order. I am not convinced. By controlling the order of the properties and the load order of the forms it is possible to control the resolving order. Does FPC loose on quality if you use the same order as Delphi? It is possible that we don't know all future applications of resolving order at the moment, why should we give away compatibility if not necessary? In my developments I try to constrict the possibilities as little as possible. Often the users of our code do things we never thought. :-) Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Important: Call for testing.
From: [EMAIL PROTECTED] To: fpc-devel@lists.freepascal.org Subject: RE: [fpc-devel] Important: Call for testing. Date: Sun, 30 Mar 2008 22:21:52 + I have noticed another incompatibility with the previous version - the TParser object in parser.inc can now return toWString as one of the possibilities; the previous version returned toString regardless, but offered a wide and normal version of the string. This change breaks lazarus on wide strings. Which should be changed? toWString was missing, now it's more delphi compatible and you don't have to check every character of the widestring (returned with TParser.TokenWideString) to determine if the string is really a wide or an ansi string. Note that now you still have a normal and wide version of the string (TokenString / TokenWideString) but Token property can be toWString too. So the only needed change should be in checking for toWString too when checking for toString. Ok, toWString is declared in trunk only, so you should use an ifdef for now. However it will be merged to fixes_2_2 too, so the ifdef will be only needed till 2.2.2 is released. Maybe this patch (for lazarus) solves the issue? (warning: lazarus compiles and runs but I didn't test it). Giulio _ Discover the new Windows Vista http://search.msn.com/results.aspx?q=windows+vistamkt=en-USform=QBRE parser_wstring_patch.diff.gz Description: GNU Zip compressed data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Monday 31 March 2008 15.00:02 Michael Van Canneyt wrote: It is like streaming of an inherited form. Lookup the ancestor and write the property differences. Nono, when streaming an inherited form, the IDE provides the ancestor instance when the streaming starts, because it calls writedescendent. When you have a frame inside a form IDE, the IDE cannot provide the ancestor of the frame: the streaming code must look for the original instance of the frame by itself. My guess is that this is done by setting the OnFindAncestor callback ? Correct. Sorry that I didn't get your question right. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Mon, 31 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 20.42:13 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: I'd like to second Colins wish. Please use the same resolving order as Delphi. MSEide+MSEgui compiles with Delphi7 so the reversed order is an unnecessary complication and error source. It's not a complication. Resolving order is and must be irrelevant. Until 'Loaded' is called, you're not supposed to make any assumptions about what property is and what property is not set, and hence also not about the order. I am not convinced. By controlling the order of the properties and the load order of the forms it is possible to control the resolving order. Does FPC loose on quality if you use the same order as Delphi? It is possible that we don't know all future applications of resolving order at the moment, why should we give away compatibility if not necessary? Simply said: if I must reverse order, then I have to redo the whole cleanroom stuff and it will be exactly as in Delphi. This is not an option. And since resolving order is not something you are supposed to rely on, you're on dangerous ground. As soon as Delphi changes it, your code will break anyway. As I said: the only moment that is guaranteed is the 'loaded' call, stick to that. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Op maandag 31-03-2008 om 16:13 uur [tijdzone +0200], schreef Michael Van Canneyt: Simply said: if I must reverse order, then I have to redo the whole cleanroom stuff and it will be exactly as in Delphi. This is not an option. Is this about mine (cleanroom) code? Maybe I can change it? If someone can explain to me what chould be changed and supply some tests... I haven't looked into the differences. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Monday 31 March 2008 16.13:48 Michael Van Canneyt wrote: On Mon, 31 Mar 2008, Martin Schreiber wrote: I am not convinced. By controlling the order of the properties and the load order of the forms it is possible to control the resolving order. Does FPC loose on quality if you use the same order as Delphi? It is possible that we don't know all future applications of resolving order at the moment, why should we give away compatibility if not necessary? Simply said: if I must reverse order, then I have to redo the whole cleanroom stuff and it will be exactly as in Delphi. This is not an option. I probably don't understand. What is the problem to reverse the iterating order over a list? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Mon, 31 Mar 2008, Martin Schreiber wrote: On Monday 31 March 2008 16.13:48 Michael Van Canneyt wrote: On Mon, 31 Mar 2008, Martin Schreiber wrote: I am not convinced. By controlling the order of the properties and the load order of the forms it is possible to control the resolving order. Does FPC loose on quality if you use the same order as Delphi? It is possible that we don't know all future applications of resolving order at the moment, why should we give away compatibility if not necessary? Simply said: if I must reverse order, then I have to redo the whole cleanroom stuff and it will be exactly as in Delphi. This is not an option. I probably don't understand. What is the problem to reverse the iterating order over a list? It's a single linked list. Not a TList. Reversing it would be a waste of time. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Giulio Bernardi wrote: Maybe this patch (for lazarus) solves the issue? (warning: lazarus compiles and runs but I didn't test it). Giulio It seems to work reasonably OK for me. It doesn't handle the copyright symbol quite right that was causing me problems, but I don't think the previous version did either. It does stop the error message though. Colin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
C Western schreef: Giulio Bernardi wrote: Maybe this patch (for lazarus) solves the issue? (warning: lazarus compiles and runs but I didn't test it). Giulio It seems to work reasonably OK for me. It doesn't handle the copyright symbol quite right that was causing me problems, but I don't think the previous version did either. It does stop the error message though. Giulio, thanks for the patch. Colin, thanks for testing. Applied in r14698. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: On Sat, 29 Mar 2008, Martin Schreiber wrote: On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). Seems fixed now. I hope I have done it correct (your test program runs fine) and didn't break anything else... :( Looks good, thanks. There is a problem with inline components: http://bugs.freepascal.org/view.php?id=11069 Please delete 11068, it was posted private by accident. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On 30 Mar 2008, at 01:32, Michael Van Canneyt wrote: On Sat, 29 Mar 2008, Martin Schreiber wrote: On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Jesus just told me that it is fixed in r10587. Great, I set the bug to resolved. Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). Seems fixed now. Can you also commit tests for these fixed bugs (11059, 11060, 11067) to svn? Jonas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Michael Van Canneyt wrote: Indeed. It completely short-circuits the idea of trying to locally resolve references before trying globally :) Anyway, your hint gave me the idea where to look. I fixed the issue properly. The error was in another routine altogether. Hopefully now 11060 is really fixed. Things now seem to work for me after a little adjustment. I don't know if it is intentional, but the order in which references are satisfied seems to have been reversed in the current version, which revealed a minor error in my code. I suspect I won't be the only one, so it might be kind to reverse the list to avoid similar problems. The other thing that struck me is that unsatisfied references do not throw an error - shouldn't they? (It would have made fixing the error a little easier) How about the following patch: Colin diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/reader.inc trunk.w/fpcsrc/rtl/objpas/classes/reader.inc --- trunk/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 21:15:01.0 + +++ trunk.w/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-30 12:11:52.0 +0100 @@ -658,7 +658,9 @@ begin G:=AddToResolveList(R.FInstance); G.Addreference(R.FRoot,R.FPropInfo,Copy(R.FRelative,1,P-1),Copy(R.FRelative,P+1,Length(R.FRelative)-P)); - end; + end +else + raise EReadError.CreateFmt(SResNotFound, [Ref]); end; L.RemoveItem(R,True); R:=RN; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Jonas Maebe wrote: On 30 Mar 2008, at 01:32, Michael Van Canneyt wrote: On Sat, 29 Mar 2008, Martin Schreiber wrote: On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Jesus just told me that it is fixed in r10587. Great, I set the bug to resolved. Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). Seems fixed now. Can you also commit tests for these fixed bugs (11059, 11060, 11067) to svn? I converted them to fpcunit tests while implementing, but since I don't know yet how to handle those in the testsuite, I didn't commit them yet. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: On Sat, 29 Mar 2008, Martin Schreiber wrote: On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). Seems fixed now. I hope I have done it correct (your test program runs fine) and didn't break anything else... :( Looks good, thanks. There is a problem with inline components: http://bugs.freepascal.org/view.php?id=11069 Please delete 11068, it was posted private by accident. OK, I knew how to handle visual form inheritance so I could fix 11067, but inline I have no idea what it is. Can you explain me what needs to be done, and in what situations it is used ? Alternatively you can supply a patch ;-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, C Western wrote: Michael Van Canneyt wrote: Indeed. It completely short-circuits the idea of trying to locally resolve references before trying globally :) Anyway, your hint gave me the idea where to look. I fixed the issue properly. The error was in another routine altogether. Hopefully now 11060 is really fixed. Things now seem to work for me after a little adjustment. I don't know if it is intentional, but the order in which references are satisfied seems to have been reversed in the current version, which revealed a minor error in my code. I suspect I won't be the only one, so it might be kind to reverse the list to avoid similar problems. Nono, it's good that you fixed your bug. You should never rely on the loading order. For forms, for instance, it is dependent on the creation in the IDE. A simple cut and paste could change the order. Relying on this would be bad practice. The other thing that struck me is that unsatisfied references do not throw an error - shouldn't they? (It would have made fixing the error a little easier) How about the following patch: Delphi doesn't throw an error either, and it should definitely not do so at the end of local reference resolving; At most this could be done after all loading is done, and you don't know when that is: forms can be created at any time... Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Michael Van Canneyt wrote: Nono, it's good that you fixed your bug. You should never rely on the loading order. For forms, for instance, it is dependent on the creation in the IDE. A simple cut and paste could change the order. Relying on this would be bad practice. Absolutely The other thing that struck me is that unsatisfied references do not throw an error - shouldn't they? (It would have made fixing the error a little easier) How about the following patch: Delphi doesn't throw an error either, and it should definitely not do so at the end of local reference resolving; At most this could be done after all loading is done, and you don't know when that is: forms can be created at any time... It still seems strange not to throw an error. The point I suggested is the first time that it is definitely known that the local reference will never be resolved, as at that point the reference is simply thrown away if not resolved. (Or am I missing something?) Colin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 17.56:40 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: Looks good, thanks. There is a problem with inline components: http://bugs.freepascal.org/view.php?id=11069 Please delete 11068, it was posted private by accident. OK, I knew how to handle visual form inheritance so I could fix 11067, but inline I have no idea what it is. Can you explain me what needs to be done, and in what situations it is used ? Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sunday 30 March 2008 19.21:04 Vincent Snijders wrote: Martin Schreiber schreef: Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. Alternatively you can supply a patch ;-) I don't think I am clean enough... Alternatively, you can write the test case ;-) I'll do. The first is http://bugs.freepascal.org/view.php?id=11069 Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 18.08:24 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, C Western wrote: Things now seem to work for me after a little adjustment. I don't know if it is intentional, but the order in which references are satisfied seems to have been reversed in the current version, which revealed a minor error in my code. I suspect I won't be the only one, so it might be kind to reverse the list to avoid similar problems. Nono, it's good that you fixed your bug. You should never rely on the loading order. For forms, for instance, it is dependent on the creation in the IDE. A simple cut and paste could change the order. Relying on this would be bad practice. I'd like to second Colins wish. Please use the same resolving order as Delphi. MSEide+MSEgui compiles with Delphi7 so the reversed order is an unnecessary complication and error source. It's not a complication. Resolving order is and must be irrelevant. Until 'Loaded' is called, you're not supposed to make any assumptions about what property is and what property is not set, and hence also not about the order. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 17.56:40 Michael Van Canneyt wrote: On Sun, 30 Mar 2008, Martin Schreiber wrote: On Sunday 30 March 2008 01.32:09 Michael Van Canneyt wrote: Looks good, thanks. There is a problem with inline components: http://bugs.freepascal.org/view.php?id=11069 Please delete 11068, it was posted private by accident. OK, I knew how to handle visual form inheritance so I could fix 11067, but inline I have no idea what it is. Can you explain me what needs to be done, and in what situations it is used ? Inline is used for subforms, components in a form which inherit from another form (TFrame in Delphi), in MSEgui every form can be used as inline component. The ffInline filer flag must be written and the ancestor must be looked up on writing and reading like inherited components. OK, So: Form1 = TForm1 Frame1 = TMyFrame [inline comes here somewhere] end end When Frame1 is streamed, where do I find TMyFrame ? It's Ancestor is not being streamed ? Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
I have noticed another incompatibility with the previous version - the TParser object in parser.inc can now return toWString as one of the possibilities; the previous version returned toString regardless, but offered a wide and normal version of the string. This change breaks lazarus on wide strings. Which should be changed? Colin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE: [fpc-devel] Important: Call for testing.
I have noticed another incompatibility with the previous version - the TParser object in parser.inc can now return toWString as one of the possibilities; the previous version returned toString regardless, but offered a wide and normal version of the string. This change breaks lazarus on wide strings. Which should be changed? toWString was missing, now it's more delphi compatible and you don't have to check every character of the widestring (returned with TParser.TokenWideString) to determine if the string is really a wide or an ansi string. Note that now you still have a normal and wide version of the string (TokenString / TokenWideString) but Token property can be toWString too. So the only needed change should be in checking for toWString too when checking for toString. Ok, toWString is declared in trunk only, so you should use an ifdef for now. However it will be merged to fixes_2_2 too, so the ifdef will be only needed till 2.2.2 is released. Giulio _ News, entertainment and everything you care about at Live.com. Get it now! http://www.live.com/getstarted.aspx___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Fri, 28 Mar 2008, Vincent Snijders wrote: Martin Schreiber schreef: On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ http://bugs.freepascal.org/view.php?id=11059 Does this cause no problems for Lazarus? 11059 should be fixed. I added this and 11060 to the cleanroom page. http://wiki.lazarus.freepascal.org/FPC_Cleanroom#Bug_reports There still is a memleak in the reader, when starting and stopping Lazarus: 333861 memory blocks allocated : 48899445/49814032 333803 memory blocks freed : 48898000/49812384 58 unfreed memory blocks : 1445 I think I plugged that one (Vincent: we had it in the tests too, if you recall). Can you test please ? If it persists, please send me the heaptrc output, that will make searching easier. 11060 is a harder nut to crack, though. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Michael Van Canneyt schreef: There still is a memleak in the reader, when starting and stopping Lazarus: 333861 memory blocks allocated : 48899445/49814032 333803 memory blocks freed : 48898000/49812384 58 unfreed memory blocks : 1445 I think I plugged that one (Vincent: we had it in the tests too, if you recall). Can you test please ? If it persists, please send me the heaptrc output, that will make searching easier. It is not yet fixed. I sent heaptrc to you privately. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Vincent Snijders schreef: Michael Van Canneyt schreef: There still is a memleak in the reader, when starting and stopping Lazarus: 333861 memory blocks allocated : 48899445/49814032 333803 memory blocks freed : 48898000/49812384 58 unfreed memory blocks : 1445 I think I plugged that one (Vincent: we had it in the tests too, if you recall). Can you test please ? If it persists, please send me the heaptrc output, that will make searching easier. It is not yet fixed. I sent heaptrc to you privately. Fixed in 10583: Heap dump by heaptrc unit 338700 memory blocks allocated : 45274460/46194864 338700 memory blocks freed : 45274460/46194864 0 unfreed memory blocks : 0 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
There seems to be a problem in TReader.FindComponentClass - the search in FindInFieldTable does not properly include ancestors. See attached patch Colin diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/reader.inc trunk.w/fpcsrc/rtl/objpas/classes/reader.inc --- trunk/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-28 09:19:50.0 + +++ trunk.w/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 13:38:54.0 + @@ -1470,7 +1470,7 @@ // descendants of TComponent while ComponentClassTypeTComponent do begin FieldClassTable := -PFieldTable((Pointer(RootComponent.ClassType)+vmtFieldTable)^)^.ClassTable; +PFieldTable((Pointer(ComponentClassType)+vmtFieldTable)^)^.ClassTable; if assigned(FieldClassTable) then begin for i := 0 to FieldClassTable^.Count -1 do begin Entry := FieldClassTable^.Entries[i]; ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sat, 29 Mar 2008, C Western wrote: There seems to be a problem in TReader.FindComponentClass - the search in FindInFieldTable does not properly include ancestors. Great, I applied the patch. This should probably fix issue 11060 ! Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
There also seems to be a problem with fixing up references to other
components while reading - TLabel.FocusControl seems to be one of the
things that is tripping this up. Local unresolved references are being
silently discarded, but I think should be added to the global list. The
attached patch fixes it for my application, but might not be the best
general fix.
Colin
diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/reader.inc trunk.w/fpcsrc/rtl/objpas/classes/reader.inc
--- trunk/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 16:56:06.0 +
+++ trunk.w/fpcsrc/rtl/objpas/classes/reader.inc 2008-03-29 16:57:37.0 +
@@ -630,7 +630,7 @@
procedure TReader.DoFixupReferences;
Var
- R,RN : TLocalUnresolvedReference;
+ R : TLocalUnresolvedReference;
G : TUnresolvedInstance;
Ref : String;
C : TComponent;
@@ -644,7 +644,6 @@
R:=TLocalUnresolvedReference(L.Root);
While (RNil) do
begin
- RN:=TLocalUnresolvedReference(R.Next);
Ref:=R.FRelative;
If Assigned(FOnReferenceName) then
FOnReferenceName(Self,Ref);
@@ -654,14 +653,10 @@
else
begin
P:=Pos('.',R.FRelative);
-If (P0) then
- begin
- G:=AddToResolveList(R.FInstance);
- G.Addreference(R.FRoot,R.FPropInfo,Copy(R.FRelative,1,P-1),Copy(R.FRelative,P+1,Length(R.FRelative)-P));
- end;
+G:=AddToResolveList(R.FInstance);
+G.Addreference(R.FRoot,R.FPropInfo,Copy(R.FRelative,1,P-1),Copy(R.FRelative,P+1,Length(R.FRelative)-P));
end;
- L.RemoveItem(R,True);
- R:=RN;
+ R:=TLocalUnresolvedReference(R.Next);
end;
FreeAndNil(FFixups);
end;
diff -uNr --exclude=.svn --exclude='*.rst' trunk/fpcsrc/rtl/objpas/classes/resref.inc trunk.w/fpcsrc/rtl/objpas/classes/resref.inc
--- trunk/fpcsrc/rtl/objpas/classes/resref.inc 2008-03-28 09:19:50.0 +
+++ trunk.w/fpcsrc/rtl/objpas/classes/resref.inc 2008-03-29 16:57:37.0 +
@@ -220,7 +220,10 @@
C : TComponent;
begin
- C:=FindGlobalComponent(FGlobal);
+ if FGlobal '' then
+C:=FindGlobalComponent(FGlobal)
+ else
+C:=FRoot;
Result:=(CNil);
If Result then
begin
@@ -229,7 +232,7 @@
If Result then
SetObjectProp(Instance, FPropInfo,C);
end;
-end;
+end;
Function TUnresolvedReference.RootMatches(ARoot : TComponent) : Boolean; Inline;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Jesus Reyes A. schreef: - Original Message - From: C Western [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Saturday, March 29, 2008 11:04 AM Subject: Re: [fpc-devel] Important: Call for testing. There also seems to be a problem with fixing up references to other components while reading - TLabel.FocusControl seems to be one of the things that is tripping this up. Local unresolved references are being silently discarded, but I think should be added to the global list. The attached patch fixes it for my application, but might not be the best general fix. Colin This patch fixes issue 11060, however, while trying to open project's compiler options dialog I get this: snip Other dialogs seems to be fine though. Jesus just told me that it is fixed in r10587. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sat, 29 Mar 2008, Vincent Snijders wrote: Jesus Reyes A. schreef: - Original Message - From: C Western [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Saturday, March 29, 2008 11:04 AM Subject: Re: [fpc-devel] Important: Call for testing. There also seems to be a problem with fixing up references to other components while reading - TLabel.FocusControl seems to be one of the things that is tripping this up. Local unresolved references are being silently discarded, but I think should be added to the global list. The attached patch fixes it for my application, but might not be the best general fix. Colin This patch fixes issue 11060, however, while trying to open project's compiler options dialog I get this: snip Other dialogs seems to be fine though. Jesus just told me that it is fixed in r10587. Great, I set the bug to resolved. Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Jesus just told me that it is fixed in r10587. Great, I set the bug to resolved. Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). 11060 seems to be fixed for MSEide too, thanks a lot. Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Sat, 29 Mar 2008, Martin Schreiber wrote: On Saturday 29 March 2008 21.52:51 Michael Van Canneyt wrote: Jesus just told me that it is fixed in r10587. Great, I set the bug to resolved. Seems like the most obvious bugs are fixed. Now I wait for the subtle ones to appear ;-) Here it is the first one: http://bugs.freepascal.org/view.php?id=11067 (Wrong ancestor value in defineproperties). Seems fixed now. I hope I have done it correct (your test program runs fine) and didn't break anything else... :( Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ http://bugs.freepascal.org/view.php?id=11059 Does this cause no problems for Lazarus? Martin ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Martin Schreiber schreef: On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: http://bugs.freepascal.org/view.php?id=11059 Does this cause no problems for Lazarus? Yes, it does. I didn't notice before though. It is a problem for non-control TComponent you drop on a form, like a TOpenDialog. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Important: Call for testing.
Martin Schreiber schreef: On Thursday 27 March 2008 21.50:33 Michael Van Canneyt wrote: While extensive testing has been done (using the FPCunit testing framework), and the working of Lazarus with this new code was verified, it is possible that bugs remain. We would therefor very much appreciate that if you have code that uses some of the routines below, that you test your code with the latest FPC from subversion (revision 10572 or above) and report any bugs that you may encounter. If you do, please submit a bugreport in mantis: http://bugs.freepascal.org/ http://bugs.freepascal.org/view.php?id=11059 Does this cause no problems for Lazarus? I added this and 11060 to the cleanroom page. http://wiki.lazarus.freepascal.org/FPC_Cleanroom#Bug_reports There still is a memleak in the reader, when starting and stopping Lazarus: 333861 memory blocks allocated : 48899445/49814032 333803 memory blocks freed : 48898000/49812384 58 unfreed memory blocks : 1445 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
