WinId and WinIdChange
-
This code cause infinity cycle. So when I'm pressing button winId is calling and cause QEvent::WinIdChange.
Inside Event handler winid is called again to obtain new winId and it cause one more QEvent::WinIdChange event and so on. What I'm doing wrong. Thank you.@void ProcessTab::OnButtonClick()
{
set(winId());
}bool ProcessTab::event( QEvent* event )
{
if (event->type() == QEvent::WinIdChange){
set(winId());
return true;
}
return QWidget::event(event);
}@ -
Hi heorhiy,
have you read the docs?
bq. If a widget is non-native (alien) and winId() is invoked on it, that widget will be provided a native handle.
On Mac OS X, the type returned depends on which framework Qt was linked against. If Qt is using Carbon, the {WId} is actually an HIViewRef. If Qt is using Cocoa, {WId} is a pointer to an NSView.
This value may change at run-time. An event with type QEvent::WinIdChange will be sent to the widget following a change in window system identifier.Might it be that you ahve a non native window (a child) where you call winId()?
Then it might be created on runtime as temporary HWND.
-
But that is a bit weird behaviour, isn't it? I mean, the WinIdChanged event is just a QEvent, so it does not carry the changed id (right?). So, what are you supposed to do when you receive that event then? If you actually want to react to it and use the changed id, you have to call winId(), which in turn will trigger a change, if I understand you correctly.
I can understand that heorhiy is confused on this.
-
I think that either calling winId() should not trigger a change in the winId (though it might trigger the first creation of one), or the WinIdChanged event needs an event subclass of its own that includes the actual value of the new winId. As it stands, it seems quite useless.
Yes, I think a report is in order.
-
Created a bug report: "QTBUG-18132":http://bugreports.qt.nokia.com/browse/QTBUG-18132