根据穆林森的经验，应该是光标在离开某控件作判断的时候，判断flag出现了不必要的赋值，导致数值型出现了错误。表面上看log，这真是个应该在单体测试时候便被发现解决完全不该留到连接测试的dà_bug，真是阴沟里翻船。可是穆林森知道这部单体程序的复杂程度，为了满足客户的输入习惯和要求，硬生生把spread（制表插件）回车后只能往右移动的限制给打破了，定义了一个静态变量和一大堆的判断flag用来控制光标的走向，第一格回车向右第二格回车向下第三格回车回到上一行右最后一格回车后新建一行……整个程序代码如同曲线救国一般，庞大而且紊乱。穆林森当时笃定自己一定会从项目开始跟到项目结束，所以这个复杂的单体程序自单体开发开始到一遍一遍的修改都由穆林森亲力亲为，反正是写给自己看的也不会有其他人来改动，穆林森便懒了一懒也没有给代码上加很多的注释，所有判断flag的取名都和等差数列一般f1，f2，f3以此类推，后来又因为各种各样的修正等差数列中也有了断层。如今过了将近一个多月再捡起来看，特别是要检查一个事件十七八个flag中出错的到底是哪一个，简直如同大海捞针，况且现在根本不知道是怎样的契机才能点出那个bug。

哦漏！我当初给这些flag取名都该和葫芦娃一样才对啊啊啊啊！！——穆林森内心的小人悔不当初。

作者有话要说：=a=其实我还没想好那bug到底怎么跳出来。。。因为三年多木有编过码了tat所以也许我在对代码之类的描述上会出现bug。。。大家看到bug就当木有看到吧跪谢！

=================项目注释分割线===============

刚刚写了1000字的注释啊。框框死啦吞拉没拉！于是我现在就简单的写一下

穆林森与乔云参与的会计程序是一个客户端+服务器端的程序，前期准备工作不算在内（因为lz也木有做过项目经理所以对综合设计不懂），从开发开始分为程序架构（打地基），大规模单体开发（造房子），连接测试（看看房子门窗是不是都安对了），综合测试（看看房子水电煤是不是都通了），第一次交货（毛胚），交货后大规模对应（装修），最终交货（商品房），交货后质保（售后服务）这几个步骤，穆林森与乔云刚认识的时候是在交货后大规模修正阶段。然后现在就是到了售后阶段，因为售后阶段bug一般来说比较少，对应也不需要花太多人力，所以到这个阶段项目组一般就剩下一到两个人，其余人都进入别的项目进行开发。

=================名词解释分割线===============

bug：程序中的错误

error框：比姨妈红还要血腥的红色错误框，程序出dà_bug又没有被代码中设置好的小警察（catch）抓住的话，就会甩出个血腥大框框。

log：代码中埋下的打log代码，好比程序运行时的心电图，是给开发人员检查程序用的。

flag：就好比程序的某个地方安插了一个小警察，程序如果走到这个小警察面前了，小警察就看看它接下来该走哪条路，给它头上插面旗子（就是文中提到的赋值），到下一个分叉路口就按照头上那面旗子指示的路去走。

spread：当年我开发程序时候用到的最为棘手的插件，和excel一样是个表格插件，和excel一样，按回车光标只能向右跳（excel是回车过后光标向下跳），然后客户要求表格里两行一个单元，在这个单元里光标要从上到下再从左到右跳，也就是说客户规定了一条光标移动的线路，而表格插件不允许，这个时候就要程序代码作出判断，那个判断就是靠上面所提到的flag小旗子来实现的。

注释暂时那么多tat不知道大家能不能看懂。