jhsy

Results 39 comments of jhsy

正常有值的时候应该为zh这样 出问题的时候 Store中的flowdata全部为null 导致读不到mc

server.js中这个位置增加断点. 就不报错了. 猜测是代码执行的时机出了问题. 导致data被清空, 断点位置的时候flowdata还是有值的

附上解决方案吧. 也不知道对不对. 看不懂这个代码. 可读性太差. draw.js中 判定 mainCell为空就不处理了 ![image](https://user-images.githubusercontent.com/6167532/171360894-ad052893-7180-41c1-a0b1-fe3b69930362.png)

事实上订阅->通知的过程是为了解决项目繁杂. 接口繁多导致的信息不对称 通知机制可以预留接口. - 站内信 - 邮件通知 - 公司内的IM通知 - 有条件的短信平台通知等等

怎么说呢. 信息不对称的代价我觉得是非常耗时和昂贵的. 如果能有提醒能最大化的减少这种影响, 那何乐而不为呢, 如果是我的话. 我可能会将接口的状态做成"类生命周期"一样. 每个周期触发钩子. 钩子检测订阅的事件配置. 触发不同的动作. 比如 post 一个请求出去. 携带变动的参数. 请求的URL可以配置. 当然站内信的模式就无须触发这种钩子. 仅仅是建议供参考.

确实不通过好像. 我的结果 "校验码校验失败,数据校验码为:50, 待校验的校验码为:22, " 十进制的

@Dufresh HI, 我换了个心跳包可以校验了. 现在卡在分包的处理上. 如何重新把这些包拼起来呢. 或者要求终端重传, 不知道有什么好的方案. 你有什么建议吗?

建议你手动编译 静态引用.

正常的数据应该类似这样:`报文:{"t":"all","i":"09b5bafe-6f3e-4a65-89c2-fa29f24d67f0","v":[{"r":84,"c":2,"index":"09b5bafe-6f3e-4a65-89c2-fa29f24d67f0","func":[true,159,"=SUM(C3:C84)"]}],"k":"calcChain"}`