WinId and WinIdChange

[heorhiy]

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);
}@

[giesbert]

what does set() do?
perhaps it's related to this call?

[heorhiy]

nothing for tests set is just
void set(HWND h){
}

[giesbert]

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.

[heorhiy]

Hi,
Yes it seems that it is non native window.
Ok it creates temprorary HWND but why it cause infinity cycle, is it bug ?
Or maybe I shouldn't catch WinIdChange? But there is bothing about that in documentation.

[giesbert]

calling winId creates a temporary HWND and emits winIdChange. in winIdChange you call winId

inside the winIdChanged event, you should perhaps call QWidget::internalWinId which just returns the id and does not do any creational stuff...

[heorhiy]

Thank you, it works fine.
But I Didn't find any mention about QWidget::internalWinId in documentation.

[giesbert]

I found it in the code :-))

[andre]

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.

[heorhiy]

Yes, but it means that it's internal function and could disappear or be changed in any moment (:

Any way, now everything work, thank you much.

[giesbert]

I think it could be a bug, perhaps the event is send before some attributes are set so calling winId causes another loop. calling internalWinId just returns the value, never creates anything.

Shall we submit a bug report for it?

[andre]

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.

[giesbert]

Created a bug report: "QTBUG-18132":http://bugreports.qt.nokia.com/browse/QTBUG-18132