MiGL Tech.

苟利国家生死以，岂因祸福避趋之~

开始写BLOG

2009年05月11日

选定下拉列表中的指定项目 + Date对象的一些特别注意

select.selectedIndex 来指定下拉列表中的选定项目

Date()对象一定要new 后再使用

getMonth()的一月 = 1

getDay()得到的是Weekday，星期一 = 1

getDate()得到的才是日阅读全文>

发表于 @ 2009年05月11日 23:21:00|评论(loading...)|举报|收藏

2009年05月07日

DropDownList的SelectedItem使用注意

如果DropDownList放在UpdatePanel中，那么在取值的时候使用DropDownList.SelectedItem就会是Null，会出异常，所以不要这么用。阅读全文>

发表于 @ 2009年05月07日 22:27:00|评论(loading...)|举报|收藏

2009年04月03日

比较软连接和硬连接

目录项中包含文件名和一个指向i节点的指针。
软链接i节点指针指向目录项，
硬链接i节点指针指向i节点.
如果软链接到一个文件，你删除这个软链接不会影响原文件。
如果硬链接到一个文件，你删除这个硬链接，原来的文件所指向的inode中的链接计数器就会减1。减到0时就删除这个inode.阅读全文>

发表于 @ 2009年04月03日 12:44:00|评论(loading...)|举报|收藏

2009年04月01日

JavaScript 中的 parseInt

parseInt(string)

如果 string 以 0 开头，按照 8 进制转换
如果 string 以 0x 开头，按照 16 进制转换
不然，按照 10 进制转换

parseInt(string, radix)

radix 是强制指定进制的转换阅读全文>

发表于 @ 2009年04月01日 10:08:00|评论(loading...)|举报|收藏

2008年12月14日

IPLE 开发笔记 7 -- 中国病人

12月14日

很久没有写开发笔记，因为前段时间一直在忙找工作，工作找到了，还是非常满意的，但是这个经历给我带来了更多深入的思考。

我不喜欢做自己不喜欢的，尤其是在技术上，俗话说：“术业有专攻”，然而我也并不是用这句话来掩饰我的无知，我始终认为，一个完善的系统需要多方面考虑和分析问题，而这多方面就是需要“博”，然而这种博不是泛泛的了解，而是在每个可能涉及的领域都有过深入研究的经验，听起来好像很荒谬，但是没有这些积淀，什么都搞不成，这是一定的！

最近的IPLE一直搁置，是因为我要解决一个问题，即抛弃Windows的内存映射文件对象，为IPLE重新量身定做一个内存映射文件机制。

好像就是一个问题，不过并不尽然，一个完善的设计需要诸多方面深入的考虑，眼下分析的就有如下问题需要亟待解决：
1、进程、线程同步
2、缓存设计
3、可能引发的异常及处理方法
没有考虑到的问题可能很多，需要进一步的思考和分析。

我非常渴望知道一切事物的阅读全文>

发表于 @ 2008年12月14日 15:31:00|评论(loading...)|举报|收藏

2008年10月25日

Vista 下 AnimateWindow 的问题

AnimateWindow函数是标准的Win32 API 函数，Win98 以上操作系统都可借助他来实现动感的窗口切换操作，在Vista下虽然也能实现，但是有一点让笔者不爽，那就是窗口阴影并不受AnimateWindow控制，实验表明，当淡出时阴影会先于淡出操作消失，很容易被肉眼识别，影响整体效果，所以Vista 下不建议使用 AnimateWindow。阅读全文>

发表于 @ 2008年10月25日 22:06:00|评论(loading...)|举报|收藏

2008年10月24日

IPLE 开发笔记 6 -- Debug 日志加入

10 月 24 日
Debug日志记录功能引入了IPLE，因为我喜欢采用防守式编程，任何地方都可能出现错误，看上去虽然非常保守，但是软件的稳定性确实要第一考虑！！
而且，在程序中处理可能出错的情况，可以一定程度上减轻后面的测试工作。其他的不多说，现在整个系统还是处于接口的定义状态，也就是只写函数，不写函数实现，然后主程序直接调用这些函数，逻辑上检查无误了，再去写函数实现，面向接口编程就是这么个道理，这在一定程度上确实提升了开发效率，后面的代码实现要依托系统定义的一系列约定，只是体力活了，留在后面做吧，o(∩_∩)o...阅读全文>

发表于 @ 2008年10月24日 11:43:00|评论(loading...)|举报|收藏

2008年10月20日

IPLE 开发笔记 5 -- 关于巨型的一些新问题

10 月 20 日昨晚看了一部电影《通缉令》，里面有这么一句话：“子弹会走直线是因为你一开始就认为它是走直线的，现在你需要改变你的想法。”这句话给了我很大的启发，关于解决海量数据，我们需要更多的创新，因为一种狭义上的最优方法放到广义上也许就可能一点都不适用了。有限制的软件用起来是不爽的，所以我们要不断追求卓越~新一套的API就快完成了，但是就在这个时候还是面临着下面几个难题：1、巨型图像的频率域处理问题这个最难弄，因为即使使用了快速傅里叶变换，对于大一点的图来说速度也是不太理想，以前使用的都是基2的方法，打算在后面试试基4的方法，实在不行再试试基8的，但是这又有一个问题，虽然基4的速度上确实快一些，但是在一些图像如511*23这样长宽非2的整数次幂的情况，要开辟的临时存储空间也是原来的很多倍，这样就很恼火了。2、巨型图像处理的撤销问题我的方法是产生临时文件，撤销的话就是回滚到某一个临时文件，但是图像一大临时文件也就大了，如果用户的硬盘空间不富裕，那就难办了，可能要压缩，但是压缩算法又很难确阅读全文>

发表于 @ 2008年10月20日 12:49:00|评论(loading...)|举报|收藏