Both functions return the same value for my widget. I can use the returned handle to register it with my raw input device but Qt calls the function
@bool QWidget::winEvent(MSG * message, long * result)@
of the widget that returned the native windows handle only, if the active and focused window contains a widget that can get the input focus. So the native windows handle of a QWidget is not suitable for use with Win32 raw input API. Therefore I need a valid handle of the applications core window (not the main window).
A possible solution would be to use the qWinAppInst() function to get a native Win32 hInstance value and to find the core application window via Win32 function calls:
yes i wrote a small test prog and was able to replicate your problem. the actual behavior I noticed is as follows:
when you undock if you ensure that the toolbar remains horizontal always, you still get back the custom icon, if the toolbar becomes vertical and then you try to dock it and resize, the custom icon is lost and the default is back. to check further ...
does QPixmap::ShareMode have anything to do with this. It says on x11, you have to explicitly delete the pixmap handle. how would one use it?
also, not related to leak, but I've found QImageReader to be more efficient in terms of memory footprint, you might cross check.. below from qt docs:
QImageReader is a specialized class which gives you more control when reading images. For example,
you can read an image into a specific size by calling setScaledSize(), and you can select a clip rect,
effectively loading only parts of an image, by calling setClipRect(). Depending on the underlying support
in the image format, this can save memory and speed up loading of images
If you don't do it already: For an embedded target, you could use the auxiliary tool qconfig: see the keyword "Fine-Tuning Features in Qt" in the Qt documentation. It is a simple GUI that lets you select and de-select the features or class you want excluded. It makes sure that class depending on an excluded class are excluded, too.
You cannot get rid of QWidget itself, because QGraphicsView inherits QWidget. But I would expect that most of the classes derived from QWidget should disappear. If you look at src/corelib/global/qfeatures.txt and search for "# Widgets", "# Dialogs", "# ItemViews", and "# Styles", you get a pretty good idea, what can and will be removed.