那36字节的内存泄漏似乎是在Boost里的，昨天从CodeProject上下了一个跟踪内存分配情况的代码，放在工程里用了一下，看到走到Boost.system里去了。这让我觉得有点泄气，对Boost对崇敬的心情啊！不过想想，这36字节一直存在于整个进程的始末，也许它像个普通的singleton一样是不需要释放的呢，而且说不定release就没问题了呢。
MS SQL Server居然不支持双引号，晕，Access就好好的。气死人了。
问题太多了，改来改去整出一堆一堆的问题。下午的时候都烦死了，于是在那里抱怨，当初决定用Excel来作为流程文件格式，根本就是一个错误的决策。因为用户在用Excel编辑的时候，我的程序是跟踪不到各种变化的，最大限度的只能了解到变化前后的状态。今天又偶然发现另一个让人头疼的问题。本来那图形通过Excel的自动化接口直接Copy到系统剪贴板中，然后再从剪贴板中取出存成一个图片文件。但在Copy时有一问题是，它并不从Sheet左上角（0,0）位置开始，而是从所有Shape的最大边界值开始，而我关心的只是Rectangle、Ellipse等几个图形，对于Line等都是直接丢弃掉的。另一方面，Copy图形时，是会把所有Shape都选进去的，这样当有line是在rectangle之类的最大边界以外时，就不能再计算出定义精确的位置偏移了。为了这个问题，跟同事讨论了好一会儿，也没有人根本性的从技术上解决的方案，最后我灵机一动，说不如我们定个模板，该模板固定在左上角（0,0）处开始有个Shape，放个logo上去，用户的流程文件只能从该文件修改而来，这样就保证能获取不用计算偏移的图片了。说改就改，我都为我的灵机一动感到犹如神来之笔啊，哈哈！
还有很多易用性的问题，确实，最早的时候自己也觉得易用性太差，后来根据同事意见，作了一定的修改，易用性有了一定的提高，今天得到一些意见，果然易用性还是太差，嗯，写程序的人确实很难去理解最终用户的使用习惯，这是一大弊端啊，要改要改！
这样弄得心好烦啊！两年计划真的能好好实施下去吗？我不知道，我太懒了，所以我不敢拍胸脯。
支付宝扫一扫
微信扫一扫