This behaviour was tested against native winhlp32 by pressing down the
left mouse button and holding it while over the link to avoid having
WM_LBUTTONUP sent. I noticed that the action for clicking the link
happened right away, without waiting for me to release the mouse button.
Previously the cursor was being set by winhlp32 on WM_MOUSEMOVE, then
the richedit control would change it again on WM_SETCURSOR. Since the
cursor set in both of these places was different, the cursor would
flicker from being frequently changed.
The reason winhlp32 is setting the cursor, rather than letting the
richedit control set the cursor, is that winhlp32 needs the hand cursor
to be shown over a link. My first instinct was to just add the CFE_LINK
effect to the link characters, however this also forced a colour for the
link that was inconsistent with native winhlp32. Native winhlp32
doesn't seem to load any richedit dll, so this doesn't imply that there
is an undocumented way of changing the colour of characters with
CFE_LINK.
This patch has winhlp32 override the WNDPROC for the richedit control to
handle the WM_SETCURSOR. It simply sets the cursor to the hand if the
cursor is over the link, otherwise it just calls the original richedit
window proc.
Previously the richedit control contents were scrolled directly using
ScrollWindow. This caused the richedit control to not actually scroll,
but only look like it scrolled, therefore causing plenty of glitches.
Owen Rudge