5
5
windows 界面交互跟背后大量的计算,这二者中间存在着并发性,需要你懂的编写异步并发的程序。
可能你只是编写过一些简单的命令行程序,对于交互式程序的设计还是图省事、套用命令行程序那种顺序流程的设计思路。
5
这个问题的根本原因,在于你出于何种考虑需要使用进度条并需要拖动,这有直接的因果关系。
假如拖动后需要立即重新计算(或数值从1变为10需要即时起作用的,那可以考虑后台使用backgroupworker控件。
假如进度条只是装饰的话,就把所谓的“计算方法”异步处理。
反正都得多线程
5
只是告诉你该怎么样起步去学习设计一个良好交互操作体验的程序,不要把交互操作跟简单的数学计算函数扯在一起。正常的滑块的拖动应该是非常顺滑的,原因是 UI 主线程基本上不干什么事儿,每一个UI 操作生命周期都异常短(几毫秒),并不会“卡”上几秒种、几分钟。它跟计算并不是顺序关系,而是并发执行的。
5
纯属个人爱好。是这样一个软件,托动HScrollBar滚动条用以修改地理经纬度和海拔高度;滚动数字框用以修改时区数;在DateTimePicker输入日期;挪动TrackBar用以修改当天的具体时间,然后计算出当前时间和地点的日月和行星的黄道赤道地平坐标,然后再计算出当天的日月和行星的升降与中天的具体时刻。只要地理坐标和当前日期一变,全部的数据就都变了,就都得重新计算。
程序主界面是下面这个样子的。
这样的话计算量确实很大,假如按你说的“算法上不能更改”的话,就利用多线程改善一下,这个不是三言两语能说清的,建议学习一下多线程相关知识。思路就是程序并发地计算你需要显示出来的这些数据,就好比原来计算的工作是一个人做的,用了多线程之后这个工作分给很多人同时做,分工合作。
5
太阳的位置(高度角、方位角)的算法有低精度和高精度两种,且不管你使用的是哪种(反正你认为是最好的)
既然你是 滑块不能连续快速移动,显然是计算量过大了
那么你可以这么考虑:
当滑块移动时,采用低精度算法(实际是个经验公式)以减少计算时间。数据在连续变化时,观察者对数据的精度是不敏感的,误差大些无碍大局。
停止滑块移动时,再用你的高精度算法矫正一下界面中的数据
使用多线程并不能有什么改善,多线程并不能减少你计算所需的时间
你现在是单线程,滑块拖不动
改用多线程,滑块是拖动了,但画面是一跳一跳的严重滞后
假如你的算法能化作并行计算的话,倒是可以利用一下 .net4 的并行处理机制
不过看你对算法的概略描述,应该是不行的
5
实际上“滑块挪动”跟你的计算一次天文数据,二者到底该怎么样交互协同,这个并不知道,这应该是你本人编程设计的,原因是你本人有算法细节、了解界面需求、可以直观测试各种处理流程的用户体验。
只是告诉你该怎么样起步去学习设计一个良好交互操作体验的程序,不要把交互操作跟简单的数学计算函数扯在一起。正常的滑块的拖动应该是非常顺滑的,原因是 UI 主线程基本上不干什么事儿,每一个UI 操作生命周期都异常短(几毫秒),并不会“卡”上几秒种、几分钟。它跟计算并不是顺序关系,而是并发执行的。
行了吧你
别BB那些没用的了,再拖动事件里加一个延迟执行的方法就行了,
说这么多干P,他能看得懂?
举个例子
在按钮拖动的事件里,
加个if(上次执行时间+500毫秒<当前时间)
然后再执行重绘代码!
当然也有更好的解决方案,本人只是说出了他问题的本质!
5
LZ的界面绘制的好华丽啊,可以发放代码小弟学习下可好?谢谢!
本人现在还没有做完,另外总卡可怎么办呢?
看本人的回复,so easy