This brings us to another issue: When I try to format
VirtualTrees.pas it takes a very long time just to
come up with an error that says "Unexpected token '['
near ; on line X position Y".
Is it because you have not optimized JCF for speed
yet, or is it because of the design?
All in all, JCF is a good work; please keep it up.
Cheers,
Adem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Are you sure that this is the offending code? There's no '[' in it.
I shall look into this for Beta 5 when I get the time. You should log it as a bug.
It would be great if you could get a small test unit that crashes - I can add things like that to the regression tests. Otherwise I shall try out the VirtualTrees.pas file.
As for speed: yes, I haven't optimised for speed, and the design is more compute-intensive than V1. I am using a recursive descent to generate a parse tree, which is much more powerfull but also takes more time & memory than just anotating a token stream. The other drawback is that anything that the parser does not understand is an error.
The benefit is that everything else becomes much more straightforward and unambigous. I have never had run speed as a priority goal. (and besides, I don't like huge units). Is the formatter too slow to use every once in a while?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
> Are you sure that this is the offending code? There's no '[' in it.
It seems to look for a '[' rather than find one.
> I shall look into this for Beta 5 when I get the time. You should
> log it as a bug.
>
> It would be great if you could get a small test unit that crashes - I
> can add things like that to the regression tests. Otherwise I shall
> try out the VirtualTrees.pas file.
Below is the code that produces the same error --dont try to run it,
it is just a dumb code ;-)
> As for speed: yes, I haven't optimised for speed, and the design is
> more compute-intensive than V1. I am using a recursive descent to
> generate a parse tree, which is much more powerfull but also takes
> more time & memory than just anotating a token stream. The other
> drawback is that anything that the parser does not understand is an
> error.
It would be more helpful if it went back to the offending line by
itself; but this is just a GUI feature which can be added later.
> The benefit is that everything else becomes much more straightforward
> and unambigous. I have never had run speed as a priority goal. (and
> besides, I don't like huge units). Is the formatter too slow to use
> every once in a while?
You are right, one does not write as big a unit as VirtualTrees.pas
too often. With that sort of code size it probably is more important
to format it as best as it can, rather than as fast as it can.
But, wrt 'once in a while', I personally use code formatter almost
once every 10 minutes just to get my own code right and more readable
to me.
Here is the unit that produces the error in question
PS: One more thing, can you make the text line in the error/exception
messagebox copy-pasteable, so that we can get them back to you without
our own typos added :-)
----------CODE BEGIN----------
Unit CodeFormatTry;
Hi,
JCF does not seem to like it if a class publishes an already protected property.
Here is th sample code.
TVirtualTreeOptions = Class(TCustomVirtualTreeOptions)
Published
Property AnimationOptions;
Property AutoOptions;
Property MiscOptions;
Property PaintOptions;
Property SelectionOptions;
End;
BTW, I took it from Mike Lischke's VirtualTrees.pas
http://www.delphi-gems.com/VirtualTreeview/VT.php
which is arguably the largest codebase for a single set
of classes.
This brings us to another issue: When I try to format
VirtualTrees.pas it takes a very long time just to
come up with an error that says "Unexpected token '['
near ; on line X position Y".
Is it because you have not optimized JCF for speed
yet, or is it because of the design?
All in all, JCF is a good work; please keep it up.
Cheers,
Adem
Are you sure that this is the offending code? There's no '[' in it.
I shall look into this for Beta 5 when I get the time. You should log it as a bug.
It would be great if you could get a small test unit that crashes - I can add things like that to the regression tests. Otherwise I shall try out the VirtualTrees.pas file.
As for speed: yes, I haven't optimised for speed, and the design is more compute-intensive than V1. I am using a recursive descent to generate a parse tree, which is much more powerfull but also takes more time & memory than just anotating a token stream. The other drawback is that anything that the parser does not understand is an error.
The benefit is that everything else becomes much more straightforward and unambigous. I have never had run speed as a priority goal. (and besides, I don't like huge units). Is the formatter too slow to use every once in a while?
Anthony,
> Are you sure that this is the offending code? There's no '[' in it.
It seems to look for a '[' rather than find one.
> I shall look into this for Beta 5 when I get the time. You should
> log it as a bug.
>
> It would be great if you could get a small test unit that crashes - I
> can add things like that to the regression tests. Otherwise I shall
> try out the VirtualTrees.pas file.
Below is the code that produces the same error --dont try to run it,
it is just a dumb code ;-)
> As for speed: yes, I haven't optimised for speed, and the design is
> more compute-intensive than V1. I am using a recursive descent to
> generate a parse tree, which is much more powerfull but also takes
> more time & memory than just anotating a token stream. The other
> drawback is that anything that the parser does not understand is an
> error.
It would be more helpful if it went back to the offending line by
itself; but this is just a GUI feature which can be added later.
> The benefit is that everything else becomes much more straightforward
> and unambigous. I have never had run speed as a priority goal. (and
> besides, I don't like huge units). Is the formatter too slow to use
> every once in a while?
You are right, one does not write as big a unit as VirtualTrees.pas
too often. With that sort of code size it probably is more important
to format it as best as it can, rather than as fast as it can.
But, wrt 'once in a while', I personally use code formatter almost
once every 10 minutes just to get my own code right and more readable
to me.
Here is the unit that produces the error in question
PS: One more thing, can you make the text line in the error/exception
messagebox copy-pasteable, so that we can get them back to you without
our own typos added :-)
----------CODE BEGIN----------
Unit CodeFormatTry;
Interface
Uses
Windows,
Messages,
SysUtils,
Classes,
Graphics,
Controls,
Forms,
ImgList,
ActiveX,
StdCtrls,
Menus,
Printers,
SyncObjs,
VirtualTrees;
Type
TVirtualTreeOptionsTry = Class(TCustomVirtualTreeOptions)
Published
Property AnimationOptions;
Property AutoOptions;
Property MiscOptions;
Property PaintOptions;
Property SelectionOptions;
End;
Implementation
End.
----------CODE END----------
Thank you. The bug has been confirmed and a simple test case has been made. Fixing it will happen soon.
I have worked through the VirtualTrees unit, fixed a few issues. But as I feared, the formatter was stopped by an ifdef at line 2532:
{$ifdef TntSupport}
TVTEdit = class(TTntEdit)
{$else}
TVTEdit = class(TCustomEdit)
{$endif TntSupport}