自动存储数据的有关问题
自动存储数据的问题
1. 我设定了定时器每2秒钟自动存储一次编辑框中的数据（编辑框每两秒钟自动接收串口数据，只显示港接收到的数据），并且把数据和当前时间一起存成.xls文件
2. 经测试，1个小时后，只存储了680行收据，我查看了一下，刚开始时每2秒钟一行数据，不一会就变成3-5秒，后来10-15秒一行了
3. 这是为什么呢？
------解决方案--------------------
定时器在消息队列中的优先级和WM_PAINT一样低,如果其他的什么优先级高的消息打断了它的执行,那么它就只好错过这次中断机会,而等待下次中断了执行了,并且它的定时也不是百分之百地正确,它在WIN98中能捕获到的最低时间间隔是
55MS,在WIN NT中是10MS,至于你那个时间跨度那么大,肯定是程序本身有问题,一般不会造成这么大的差距.
------解决方案--------------------
程序结构有问题，串口数据来了之后，更新界面，再发个消息，用来存储数据。
没有根据界面变化存储数据的道理，也用不到定时器。
或者，你的程序是2秒从串口取一次数据吧？那就取来之后分别送界面和存储，不应该有问题的。
可能的情况是，你的XLS写错了，重复写到某一行，把以前写的覆盖了？
------解决方案--------------------
1，定时器
串口已经是中断事件，本来就应该由它驱动显示更新和数据记录，干嘛还要用定时器？
硬件的中断事件是最好的驱动源，如果用了定时器，就要考虑定时器和串口中断的同步，引起一系列不必要的麻烦，浪费资源，多此一举。
我举个更简单的例子。你的问题相当于，把鼠标的移动坐标写到文件里。。。。。这难道还要个定时器去跟踪吗？鼠标移动不是有消息了吗？
2，记录数据的位置
想不通为什么记录编辑框的数据，而不是把处理后的数据直接记录下来。你把数据Set到编辑框，再Get回来，然后记录到文件，这不是多余吗？
想想数据是怎样产生和消费的，串口是产生数据的，界面和文件是消费数据的，你把已经消费完的数据（编辑框）又拿回来了，又消费了一次（文件）。
可以走直道，偏偏要绕远，真是匪夷所思。
3，串口中断要精心设计
如果串口通讯速度快，不允许你做太多的事。改良一下代码，否则要出麻烦的。
1. 我设定了定时器每2秒钟自动存储一次编辑框中的数据（编辑框每两秒钟自动接收串口数据，只显示港接收到的数据），并且把数据和当前时间一起存成.xls文件
2. 经测试，1个小时后，只存储了680行收据，我查看了一下，刚开始时每2秒钟一行数据，不一会就变成3-5秒，后来10-15秒一行了
3. 这是为什么呢？
------解决方案--------------------
定时器在消息队列中的优先级和WM_PAINT一样低,如果其他的什么优先级高的消息打断了它的执行,那么它就只好错过这次中断机会,而等待下次中断了执行了,并且它的定时也不是百分之百地正确,它在WIN98中能捕获到的最低时间间隔是
55MS,在WIN NT中是10MS,至于你那个时间跨度那么大,肯定是程序本身有问题,一般不会造成这么大的差距.
------解决方案--------------------
程序结构有问题，串口数据来了之后，更新界面，再发个消息，用来存储数据。
没有根据界面变化存储数据的道理，也用不到定时器。
或者，你的程序是2秒从串口取一次数据吧？那就取来之后分别送界面和存储，不应该有问题的。
可能的情况是，你的XLS写错了，重复写到某一行，把以前写的覆盖了？
------解决方案--------------------
1，定时器
串口已经是中断事件，本来就应该由它驱动显示更新和数据记录，干嘛还要用定时器？
硬件的中断事件是最好的驱动源，如果用了定时器，就要考虑定时器和串口中断的同步，引起一系列不必要的麻烦，浪费资源，多此一举。
我举个更简单的例子。你的问题相当于，把鼠标的移动坐标写到文件里。。。。。这难道还要个定时器去跟踪吗？鼠标移动不是有消息了吗？
2，记录数据的位置
想不通为什么记录编辑框的数据，而不是把处理后的数据直接记录下来。你把数据Set到编辑框，再Get回来，然后记录到文件，这不是多余吗？
想想数据是怎样产生和消费的，串口是产生数据的，界面和文件是消费数据的，你把已经消费完的数据（编辑框）又拿回来了，又消费了一次（文件）。
可以走直道，偏偏要绕远，真是匪夷所思。
3，串口中断要精心设计
如果串口通讯速度快，不允许你做太多的事。改良一下代码，否则要出麻烦的。