RTY 实践出真知

QPixmap QPixmap::grabWindow ( WId window, int x = 0, int y = 0, int width = -1, int height = -1 ) [static]

Creates and returns a pixmap constructed by grabbing the contents of the given window restricted by QRect(x, y, width, height).

The arguments (x, y) specify the offset in the window, whereas (width, height) specify the area to be copied. If width is negative, the function copies everything to the right border of the window. If height is negative, the function copies everything to the bottom of the window.

The window system identifier (WId) can be retrieved using the QWidget::winId() function. The rationale for using a window identifier and not a QWidget, is to enable grabbing of windows that are not part of the application, window system frames, and so on.

The grabWindow() function grabs pixels from the screen, not from the window, i.e. if there is another window partially or entirely over the one you grab, you get pixels from the overlying window, too. The mouse cursor is generally not grabbed.

Note on X11 that if the given window doesn't have the same depth as the root window, and another window partially or entirely obscures the one you grab, you will not get pixels from the overlying window. The contents of the obscured areas in the pixmap will be undefined and uninitialized.

On Windows Vista and above grabbing a layered window, which is created by setting the Qt::WA_TranslucentBackground attribute, will not work. Instead grabbing the desktop widget should work.

Warning: In general, grabbing an area outside the screen is not safe. This depends on the underlying window system.

void QApplication::beep () [static]

Sounds the bell, using the default volume and sound. The function is not available in Qt for Embedded Linux.

写的不错，转一下：

首先呢，声明一下，QString 是不存在中文支持问题的，很多人遇到问题，并不是本身 QString 的问题，而是没有将自己希望的字符串正确赋给QString。

很简单的问题，"我是中文"这样写的时候，它是传统的 char 类型的窄字符串，我们需要的只不过是通过某种方式告诉QString 这四个汉字采用的那种编码。而问题一般都出在很多用户对自己当前的编码没太多概念，

于是

一个简 单的 Qt 程序

下面这个小程序，估计大家会感到比较亲切。似乎有相当多的中文用户尝试写过这样的代码：

#include <QtGui/QApplication>
#include <QtGui/QLabel>

int main(int argc, char **argv)
{
 QApplication app(argc, argv);
 QString a= "我是汉字";
 QLabel label(a);
 label.show();
 return app.exec();
}

编码，保存，编译，运行，一切都很顺利，可是结果呢？

多数用户看到	其他用户看到
ÎÒÊǺº×Ö	æˆ‘æ˜¯æ±‰å —

出乎意料，界面上中文没显示出来，出现了不认识字符。 于是开始用搜索引擎搜索，开始上论坛发帖或抱怨

最后被告知，下面的语句之一可以解决问题：

QTextCodec::setCodecForCStrings(QTextCodec::codecForName("GB2312"));
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8"));

两条指令挨个一试，确实可以解决(多数用户是第一条，其他用户是第二条)。那么，为什么会这样呢？

两种乱码什么时候出现

对这个问题，我想大家可能都有话说。在继续之前，我们先列个表，看看两种乱码分别在那种情况下出现：

我们只列举大家最常用的3个编译器(微软VS的中的cl，Mingw中的g++，Linux下的g++)，源代码分别采用 GBK 和 不带BOM的UTF-8  以及 带BOM的UTF-8 这3中编码进行保存。

源代码的编码	编译器	结果
GBK	cl	1	*
	mingw-g++	1	*
	g++	1
UTF-8(不带BOM)	cl	2
	mingw-g++	2
	g++	2	*
UTF-8(带BOM)	cl	1
	mingw-g++	2
	g++	编译失败

采用3种不同编码保存的源代码文件，分别用3种不同的编译器编译，形成9种组合，除掉一种不能工作的情况，两种乱码出现的情况各占一半。

从中我们也可以看出，乱码和操作系统原本是没有关系的。但我们在 Windows 一般用的GBK，linux一般用的是不带BOM的UTF-8。如果我们只考虑带*的情况，也可以说两种乱码和系统有关。

QString 为什么会乱码呢？

真的是 QString 乱码了吗？我们可以问问自己，我们抱怨的对象是不是搞错了？

继续之前，先明确几个概念：

明确概念1：

"我是汉字" 是C语言中的字符串，它是char型的窄字符串。上面的例子可写为

const char * str = "我是汉字";
QString a= str;

或

char str[] = "我是汉字";
QString a= str;

等

明确概念2：

源文件是有编码的，但是这种纯文本文件却不会记录自己采用的编码

这个是问题的根源，不妨做个试验，将前面的源代码保存成GBK编码，用16进制编辑器能看到引号内是ce d2 ca c7 ba ba d7 d6这样8个字节。

现在将该文件拷贝到正体(繁体)中文的Windows中，用记事本打开会什么样子呢？

...
 QString a= "扂岆犖趼";
 QLabel label(a);
 label.show();
...

那么放到欧美人的Windows系统中，再用记事本打开呢？

...
 QString a= "ÎÒÊǺº×Ö";
 QLabel label(a);
 label.show();
...

同一个文件，未做任何修改，但其中的8个字节ce d2 ca c7 ba ba d7 d6,对用GBK的大陆人，用BIG5的港澳台同胞，以及用Latin-1的欧洲人看来，看到的却是完全不同的文字。

明确概念3：

如同我们都了解的'A'与'\x41'等价一样。

GBK编码下的

const char * str = "我是汉字"

等价于

const char * str = "\xce\xd2\xca\xc7\xba\xba\xd7\xd6";

当用UTF-8编码时，等价于

const char * str = "\xe6\x88\x91\xe6\x98\xaf\xe6\xb1\x89\xe5\xad\x97";

