Patrice,
I am talking
not about conventional memory leaks but rather
about GDI object leaks like HDC, HPEN, HBRUSH, HBITMAP, etc. handles. Those that you create then select/deselect and then delete or release. These are leaking (i.e. are created but not destroyed, or fail to be destroyed, after use) at a rate of 8 handles per spinner popup.

You should examine it not in the debug mode but rather in your Task Manager if you inspect its
GDI Objects table column.
Such a leak is usually observed when one attempts to delete the objects that are currently selected in a DC, or DCs with non-native GDI objects created by the user and selected into them. All such deletions fail silently, which results in the app's GDI object count growing rapidly as more and more models are reloaded into the app throughout the same session.
When the ZI_Spinner calls are commented out, my OR GDI object count is absolutely steady at 141/143 GDI handles throughout the entire session. I'm seeing this issue with the ZI_Spinner both precompiled into GDImage and as a standalone include you sent me.
This gives me a reason to believe that the cause of leakage lies in an improper use of GDI handles in the ZI_Spinner source code.
[UPD] I was lucky to reduce the leakage to 6 handles per popup. So far so good...