Archive: WM_SETCURSOR with Bitmap Control


WM_SETCURSOR with Bitmap Control
I've been trying to set a hand cursor on a bitmap image I have placed using nsDialogs like this:

${NSD_CreateBitmap} 0 108u 100% 100% ""
Pop $IMAGE
${NSD_SetImage} $IMAGE "$PLUGINSDIR\blah.bmp" $IMAGEHANDLE

GetFunctionAddress $0 TestFunction
nsDialogs::OnClick $IMAGE $0

How can I make it in a way that when the user hovers over the bitmap, the cursor changes to IDC_HAND?


you need to handle the window message, and nsDialogs can't do it.

http://nsis.sourceforge.net/WndSubclass_plug-in can do it, but it's very much in the Alpha stage, and you pretty much need to be a win32 programmer to use it


If I'm not mistaken I only need to use LoadCursor() and SetCursor() correct?


now this is a bit weird as i made a modification to nsDialogs to do just the same thing for one of the winamp lang pack authors last weekend (still need to sort out the patch difference and to have a look at implementing this as well).

the attached 7z file has an altered nsDialogs.dll and nsDialogs.nsh - should be able to just extract it out into the main NSIS folder (with path extraction) to have it replace the required files.

then the following will need to be added to the script something like the following (am guessing at the variable's being used):

${NSD_OnSetCursor} $IMAGE Button_SetCursor ; add after the button has been created

Function Button_SetCursor ; add this where you want it to go
Pop $0
Push 32649 ;${IDC_HAND}
FunctionEnd


-daz


but should there be a special callback for every message? nsDialogs can't support everything. It would make more sense if nsD had some sort of subclass support, or that people would use external subclass plugins IMHO


i agree with you that it can't support everything (and obviously that's where the subclass has to come in on things) but for certain common cases then it makes sense to have it natively done in nsDialogs. and in this case, it's a minor adjustment to expand the code already used for setting the cursor on the link control to be able to be applied for the other created controls.

native subclass support of some form would make things easier but then it comes down how to integrate that into the existing framework.

then again i thought most of the 'special' cases which would require subclassing of some sort are aready handled by existing plugins. either way it's an area that needs to be worked through a bit more (since all i've done was a quick hack to get something working [to save you some #nsis questions ;) ] but is something that needs a bit more thinking through as such).

-daz