报表绘制的方法，是非常影响工作效率的，特别是对于格线比较多的表。 　传统的报表绘制，大多数是用的拖拽式，拿部件拖来拽去。后来可能是发现了其中的不便，所以出现了类EXCEL的绘制方法。 　其实，这两者根本不具可比性，类EXCEL的方法明显优于拖拽式，或者说，画报表就应该是用象Excel那样的方法。 　道理非常简单，你见过有人用Powerpoint画表吗？会累死的。大概稍有点常识的人，都会拿Excel画表吧。 　所以，类Excel是必然的方向。

报表绘制的方法，是非常影响工作效率的，特别是对于格线比较多的表。 　传统的报表绘制，大多数是用的拖拽式，拿部件拖来拽去。后来可能是发现了其中的不便，所以出现了类EXCEL的绘制方法。 　其实，这两者根本不具可比性，类EXCEL的方法明显优于拖拽式，或者说，画报表就应该是用象Excel那样的方法。 　道理非常简单，你见过有人用Powerpoint画表吗？会累死的。大概稍有点常识的人，都会拿Excel画表吧。 　所以，类Excel是必然的方向。

当然，宏在带来方便的同时，也有其缺点，写进了宏的表达式在报表设计期间无法进行语法检查，只能在解析后才能查出错误，使用时必须很小心；另外，宏的解析很复杂，会影响表达式的处理速度（C编译器有相当多时间用于解析宏，PASCAL没这问题速度能快很多），对于表达式很多且性能要求很高的情况尽量不要采用宏。曾经有个相关的案例。用户有一张报表希望以某个字段排序输出，需要有正序和逆序两种形式。出于某些设计方面的原因，必须采用数据库的排序运算，即用SQL的ORDER BY子句控制，但该排序字段又不是数值型量，只能用ASC和DESC控制，但排序方向在水晶报表中不可作为参数传递，结果只能制作两张报表（如果是数值型量可通过乘1或-1控制，不必改变排序方向，即可用参数传递了），维护其一致性非常麻烦；而采用华天企业报表系统特有的宏，只要把排序方向作为宏传入就可以轻松解决。

这张表在篮板的统计那里，分成了两层，因此，需要能够生成这种复杂的表头。（实际上这个表头还不算是复杂的，更复杂的情况是需要进行横向的数据展开，在后面的文章中将会提到） 同时，篮板球的总数，是进攻篮板和防守篮板的合计，这就需要能够在报表内自动进行合计。（这种横向的运算，是最简单的运算，复杂的运算，在后面的文章中也会提到）

打印地址标签，是一个并不复杂的功能，但是非常实用。 简单讲，就是将一大堆地址，打印成发信用的地址标签（实际一般是打印在不干胶纸上，不过这事就和报表没关系了）。往往是一张纸上，要打印mxn个标签：

类似的情况非常普遍，比如许多业务单据都是这样，如销售订单、采购单、出差报销单等。 主从报表还可能是包括多个从表（明细表），比如，再增加一个”教育经历”之类的。

一般地，Web报表在一个软件开发项目中占的比例大概是 10% 左右，这两年有上升的趋势，据我现在项目中报表的开发量大的能占到20%。下面的计算还是以10%为标准，每人月的成本按2.5万计算。 以一个100万的软件开发项目为例，Web报表的工作量占 10% ，即开发成本为 10 万元。以 2.5 万 / 人月来计算，这个项目需要用 4 个人月来完成报表工作。在实际的项目中，这 10 万元有几种方式分摊：

图表英文是CHART。 图表的差异，一方面在于是否能实现各种不同样式的图，另一方面在于展现的时候是什么样子。比较好的是在HTML里直接展现，而比较差的就还要通过一个控件。

交叉表的特点是： 数据在横、纵两个方向扩展，即行、列均不固定 左边、上边都有一个表头，而中间是明细区。后面往往还有合计之类的。

Full 报表 Archive