注意：这个说法不全对，比如保存成带BOM的UTF-8，用cl编译器时，汉字本身是UTF-8编码，但程序内保存时却是对应的GBK编码。

明确概念4：

QString 内部采用的是Unicode。

QString内部采用的是 Unicode，它可以同时存放GBK中的字符"我是汉字",BIG5中的字符"扂岆犖趼" 以及Latin-1中的字符"ÎÒÊǺº×Ö"。

一个问题是，源代码中的这8个字节"\xce\xd2\xca\xc7\xba\xba\xd7\xd6"，该怎么转换成Unicode并存到 QString 内？按照GBK、BIG5、Latin-1还是其他方式...

在你不告诉它的情况下，它默认选择了Latin-1，于是8个字符"ÎÒÊǺº×Ö"的unicode码被存进了QString中。最终，8个Latin字符出现在你期盼看到4中文字符的地方，所谓的乱码出现了

QString 工作方式

const char * str = "我是汉字";
QString a= str;

其实很简单的一个问题，当你需要从窄字符串 char* 转成Unicode的QString字符串的，你需要告诉QString你的这串char* 中究竟是什么编码？GBK、BIG5、Latin-1

理想情况就是：将char* 传给QString时，同时告诉QString自己的编码是什么：

就像下面的函数一样，QString的成员函数知道按照何种编码来处理 C 字符串

QString QString::fromAscii ( const char * str, int size = -1 )
QString QString::fromLatin1 ( const char * str, int size = -1 ) 
QString QString::fromLocal8Bit ( const char * str, int size = -1 )
QString QString::fromUtf8 ( const char * str, int size = -1 )

单QString 只提供了这几个成员函数，远远满足不了大家的需求，比如，在简体中文Windows下，local8Bit是GBK，可是有一个char串是 BIG5 或 Latin-2怎么办？

那就动用强大的QTextCodec吧，首先QTextCodec肯定知道自己所负责的编码的，然后你把一个char串送给它，它就能正确将其转成Unicode了。

QString QTextCodec::toUnicode ( const char * chars ) const

可是这个调用太麻烦了，我就想直接

QString a= str;

或

QString a(str);

这样用怎么办？

这样一来肯定没办法同时告诉 QString 你的str是何种编码了，只能通过其他方式了。这也就是开头提到的

QTextCodec::setCodecForCStrings(QTextCodec::codecForName("GBK"));
QTextCodec::setCodecForCStrings(QTextCodec::codecForName("UTF-8"));

设置QString默认采用的编码。而究竟采用哪一个，一般来说就是源代码是GBK，就用GBK，源代码是UTF-8就用UTF-8。但有一个例外，如果你保存成了带BOM的UTF-8而且用的微软的cl编译器，此时仍是GBK。

在使用C++编程的过程中，常常需要对类成员进行初始化，通常的方法有两种：

第一种方法：

CMYClass::CSomeClass()
{
    x=0;
    y=1;
}

第二种方法：

CSomeClass::CSomeClass() : x(0), y(1)
{
}

本文将要探讨这两种方法的异同以及如何使用这两种方法。

    从技术上说，第二种方法比较好，但是在大多数情况下，两者实际上没有什么区别。第二种语法被称为成员初始化列表，之所以要使用这种语法有两个原因：一个原因是必须这么做，另一个原因是出于效率考虑。

    让我们先看一下第一个原因——必要性。设想你有一个类成员，它本身是一个类或者结构，而且只有一个带一个参数的构造函数。

class CMyClass {
    CMember m_member;
public:
    CMyClass();
};

// 必须使用初始化列表来初始化成员 m_memberCMyClass::CMyClass() : m_member(2){•••}

    使用初始化列表的第二个原因是出于效率考虑，当成员类具有一个缺省的构造函数和一个赋值操作符时。MFC的CString提供了一个完美的例子。假定你有一个类CMyClass具有一个CString类型的成员m_str，你想把它初始化为"Hi,how are you."。你有两种选择：

CMyClass::CMyClass() {// 使用赋值操作符// CString::operator=(LPCTSTR);m_str = _T("Hi,how are you.");}

// 使用初始化列表// 和构造函数 CString::CString(LPCTSTR)CMyClass::CMyClass() : m_str(_T("Hi,how are you.")){}

    在CString的例子里这是无所谓的，因为缺省构造函数是内联的，CString只是在需要时为字符串分配内存（即，当你实际赋值时）。但是，一般而言，重复的函数调用是浪费资源的，尤其是当构造函数和赋值操作符分配内存的时候。在一些大的类里面，你可能拥有一个构造函数和一个赋值操作符都要调用同一个负责分配大量内存空间的Init函数。在这种情况下，你必须使用初始化列表，以避免不要的分配两次内存。

x=y=z=0;

memset(this,0,sizeof(this));

    当我考虑初始化列表的问题时，有一个奇怪的特性我应该警告你，它是关于C++初始化类成员的，它们是按照声明的顺序初始化的，而不是按照出现在初始化列表中的顺序。

class CMyClass {    CMyClass(int x, int y);    int m_x;    int m_y;};CMyClass::CMyClass(int i) : m_y(i), m_x(m_y){}

class CMember {
public:
    CMember(int x) { ... }
};

因为CMember有一个显式声明的构造函数，编译器不产生一个缺省构造函数（不带参数），所以没有一个整数就无法创建CMember的一个实例。

CMember* pm = new CMember;        // 出错!!
CMember* pm = new CMember(2);     // OK

    如果CMember是另一个类的成员，你怎样初始化它呢？答案是你必须使用成员初始化列表。