G
grwriter
Unregistered / Unconfirmed
GUEST, unregistred user!
2000年左右我们采用的是Delphi自带的QuickReport,限于QuickReport的局限性,中文折行、自动拉伸行高这种基本的问题都处理不好,用户端设计功能更不可能了。
大概在2003年我们换用了Formula One(F1Book),我们的开发队伍将F1Book封装的很完美,它类Excel的接口,可以满足我们实现任意复杂的报表。但是F1Book不能绑定数据源导致我们每张表都得封装数据接口,开发效率极低,像BUG3中涉及到的报表我们需要2个人工日才能完成。这还不算什么,最致命的是F1Book不再升级了,从我们使用那天起就没有见到过2003年以后的版本,后来逐渐发现F1Book跟N多型号的打印机冲突,越是高级的打印机越冲突。
2004年秋我写申请自助研发报表控件,种种原因公司一直不给立项,郁闷ing。
2005年秋公司决定更换报表系统,我作为组长组织评估市面上现有的报表。
用友华表:鉴于用友华表跟F1Book的实现机理相似,我们首先评估了用友华表。结论是太像F1Book了,如果采用用友华表,我么的产品可以实现零缝隙平滑升级。但是给我们的感觉用友华表就是“打印功能没有问题的F1Book”。经过近一个月的评估,最终我们放弃了用友华表。
FastReport:紧接着又评估了FastReport。结论就一个字“好”。太强大了,连宏都支持。但是对中文处理仍然有问题。太强导致太复杂,我很难想象采用FastReport后我们的产品如何让计算机知识比较欠缺的用户能够再设计。
接下来我们有评估了水晶报表;ReportMachine(FastReport翻版);快乐报表;等等。。。
直到有一天我们看到了Grid++Report,评估结论为:简单、高效、速度快、客户端再设计容易。当然也发现了一些问题,经过跟你沟通,我们决定采用Grid++Report,并且对Grid++Report寄予很高的期望。经过十几封电子邮件的往返,Grid++Report越来越接近于我们的要求,同时我们的产品也已经完成了新报表系统的整合。
大概在2003年我们换用了Formula One(F1Book),我们的开发队伍将F1Book封装的很完美,它类Excel的接口,可以满足我们实现任意复杂的报表。但是F1Book不能绑定数据源导致我们每张表都得封装数据接口,开发效率极低,像BUG3中涉及到的报表我们需要2个人工日才能完成。这还不算什么,最致命的是F1Book不再升级了,从我们使用那天起就没有见到过2003年以后的版本,后来逐渐发现F1Book跟N多型号的打印机冲突,越是高级的打印机越冲突。
2004年秋我写申请自助研发报表控件,种种原因公司一直不给立项,郁闷ing。
2005年秋公司决定更换报表系统,我作为组长组织评估市面上现有的报表。
用友华表:鉴于用友华表跟F1Book的实现机理相似,我们首先评估了用友华表。结论是太像F1Book了,如果采用用友华表,我么的产品可以实现零缝隙平滑升级。但是给我们的感觉用友华表就是“打印功能没有问题的F1Book”。经过近一个月的评估,最终我们放弃了用友华表。
FastReport:紧接着又评估了FastReport。结论就一个字“好”。太强大了,连宏都支持。但是对中文处理仍然有问题。太强导致太复杂,我很难想象采用FastReport后我们的产品如何让计算机知识比较欠缺的用户能够再设计。
接下来我们有评估了水晶报表;ReportMachine(FastReport翻版);快乐报表;等等。。。
直到有一天我们看到了Grid++Report,评估结论为:简单、高效、速度快、客户端再设计容易。当然也发现了一些问题,经过跟你沟通,我们决定采用Grid++Report,并且对Grid++Report寄予很高的期望。经过十几封电子邮件的往返,Grid++Report越来越接近于我们的要求,同时我们的产品也已经完成了新报表系统的整合。