簡 述: Qt4 和 Qt5 的信號和槽的連接 connect 與斷開 disconnect 區別
所謂 GUI 界面,歸根結底,就是一堆組件的疊加。我們創建一個窗口,把按鈕放上面,把圖標放上面,這樣就成了一個界面。在放置時,組件的位置尤其重要。我們必須要指定組件放在哪里,以便窗口能夠按照我們需要的方式進行渲染。這就涉及到組件定位的機制。Qt 提供了兩種組件定位機制:絕對定位和布局定位。
顧名思義,絕對定位就是一種最原始的定位方法:給出這個組件的坐標和長寬值。這樣,Qt 就知道該把組件放在哪里以及如何設置組件的大小。但是這樣做帶來的一個問題是,如果用戶改變了窗口大小,比如點擊最大化按鈕或者使用鼠標拖動窗口邊緣,采用絕對定位的組件是不會有任何響應的。這也很自然,因為你并沒有告訴 Qt,在窗口變化時,組件是否要更新自己以及如何更新。如果你需要讓組件自動更新——這是很常見的需求,比如在最大化時,Word 總會把稿紙區放大,把工具欄拉長——就要自己編寫相應的函數來響應這些變化。或者,還有更簡單的方法:禁止用戶改變窗口大小。但這總不是長遠之計。
針對這種變化的需求,Qt 提供了另外的一種機制——布局——來解決這個問題。你只要把組件放入某一種布局,布局由專門的布局管理器進行管理。當需要調整大小或者位置的時候,Qt 使用對應的布局管理器進行調整。
信號和槽的 connect
Qt4 方式: 宏
1
2
3
|
//Qt4: 宏 /*式1*/ static QMetaObject::Connection connect( const QObject *sender, const char * signal , const QObject *receiver, const char *method, Qt::ConnectionType type = Qt::AutoConnection) /*式2*/ QMetaObject::Connection connect( const QObject *sender, const char * signal , const char *method, Qt::ConnectionType type = Qt::AutoConnection) const |
Qt5 方式: 函數指針
1
2
3
4
|
// Qt5: 函數指針 /*式3*/ static QMetaObject::Connection connect( const QObject *sender, PointerToMemberFunction signal , const QObject *receiver, PointerToMemberFunction method, Qt::ConnectionType type = Qt::AutoConnection) /*式4*/ static QMetaObject::Connection connect( const QObject *sender, PointerToMemberFunction signal , Functor functor) /*式5*/ static QMetaObject :: Connection QObject :: connect( const QObject * sender, const QMetaMethod& signal , const QObject * receiver, const QMetaMethod& method,Qt :: ConnectionType type = Qt :: AutoConnection) |
connect 第五個參數
type:用于指明信號和槽的關聯方式,它決定了信號是立即傳送到一個槽還是在稍后時間排隊等待傳送。關聯方式使用枚舉 Qt::ConnectionType 進行描述,下表為其取值及意義
枚舉 | 值 | 說明 |
---|---|---|
Qt::AutoConnection | 0 | **(自動關聯,默認值)。**若接收者駐留在發射信號的線程中(即信號和槽在同一線程中),則使用 Qt::DirectConnection,否則,使用 Qt::QueuedConnection。當信號發射時確定使用哪種關聯類型。 |
Qt::DirectConnection | 1 | 直接關聯。當信號發射后,立即調用槽。在槽執行完之后,才會執行發射信號之后的代碼(即 emit 關鍵字之后的代碼)。該槽在信號線程中執行。 |
Qt::QueuedConnection | 2 | 隊列關聯。當控制權返回到接收者線程的事件循環后,槽才會被調用 ,也就是說 emit 關鍵字后面的代碼將立即執行,槽將在稍后執行,該槽在接收者的線程中執行。 |
Qt::BlockingQueuedConnection | 3 | 阻塞隊列關聯。和 Qt::QueuedConnection 一樣,只是信號線程會一直阻塞,直到槽返回。如果接收者駐留在信號線程中,則不能使用此連接,否則應用程序將會死鎖。 |
Qt::UniqueConnection | 0x80 | 唯一關聯。這是一個標志,可使用按位或與上述任何連接類型組合。當設置 Qt::UniqueConnection 時,則只有在不重復的情況下才會進行連接,如果已經存在重復連接(即,相同的信號指同一對象上的完全相同的槽),則連接將失敗,此時將返回無效的 QMetaObject::Connection |
例子
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
// 式1 A ma; B mb; QObject::connect (&ma, SIGNAL( s( int ) ), &mb, SLOT(x( int ) ); // 式2 A ma; B mb; mb.connect(&ma, SIGNAL(s( int )), SLOT(x( int )); // 式3 A ma; B mb; QObject::connect(&ma, &A::s, &mb, &B::x ); // 式4 A ma; QObject::connect(&ma, &A::s, &B::x); // void x(int i)是類 B 中定義的靜態槽 // 式5 A ma; B mb; int indexSig = ma.metaObject()->indexOfSignal( "clicked(bool)" ); int indexSlot = mb.metaObject()->indexOfSlot( "close()" ); connect(&ma, ma.metaObject()->method(indexSig), &mb, mb.metaObject()->method(indexSlot)); |
補充:
- 形式 3 的槽函數可以不使用 slots 關鍵字聲明,任意的成員函數都可以是槽函數。形式 1 的槽函數必須使用 slots 修飾
- 形式 1 的槽函數不受 private 的限制,也就是說即使槽是 private 的,仍可通過信號調用該槽函數,而形式 3 則在使用 connect 時就會發生錯誤。
信號和槽的 disconnect
1
2
3
4
5
6
|
/*式1*/ static bool QObject::disconnect( const QObject *sender, const char * signal , const QObject *receiver, const char *method) /*式2*/ static bool QObject::disconnect( const QMetaObject::Connection &connection) /*式3*/ static bool QObject::disconnect( const QObject *sender, PointerToMemberFunction signal , const QObject*receiver, PointerToMemberFunction method) /*式4*/ static bool QObject::disconnect( const QObject *sender, const QMetaMethod & signal , const QObject*receiver, const QMetaMethod &method) /*式5*/ bool QObject::disconnect( const char * signal = Q_NULLPTR, const QObject *receiver = Q_NULLPTR, const char *method = Q_NULLPTR) const /*式6*/ bool QObject::disconnect( const QObject *receiver, const char *method = Q_NULLPTR) const |
補充:
- 形式 3 的槽函數可以不使用 slots 關鍵字聲明,任意的成員函數都可以是槽函數。形式 1 的槽函數必須使用 slots 修飾
- 形式 1 的槽函數不受 private 的限制,也就是說即使槽是 private 的,仍可通過信號調用該槽函數,而形式 3 則在使用 connect 時就會發生錯誤。
到此這篇關于Qt4和Qt5的信號和槽的使用區別的文章就介紹到這了,更多相關Qt4和Qt5的信號和槽內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家!
原文鏈接:https://blog.csdn.net/qq_33154343/article/details/118346008