算了算, 来昆明一共也才三天而已
可是总是觉得已经来了很久了, 想回去的欲望也越来越强烈
好在今天终于解决了问题, 也订了明晚回北京的机票
来昆明后, 用了一天就实现了用户提出的需求
剩下的时间却一直纠缠于一个十分诡异的问题
我们的客户端软件要在IE浏览器上安装一个插件(BHO插件)
但是在安装以后, 却导致用户使用了多年的一个用于打印的OCX控件出现异常
而且异常发生的条件一直不清楚
直到今天下午, 我找开发人员要到了打印模块的代码和那个OCX控件的安装文件
又在我的电脑上反复调试了两个小时, 才把错误重现出来
并且找到了其中的规律
规律十分复杂, 总结出来是以下几点:
1. 如果不安装我们的BHO插件, 则绝对不会出错
2. 安装了BHO插件后, 直接进行打印, 也不会出错
3. 安装了BHO插件后, 启动两个IE窗口, 并在第二个窗口中调用打印OCX控件进行打印, 也不会出错
4. 关掉第二个窗口, 再次打开这个窗口, 进行打印, 然后异常, 并且再也无法正常打印
说实话, 从来没碰到过这么曲折的异常重现方式
不过摸清了规律, 问题就解决了一半了
先是尝试在打开的页面中寻找那个OCX控件, 一旦找到则将BHO插件注销
但是没有解决问题, 估计在加载中就已经出错了
然后又尝试在加载页面之前就去判断加载的是否打印页面
如是的话, 就注销BHO插件
问题解决!
2008年5月24日星期六
2005年9月29日星期四
一个Idea - AutoLog
想起来一个关于工作日志的问题. 写日志是一个比较难的抉择, 如果是写项目日志, 那就比较简单, 只要记录每天做了多少关于这个项目的工作就可以了. 但是如果想记录一天做过的所有事情(上网看新闻聊天就算了)就比较麻烦. 很多事情是没有什么体系的, 比如说去了解某项新的技术, Google一个问题的解决办法, 整理一些资料, review一些代码, 等等. 这些事情常常会做, 需要花费不短的时间, 可是却很难把它们组织起来, 在日志里面说自己做了某某事情. 所以我想, 是不是可以做一个程序, 自动记录自己一天来做过的所有事情(当然是在电脑上面做的事情, 如果是吃饭睡觉抽烟打屁这类的, 可能交给秘书来记录比较现实).
我先给这个软件起名叫AutoLog好了, 至少在哪天会灵机一动想出更酷的名字之前. 这个程序可以常驻内存, 放在System Tray里面, 它可以自动记录用户在电脑上做的每一件事. 因为我们工作时会打开很多个窗口, 但是每一刻总是有一个窗口处于激活状态, 那这个程序就可以记录下每一个窗口处于激活状态的时间段. 例如VC, Word, IE, MSN, 等等....再根据这些程序的标题栏, 我们就可以大致了解具体是在做什么内容的工作, 比如在做哪个工程/文件的编写, 在和某人聊天, 在Google关于什么的资料. 可以将这些资料保存起来, 按照时间或工作内容进行组织, 就可以大体描绘出自己一天来做的工作了. 如果还可以检测键盘和鼠标的动作, 感知无用户动作的时间, 还可以记录用户的发呆时间^_^
初步想了一下, 会用到的技术包括对Windows窗口的枚举, 激活和隐藏, 关闭等消息的捕获, 系统空闲的感知和记录. 数据组织方式和存储方式是一个需要研究的问题, 而从大量数据中选择合适的规则进行挖掘也是一个需要仔细考虑的方面.
想了这么多, 不知道这个想法是不是早就有人想到了, 并且已经作出完整的实现, 有空的时候我得找找看, 嘻嘻.
我先给这个软件起名叫AutoLog好了, 至少在哪天会灵机一动想出更酷的名字之前. 这个程序可以常驻内存, 放在System Tray里面, 它可以自动记录用户在电脑上做的每一件事. 因为我们工作时会打开很多个窗口, 但是每一刻总是有一个窗口处于激活状态, 那这个程序就可以记录下每一个窗口处于激活状态的时间段. 例如VC, Word, IE, MSN, 等等....再根据这些程序的标题栏, 我们就可以大致了解具体是在做什么内容的工作, 比如在做哪个工程/文件的编写, 在和某人聊天, 在Google关于什么的资料. 可以将这些资料保存起来, 按照时间或工作内容进行组织, 就可以大体描绘出自己一天来做的工作了. 如果还可以检测键盘和鼠标的动作, 感知无用户动作的时间, 还可以记录用户的发呆时间^_^
初步想了一下, 会用到的技术包括对Windows窗口的枚举, 激活和隐藏, 关闭等消息的捕获, 系统空闲的感知和记录. 数据组织方式和存储方式是一个需要研究的问题, 而从大量数据中选择合适的规则进行挖掘也是一个需要仔细考虑的方面.
想了这么多, 不知道这个想法是不是早就有人想到了, 并且已经作出完整的实现, 有空的时候我得找找看, 嘻嘻.
标签:
Development,
Work
使用Unicode开发所有的应用程序
在做过繁体中文的应用程序后,终于受够了面对程序界面上的一大堆乱码,调试时在不同内码的平台上来回切换,不时的打开南极星进行内码转换和big5字符输入. 前两天看到了上面作者无情抨击那些不懂Unicode为何物并且自认为只有在自己的系统中显示正确就可以的程序员的文章. 终于下定决心, 告诉自己, 今后除非客户明确提出, 否则一定要使自己的程序支持Unicode.
其实这样做的好处真的很多, 首先在编写非简体中文平台的程序会变得比较简单, 因为无论在何种语言的OS中表现都是一样的, 不需要去转码, 也不需要把build好的程序拿到其他语言的平台上去测试; 其次, 在做web开发时, 不用去操心在不同内码间转换错误造成的显示不正常. 因为Java和ASP.NET都是支持unicode的, 如果要处理多字节字符, 反而需要进行转换, 麻烦; 再次, 现在无论是COM开发还是中间件开发, 默认支持的字符都是unicode, 更不用说Visual Basic根本就是unicode的. 硬让这些程序去处理多字节字符, 简直是一种倒退!!
不好的地方嘛, 也有. 在Windows 98和NT上面想要做Unicode简直是Mission Impossible, 虽说不是真的不可能, 不过还是不试的好.
其实这样做的好处真的很多, 首先在编写非简体中文平台的程序会变得比较简单, 因为无论在何种语言的OS中表现都是一样的, 不需要去转码, 也不需要把build好的程序拿到其他语言的平台上去测试; 其次, 在做web开发时, 不用去操心在不同内码间转换错误造成的显示不正常. 因为Java和ASP.NET都是支持unicode的, 如果要处理多字节字符, 反而需要进行转换, 麻烦; 再次, 现在无论是COM开发还是中间件开发, 默认支持的字符都是unicode, 更不用说Visual Basic根本就是unicode的. 硬让这些程序去处理多字节字符, 简直是一种倒退!!
不好的地方嘛, 也有. 在Windows 98和NT上面想要做Unicode简直是Mission Impossible, 虽说不是真的不可能, 不过还是不试的好.
标签:
Development
订阅:
博文 (Atom)