[vb6] Fix Palette when IDE Manifested - AddIn

[LeandroA]

very good job!, if I remember correctly it is the same solution that is used with the option buttons in windows xp

[LaVolpe]

very good job!, if I remember correctly it is the same solution that is used with the option buttons in windows xp

You may have a better memory. I thought it was that the WM_PRINTCLIENT message wasn't being handled? But am not sure any longer.

[wqweto]

You may have a better memory. I thought it was that the WM_PRINTCLIENT message wasn't being handled? But am not sure any longer.

For manifested frame controls to prevent option and check buttons widget images getting garbled *and* to prevent flicker on mouse hovering I use this in subclassproc

        Case WM_PRINTCLIENT, WM_MOUSELEAVE
            ControlSubclassProc = DefWindowProc(hWnd, wMsg, wParam, lParam)
            Exit Function

Edit: Btw, in this line

        lValue = SetWindowSubclass(hWnd, AddressOf WindowProc, hWnd Xor lValue, lValue)

the Xor usage is a nice trick but mostly useless.

If you always pass 0 for uIdSubclass there is *no* chance for collision with anyone else's add-in using the same 0 for uIdSubclass because the subclass entries are keyed both on uIdSubclass *and* pfnSubclass so to collide the other add-in has to use the same AddressOf WindowProc which is very unlikely.

uIdSubclass

Type: UINT_PTR

The subclass ID. This ID together with the subclass procedure uniquely identify a subclass. To remove a subclass, pass the subclass procedure and this value to the RemoveWindowSubclass function. This value is passed to the subclass procedure in the uIdSubclass parameter.

cheers,
</wqw>

[Eduardo-]

        Case WM_PRINTCLIENT, WM_MOUSELEAVE
            ControlSubclassProc = DefWindowProc(hWnd, wMsg, wParam, lParam)
            Exit Function

Hello. Do you know what is the difference between calling DefWindowProc and not subclassing the messages at all?

[wqweto]

Hello. Do you know what is the difference between calling DefWindowProc and not subclassing the messages at all?

If the custom subclassproc swallows the messages they will just stop working.For instance WM_PRINTCLIENT is used by AnimateWindow API so it will break for no apparent reason.

Generally you don't want to *not* forward system messages to *next* window proc which you don't explicitly respond to and/or implement. Calling DefWindowProc here instead just skips the VB's window proc which is buggy.

cheers,
</wqw>

[Eduardo-]

Calling DefWindowProc here instead just skips the VB's window proc which is buggy.

Ah, OK, I understand it now. Thank you.