故事的开端是这样的,小白是一个程序员,他确实也是一个小白,目前还在程序员发展的道路上,兢兢业业的小心求学. 有一天,小白接到一个任务,完成一个Winform程序,附加一个功能就是可以读IC卡. 小白终于有机会一展身手了!!不免内心兴奋. 再联系了IC卡厂家,拿到开发SDK后,小白不久就碰到了以下难题: 1.厂家的读卡器是通过API给定的事件ReadCard()驱动的,而读卡器在ReadCard事件驱动以后,可以在往后的3s以内侦测是否有IC卡片在附近: (1)3s内,有IC卡在设备附近,立即读卡

C#  winform窗体假死 我们经常会遇到当执行一个比较大的函数时,窗体会出现假死的现象,给用户的体验不是很好,于是我们遇到了问题,那么就必须解决,我们该如何解决呢,首先在自己的脑里画个问号,接下来我们就一起研究吧! 先分析,这个问题是如何出现的呢!为什么会出现,如何避免出现,避免不了的,如何解决等,下面我们就去解决问题吧,遇到问题不要怕,解决问题是我们成长最快的时候,曾经别人告诉我,不怕不会做,就怕想不到.那我们就进入正题吧! 窗体假死是如何出现的呢? 在调用    testc();函数时

http://www.cnblogs.com/Charltsing/p/publisher.html 最近测试task并发任务的效率与线程池的区别,发现了另外一个问题.task建立任务的速度很快,输出到UI的信息过频,导致UI假死. private void TestMakeTasks(object obj) { string msg = ""; //循环创建task for (int i = 0; i < 3000; i++) { //主线程(winform)--子线程(Thr

