在個人理解中,QT和Android都是相似的開發框架,都是由開發團隊封裝了各式各樣的接口和數據結構.將一些問題的解決方法簡單化
好比QT中將線程封裝爲QThread,派生類經過重寫run方法來將代碼投入到新的線程執行,而一樣的Android中的線程是Java自帶的Thread類,一樣是重寫run方法來執行線程代碼.
因而可知,一些問題的解決方法是存在共性的.java
在程序中引進信號/槽機制,須要元數據 也就是並不是任意的類都能添加信號/槽功能數據結構
這樣會在connect時出錯 提示找不到匹配的connect
class
sender {
signals:
void
sigSend(
int
*msg);
};
正確的作法是
class
sender :
public
QThread{
Q_OBJECT
signals:
void
sigSend(
int
*msg);
};
|
繼承任意元數據的派生類均可以框架
調用流程一般是:ide
1
2
3
4
5
|
實現信號函數
void
sigSend(
int
*msg);
在某個方法內調用信號 emit sigSend(&a);
實現槽函數
void
slotRecv(
int
*msg);
建立對象後 鏈接信號與槽 connect(sender, SIGNAL(sigSend(
int
*)), recver, SLOT(slotRecv(
int
*)));
在某個地方調用包含觸發信號的方法
|
QMetaObject包含了QObject的所謂的元數據,也就是QObject信息的一些描述信息:除了類型信息外,還包含QT中特有的signal&slot信息。函數
virtual QObject::metaObject();
該方法返回一個QObject對應的metaObject對象,如上文所說,若是一個類的聲明中包含了Q_OBJECT宏,編譯器會生成代碼來實現這個類對應的QMetaObject類,並重載QObject::metaObject()方法來返回這個QMetaObject類的實例引用。這樣當經過QObject類型的引用調用metaObejct方法時,返回的是這個引用的所指的真實對象的metaobject。spa
若是一個類從QObject派生,確沒有聲明Q_OBJECT宏,那麼這個類的metaobject對象不會被生成,這樣這個類所聲明的signal slot都不能使用,而這個類實例調用metaObject()返回的就是其父類的metaobject對象,這樣致使的後果就是你從這個類實例得到的元數據其實都是父類的數據,這顯然給你的代碼埋下隱患。所以若是一個類從QOBject派生,它都應該聲明Q_OBJECT宏,無論這個類有沒有定義signal&slot和Property。線程
這樣每一個QObject類都有一個對應的QMetaObject類,造成一個平行的類型層次。code
The Q_OBJECT macro at the beginning of the class definition is necessary for all classes that define signals or slots 只有加入了Q_OBJECT,你才能使用QT中的signal和slot機制。 好比編寫事件接口等程序時,有時會出現以下問題: 在PC端成功編譯,但在開發板端卻顯示錯誤: QObject::connect: No such slot QWidget::*******() QObject::connect: (sender name: 'unnamed') QObject::connect: (receiver name: 'unnamed') 這時候,就必須在頭文件派生類的時候,首先像下面那樣引入Q_OBJECT宏: class MyMainWindow : public QWidget { Q_OBJECT ...... } QT中的moc? moc是QT的預編譯器,用來處理代碼中的slot,signal,emit,Q_OBJECT等。 moc文件是對應的處理代碼,也就是Q_OBJECT宏的實現部分,在官方文檔上有詳細說明,與其文件在同一目錄下。今天項目不能編譯過去,最後和沒改動的解決方案比較了下發現原來是把Generated MOC Files裏面少了兩個moc**_xxx.cpp文件!!