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越来越接近于我们的要求，同时我们的产品也已经完成了新报表系统的整合。
