winform程序 读取不定时跟新的数据 界面需要同步显示 如何解决

Question

现在开发 机器人 监视软件  由于机器人状态不确定 获取其各轴角度的时候 角度更新时间不定 现在需要同步显示于界面上
用timer控件 卡死
不准备用数据库 因为我不会 求指导

Answer 1

你数据量很大？一般timer够用了，也不至于卡死

Answer 2

不需要timer轮询
把机器人的状态数据作为事件源，
事件触发更新界面

Answer 3

一个timer不至无响应，软件发送获取数据命令之后的响应方式或者处理数据方式应该是问题所在。

Answer 4

使用timer卡死，有可能是因为重入问题，
如果数据解析和展示花费的时间超过了timer的interval，就会重入
而timer中的处理逻辑不允许重入，那就悲剧了
处理方法可以3楼说的，将数据接收和解析分离；
也可以将timer换成thread

Answer 5

实现“获取各轴角度”的时候，至少需要你懂的 INotifyPropertyChanged 模式，才能搞有效率的开发。否则只能纠结于胡乱轮询的频率问题没完没了。

Answer 6

使用 timer 感觉“卡死”，主要是因为浪费了大量时间去做无用功，这种间隔时间越短越对系统性能造成严重影响，而就算是拼命缩短这个时间间隔也还是尴尬地发现“对数据变化的展示是一卡一卡的”而不是流畅的。使用轮询本来就是一个编程设计大忌。几乎所有的交互操作都是事件驱动模式的，那么没有这个设计概念就会如此。

Answer 7

使用backgroundWorker后台线程控件，可以解决你说的问题！

Answer 8

sqldependency  数据库通知服务

Answer 9

怎么可能卡死，肯定是你代码的问题 这个问题很简单。。最简单的方法流程。。
创建一个后台线程：线程的过程
  
  AxisDatas old;
    void Porc()
    {
         AxisDatas  a=ReadData();   //读取所有
       if(IsEquals(old,a)==false)     //比对是否变化(函数自己完成)，没变化不通知
      {
               old=a;
               MainWindow.BeginInoke(UpdatePorc ,a);     //UpdateProc是一个前台的更新函数，参数就是a,BeginInvoke是转到前台运行这个函数
       }
   }UpdatePorc 需要内部的实现控制下更新频率，可以不每条更新到前台，加入1毫秒一次，能卡死你，可以间隔着来，控制在200毫秒一次就行

Answer 10

不懂没有关系，你知道有设计模式问题以后加入正规开发团队时引起注意就行了。我们遇到过许多次，比如说某个很好的产品，突然某个新来的研究生自以为会编程，结果胡乱加入了一个50毫秒检测一次的 timer，结果系统软件就越来越卡。而假设这个时候整个团队的开发人员基本上都是那种只知道“各人自扫门前雪”的人，没有人曾经注意过学习好设计模式问题，那么他们也就不会及时汇报这颗老鼠屎坏了这一锅汤，那么这个软件系统就会持续一段时间都一直很卡，甚至可能造成用户、投资人不满，甚至造成“腾讯公司的一个做邮箱的团队的小产品反而把别的更专业的大团队的微信给淘汰了”的悲剧。疯狂轮询是个坑爹的设计模式。要学会基本的事件驱动设计思想，这才刚刚开始学程序设计。

Answer 11

对如果用timer只获取数据的话 不卡 但是涉及到 仿真 需要 模型的运动 跟 实际机器人的动作 同步 这样就造成了界面的卡顿

Answer 12

这里最基本的设计模式设计理念就是：当各轴角度没有读取时什么也不做，当各轴角度的简单属性发生改变时立刻去界面绘制（不管是同步还是异步处理）。根本不用什么 timer。

Answer 13

不懂没有关系，你知道有设计模式问题以后加入正规开发团队时引起注意就行了。我们遇到过许多次，比如说某个很好的产品，突然某个新来的研究生自以为会编程，结果胡乱加入了一个50毫秒检测一次的 timer，结果系统软件就越来越卡。而假设这个时候整个团队的开发人员基本上都是那种只知道“各人自扫门前雪”的人，没有人曾经注意过学习好设计模式问题，那么他们也就不会及时汇报这颗老鼠屎坏了这一锅汤，那么这个软件系统就会持续一段时间都一直很卡，甚至可能造成用户、投资人不满，甚至造成“腾讯公司的一个做邮箱的团队的小产品反而把别的更专业的大团队的微信给淘汰了”的悲剧。疯狂轮询是个坑爹的设计模式。要学会基本的事件驱动设计思想，这才刚刚开始学程序设计。谢谢您的发言 我是否可以使用多线程 后台时时获取同时去除重复数据 然后跟新界面数据？

Answer 14

比如说“当某某数值改变是我要......，当某某集合增删单元时我要......，当用户在文本框输入时我要.......，当用鼠标移开某区域时我要........，当用户把窗体拖到 windows 桌面边缘时需要......，当网络中断后应该..............”等等等等无数的底层事件驱动概念。至于从业务逻辑出发的的事件驱动的描述就更多了。那么没有学过真正软件设计的人，他满脑子就是用轮询的“while 循环+线程+自阻塞”或者timer来模拟那些事件驱动开发技术，他画出的流程图、状态图、消息时序图都是同步轮询的而不是事件驱动的，所以他写出的代码也就不可能是最终的一个真正的性能尚可的正规产品需要的代码。

Answer 15

ABB机器人公司提供的封装接口 来实现pc跟机器人之间的通信 我想了 时时同步确实很难做到 因为每次只能读取一次数据 轮询也不能实现同步

Answer 16

不懂没有关系，你知道有设计模式问题以后加入正规开发团队时引起注意就行了。我们遇到过许多次，比如说某个很好的产品，突然某个新来的研究生自以为会编程，结果胡乱加入了一个50毫秒检测一次的 timer，结果系统软件就越来越卡。而假设这个时候整个团队的开发人员基本上都是那种只知道“各人自扫门前雪”的人，没有人曾经注意过学习好设计模式问题，那么他们也就不会及时汇报这颗老鼠屎坏了这一锅汤，那么这个软件系统就会持续一段时间都一直很卡，甚至可能造成用户、投资人不满，甚至造成“腾讯公司的一个做邮箱的团队的小产品反而把别的更专业的大团队的微信给淘汰了”的悲剧。疯狂轮询是个坑爹的设计模式。要学会基本的事件驱动设计思想，这才刚刚开始学程序设计。

Answer 17

你加一张表A，用来记录哪张表的数据有变化，有表名和值两个字段，表名字段记录你要监控的表的表名，值字段记录这表数据是否有变化，有变化值为1，无变化则为0，这个操作可以用触发器实现。然后再通过timer轮询A表，毕竟这表的数据量不大，不会影响性能，只要查到值为1的表，即数据有变化的表，则重新去执行查这表的数据并展示，同时更新A表里面对应这表对应的值为0，即这表我已更新了，下次轮询不用再重新查它，不断执行就可以了

Answer 18

首先time 可能比太可取，但是我建议你还是用 异步 线程，这样至少UI 不会卡死，用户体验会很好，至于你用不用数据库 那得看你想怎么设计此软件。