分类目录归档:Windows编程

VC里Tab控件页面的子窗体确定尺寸

果然问题就是在英语不好。msdn虽然有说但是看得实在是……

.net倒是很方便,直接控件拖拖拖,这个都给你实现了的。

但是sdk或者mfc里就比较麻烦。Tab控件上面的页面如果切换了,不是里面的内容要跟着变吗?但是tab控件不管里面的内容变,它只管发一个通知给你。怎么变你自己实现。于是最方便的方法就是弄很多子窗口,在切换的时候更换子窗口。

其实就是你先GetClientRect一下拿到它整个的矩形区域,然后TabCtrl_AdjustRect把这“整个”转换成“里面”。之后你去创建子窗口就可以了。

那个TabCtrl_AdjustRect说真的确实是早就看到了,但是它的说明看得半懂不懂。

VC编写的本地代码程序使用XP Style

只是避免在鱼龙混杂的网络上找到莫名其妙不可靠资料的担忧

msdn上有,不过临时去翻msdn挺麻烦的,因为没记住在哪个分类里面的话(汗

分类在Windows Desktop App Development——Windows Application UI Development——Windows Controls——Visual Styles——Enabling Visual Styles

然后若遇上网络很慢,要人命

继续阅读VC编写的本地代码程序使用XP Style

用Win32++库编写图形界面

最近一直在找C++编写图形界面的库。用C#确实方便,拖拖控件就出来了。但是对.net Framework运行库的依赖有的时候是略烦人的。于是想掌握不需要这个就能写图形界面的方法。用Windows API编写图形界面不是说不会,就是麻烦,忒麻烦(擦汗

关于现成的各种库,用过Ultimate++、FLTK等。Ultimate++在MinGW下表现不错,看起来也很native虽然是自己画的。但是换VC就半死不活了:英文下没问题,中文的话,哼哼……它源代码是保存成UTF8格式的,里面字符串全都是raw UTF8,就等着VC报错吧 -_,- FLTK的话,win95你一脸。为了静态链接,还用了好多手段好不容易调成静态链接。看着那个界面,最终还是放弃了……而且它的fluid界面设计器生成的代码,里面的字符串遇到中文的全部给你艹成斜杠加八进制数,略烦。VCF没有接触更多,没找到它的图形界面设计器,暂时还是算了……

WTL我也尝试过,用起来怎么说呢……反正也就那德行-_,- 关键是文档,WTL的文档很烂,很多都找不来,得去看代码。对于我等没文档写不了代码的人来说……Oh my god。WxWidgets的设计哲学跟我各种不符,在Code::Block里面试了一下,虽然是有设计器,但是那个设计器不知道为什么,说不出的别扭,拖了两下,运行程序,控件乱成屎了(满脸血)。

其实为什么尝试的里面没看到很著名的那些库呢?其实相关的考虑,一个是LGPL协议:QT库遵循LGPL协议,不买不给你静态链接;GTK就干脆连买的机会也木有的样子?MFC主要还是收费吧,不像是我等现在可以买得起来自己玩的,虽然给公司做的话是完全没问题……Borland那个C++ Builder的库同理。 继续阅读用Win32++库编写图形界面

用C语言写被导入EXE的代码片段

 

用过CFF Explorer之后,发现它可以给EXE添加Seciton,甚至还可以直接导入一个文件作为EXE中一个Section,功能好赞。配合OllyDBG来对现有软件的EXE做一些小小的hack感觉效果很好。

最早的时候我是直接用OllyDBG打开EXE,然后找到一片都是0的地方来汇编代码进去。但是这样受到的限制很多,最直接的就比如有的时候找不到一堆0的地方,找到也不确定能不能写:有可能这些部分其他地方要用,又或者汇编了代码进去要保存的时候OllyDBG说存不了。现在可以直接自己添加一个Section,不会出现找不到空间的情况了。

既然可以导入文件,那比起直接在OllyDBG里面敲汇编,用Nasm来写汇编代码要方便得很多。在测试导入Nasm写的汇编以后,我就在捉摸着更加方便的事情:用C语言来写。

我选用的是OpenWatcom C编译器,没什么太多理由,正好抓到它而已。它反正也可以生成Raw二进制格式的文件。

研究了一下它的链接器,最终的结果是用这样的参数:

OPTION OFFSET=xxxxxx FORMAT RAW BIN

或者

OUTPUT RAW OFFSET=xxxxxx

一起用就会出一些奇怪的结果。说明文档非常长,不知道是不是哪里漏掉了什么没看到的部分……

一起用的时候有的时候就出现最前面16个字节全部是0,然后后面的代码全部错位,大汗……

继续阅读用C语言写被导入EXE的代码片段

使用VS2012编译XP上运行的程序

在微软发布了那个升级包之后,编译器toolset里面有了一个Visual Studio 2012 – Windows XP可以选。但是本人使用测试之后,发现旧的工程选了这个toolset以后,编译出来的程序仍然无法在XP上运行。

今天在某个QQ群聊天的时候,SAPikachu大大提到了这个问题,于是我就说我自己试的时候,失败了,编译出来的东西XP不能跑。不过对方测试之后发现,他那边可以。这里面一定有什么设置不对……

对比了以后,发现除了cl.exe编译命令行那边多了一个_USING_V110_SDK71_的宏定义以外,link.exe那边也多了个/SUBSYSTEM:CONSOLE",5.01"参数。但是很奇怪的是,我这里没有。

经过对方提醒,工具集选了v110_xp以后,这个参数是自动加上的才对。我检查了链接器设置那边,发现确实最低版本写了个5.01,但是上面子系统没有填,结果最后的命令行里面没有这个参数。

最后我把子系统那边选了个Console以后这参数就加上去了。虽然还没真正测试过,不过目测这下编译出来的东西可以在windows xp上运行了。

p.s. xp还真是长命w

Jubeat Analyzer(mciSendString)对待MP3奇怪的行为

作为一个Jubeat玩家,并且还想过那些比较难的曲子,怎么样也会听说过Jubeat Analyzer吧。这个工具可以把街机上那些谱面在电脑上重现出来,这样就可以先看清楚它是怎么回事,然后再去玩,增加过关的概率。

这软件读取的谱面格式是TXT,音乐是MP3。看它的readme,里面有提到谱面的TXT的格式。里面有写曲子的速度(每分钟多少拍),从什么地方开始是第一拍,之类的。

它自带两个曲子,我当时研究了一下那个twilight goose,发现里面写的曲子第一拍开始的时间是1747毫秒。但是实际上我把MP3丢到Audacity里面打开,仔细观察,第一拍在1.5秒左右就开始了。 继续阅读Jubeat Analyzer(mciSendString)对待MP3奇怪的行为

搞死人的管道HANDLE,搞死人的继承

测试昨天的代码的时候,又遇到了问题。把整个处理流程又加长之后,其中有一个进程的输入和输出都被重定向了。因为昨天测试的时候都是中途强行停止,现在想要正常停止,自然就是把连接自己和子进程StdInput的管道HANDLE关闭,结束送数据。但是我关掉管道输入端的HANDLE以后,子进程却还在傻傻等待数据,也不退出。 继续阅读搞死人的管道HANDLE,搞死人的继承

使用Windows的匿名管道和Boost.Iostreams

因为Boost.Iostreams提供了封装Windows的Handle的支持,利用这个可以简化匿名管道的操作。我想要达到的目标,先实现这样一个简单的命令行:

ffmpeg -i c:\1.mp3 -acodec pcm_s16le -ac 2 -ar 44100 -f s16le - | oggenc2 -o c:\1.ogg -q 1 -B 16 -C 2 -R 44100 -

功能很简单,就是把一个mp3文件转换成ogg文件而已。然而要达到这个目的,耗了不少精力…… 继续阅读使用Windows的匿名管道和Boost.Iostreams