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是另一個類的成員，你怎樣初始化它呢？答案是你必須使用成員初始化列表。