WinForm窗体在使用过程中如果因为程序等待时间太久而导致窗体本身假死无法控制,会严重影响用户的体验,这种情况大多是UI线程被耗时长的代码操作占用所致,可以新开一个线程用来完成耗时长的操作,然后再将结果返回到UI中呈现,这样就不会占用到UI线程了,也就不会假死了,涉及Control的更新需要用到BeginInvoke方法 private void button1_Click(object sender, EventArgs e) { Thread t1 = new Thread(delegat

用户控件中有一个树,窗体使用了这个控件,但是重命名时执行node.text="XXXX" 执行了很长时间,大约9s,在此期间winform界面假死,尝试过多线程异步委托的方式来操作, 还是假死 再次单步调试,虽然树节点绑定了很多事件,但都是很快就执行完毕的,树是一次加载的,数据量比较大,大约7w个节点,用dot trace跟踪了一下,得到如下结果 -9,309ms System.Windows.Forms.TreeNode.set_Text(String) --9,309ms Syst

用DataGridView无分页绑定一个几千条数据的查询,查询的时候界面直接卡死十几秒,用户体验非常不好,因此用异步操作解决界面卡死的问题原本场景:点击[查询]后,界面直接卡死优化场景:点击[查询]后,界面可以随意移动,感觉不到后台在做大量数据的读取和绑定 private void btnQuery_Click(object sender, EventArgs e) { // 查询按钮点击后,按钮文本由"查询"改为"加载中",并把按钮状态改为不可点击 btnQuer

最近一直在写一个winform程序,对各类文档文件,以及压缩包的内容进行关键字检测. 模型出来之后,执行了一下,发现连续测试后,会有内存不足的问题,导致程序面假死.脑袋懵逼了两天. 回头看我的变量容器List,使用的是静态变量,思路如下: 上图是修改之后的  最初为  : private static List<Inform_Model> Model_List =new List<Inform_Model>(); 但是! static静态全局变量的生命周期是跟随程序结束而GG的:

c#中可以用BeginInvoke去启动异步调用,但是有两个BeginInvoke一个是controller的BeginInvoke还有一个是委托的BeginInvoke. 主要区别是controller的BeginInvoke会返回到主线程中执行.如果在Winform中使用了controller得BeginInvoke去执行一些费时的操作任然会使界面假死. controller的BeginInvoke使用方法是先定义一个委托 如 delegate void UpdateUI(string s)

主线程调用外部web service,没有返回时,主线程阻塞了,界面肯定假死耗时操作都是要在工作线程里面执行的.一般情况下winform调用webservice时步骤1添加服务引用---高级----添加web引用------填写url--添加web引用即可完成对webservice的引用让VS.NET环境来为我们生成服务代理,然后调用对应的Web服务.如果需要动态调用WebService,要实现这样的功能:public static object InvokeWebService(string

原文:C# Winform 窗体界面"假死"后台线程阻塞 解决办法–BeginInvoke 这个方法可以用在任何后台任务耗时较长,造成界面“假死”界面控件不更新的情况. 比如要要执行的数据库操作是几十万条的update语句,如果在click事件里阻塞或者做Thread.Sleep或一个耗时很长的操作,窗口就会无响应点不动了.故需要用this.BeginInvoke方法来异步执行UI线程的操作,更新界面显示. //导入按钮点击事件 private void btn_import_Clic

运行WinForm程序时,如果后台执行比较费时的操作,前天UI就会假死卡住,很影响使用感受,这里我们简单的解决一下这个问题 using System; using System.Collections.Concurrent; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Diagnostics; using System.Drawing; using S

UI卡顿假死问题 误区1:使用不同的线程操作UI控件和耗时操作(即,跨线程操作UI控件CheckForIllegalCrossThreadCalls = false;), 注意:此处只是为了记录...... 原始同步操作如下所示: private void button1_Click(object sender, EventArgs e) { Waintting waitting = new Waintting(); waitting.Show(); Thread.Sleep(5000);//模

转自:http://www.cnblogs.com/smartls/archive/2011/04/08/2008981.html#2457370   引言 在之前的<创建无阻塞的异步调用>中,已经介绍过异步调用的编写步骤和实施原理.异步调用是CLR为开发者提供的一种重要的编程手段,它也是构建高性能.可伸缩应用程序的关键.在多核CPU越来越普及的今天,异步编程允许使用非常少的线程执行很多操作.我们通常使用异步完成许多计算型.IO型的复杂.耗时操作,去取得我们的应用程序运行所需要的一部分数据.在

异步调用是CLR为开发者提供的一种重要的编程手段,它也是构建高性能.可伸缩应用程序的关键.在多核CPU越来越普及的今天,异步编程允许使用非常少的线程执行很多操作.我们通常使用异步完成许多计算型.IO型的复杂.耗时操作,去取得我们的应用程序运行所需要的一部分数据.在取得这些数据后,我们需要将它们绑定在UI中呈现.当数据量偏大时,我们会发现窗体变成了空白面板.此时如果用鼠标点击,窗体标题将会出现”失去响应”的字样,而实际上UI线程仍在工作着,这对用户来说是一种极度糟糕的体验.如果你希望了解其中的原因

转载:http://www.cnblogs.com/smartls/archive/2011/04/08/2008981.html 异步调用是CLR为开发者提供的一种重要的编程手段,它也是构建高性能.可伸缩应用程序的关键.在多核CPU越来越普及的今天,异步编程允许使用非常少的线程执行很多操作.我们通常使用异步完成许多计算型.IO型的复杂.耗时操作,去取得我们的应用程序运行所需要的一部分数据.在取得这些数据后,我们需要将它们绑定在UI中呈现.当数据量偏大时,我们会发现窗体变成了空白面板.此时如果用

1.1 编写目的 为了方便大家以后发现进程假死的时候能够正常的分析并且第一时间保留现场快照. 1.2编写背景 最近服务器发现tomcat的应用会偶尔出现无法访问的情况.经过一段时间的观察最近又发现有台tomcat的应用出现了无法访问情况.简单描述下该台tomcat当时具体的表现:客户端请求没有响应,查看服务器端tomcat的进程是存活的,查看业务日志的时候发现日志停止没有任何最新的访问日志.连tomcat下面的catalina.log也没有任何访问记录,基本断定该台tomcat已不能提供服务.

上周在开发Winform 项目中,我曾遇到一个看似简单,但一直都没有解决的问题,那就是:设置winform DataGridView控件的行DefaultCellStyle,但却没有任何变化,我也曾求助于博问:http://q.cnblogs.com/q/72294/,但大家给的答案没有一个能解决这个问题,可能是问题重现不太容易,我自己也曾多次在其它项目中尝试重现这个问题,但一直都是正确的,没有出现我当前项目的问题,简直要崩溃啊! 先来看看我原有的代码: private void Form1_L

我们都知道WinForm DataGridView控件支持数据绑定,使用方法很简单,只需将DataSource属性指定到相应的数据源即可,但需注意数据源必须支持IListSource类型,这里说的是支持,而不是实现,是因为他既可以是实现了IListSource的类型,也可以是实现了IList的类型,例如:List类型,DataTable类型等,这里就不一一列举了,今天我主要实现的功能如标题所描述的:实现WinForm DataGridView控件支持叠加数据绑定,或者说是附加数据功能,什么意思呢

大部分半卡死的现象是因为Dynamic Tick的一个Bug.Dynamic Tick是NT 6.2内核的一个新功能(其实Linux早就有了),原理的话大概是在空闲的时候把CPU完全暂停,来节省电量.但是貌似这个技术还不是很成熟,对“空闲”的判断有时候会出错,所以正常使用的时候CPU也可能会暂停,出现假死.RP出过一个补丁修复过一次,但是貌似还是没有完全修复. 解决办法就是把它关掉,关掉之后内核的行为就回到Win7的样子了.所以还是会和Win7一样费电,但是应该就不会假死了. 关闭的方法:用管理

问题   前几天,同事遇到一个浏览器假死的问题.就是浏览器在响应一个请求的时候,就突然不响应时间,进入假死状态,Cup也飙升到100%. 但是这个问题只出现在IE浏览器,chrome和Firefox等其他浏览器正常. 原因 Js 代码里面,看着也没有什么耗时的操作和后台异步调用.没办法,只能从响应事件的最开始一步一步调查.经过一番调试之后,问题定位在setTimeout 函数.当把setTimeout 里面执行的函数去掉之后,立马就不会出现这种情况.查看setTimeout 里面调用的函数,发现