sugestions
hi, I just noticed some things that could be usefull to report to the developers, I don't know if is the right place to post so I posted here.
1. Memory usage - fr_class and fr_rich uses too much memory just by declaring them in uses section, even if I don't have any report. It would be better if the internal singletons like TfrRichForm where created only when a report is going to be used, its usage as it is now is like if i designed my application by instancing all my required forms, even if some of them will be used more or less it dont matter: it uses memory and is not optimized. By adding some more units i got like 2Mb more memory usage without any instance active.
2. HTML exporting - I noticed that fast report creates an single table and adds many and many lines, but dont have any control of column widths and that's the cause of the weird apearance of some reports.
To solve this I think that break the report in more than one table is indispensable.
Of course is a more complicated matter, and the compatibility with the existent reports so the "new feature" could be valid only if the cell have the new property set. But how to do this? Where in the report to split it in a new table? Simple, in the component memo(cell) that we find the property, the line generated will be splitted. Call it "split:boolean" or something like, at least for me it would resolve all problems because the major problem is that the header and the footer have some text that is put in a single column in the report and cause the columns of my lists to be first column= 30% pagewidth and the 2nd,3rd,4th.... to be like 10%, its completely crazy it. I will try to put this in the code but I haven't debugged the sources yet, but i can post later if i got any sucess...
and sorry the bad english
1. Memory usage - fr_class and fr_rich uses too much memory just by declaring them in uses section, even if I don't have any report. It would be better if the internal singletons like TfrRichForm where created only when a report is going to be used, its usage as it is now is like if i designed my application by instancing all my required forms, even if some of them will be used more or less it dont matter: it uses memory and is not optimized. By adding some more units i got like 2Mb more memory usage without any instance active.
2. HTML exporting - I noticed that fast report creates an single table and adds many and many lines, but dont have any control of column widths and that's the cause of the weird apearance of some reports.
To solve this I think that break the report in more than one table is indispensable.
Of course is a more complicated matter, and the compatibility with the existent reports so the "new feature" could be valid only if the cell have the new property set. But how to do this? Where in the report to split it in a new table? Simple, in the component memo(cell) that we find the property, the line generated will be splitted. Call it "split:boolean" or something like, at least for me it would resolve all problems because the major problem is that the header and the footer have some text that is put in a single column in the report and cause the columns of my lists to be first column= 30% pagewidth and the 2nd,3rd,4th.... to be like 10%, its completely crazy it. I will try to put this in the code but I haven't debugged the sources yet, but i can post later if i got any sucess...
and sorry the bad english