- 23 Jan, 2012 1 commit
-
-
Alexandre Julliard authored
-
- 20 Jan, 2012 1 commit
-
-
Alexandre Julliard authored
-
- 08 Apr, 2011 1 commit
-
-
Francois Gouget authored
-
- 31 Mar, 2011 1 commit
-
-
Francois Gouget authored
-
- 15 Oct, 2010 1 commit
-
-
Alexandre Julliard authored
-
- 24 Aug, 2010 1 commit
-
-
André Hentschel authored
-
- 14 Jun, 2010 1 commit
-
-
Eric Pouech authored
-
- 07 Jun, 2010 3 commits
-
-
Eric Pouech authored
-
Eric Pouech authored
-
Eric Pouech authored
-
- 22 May, 2010 1 commit
-
-
Alexandre Julliard authored
-
- 03 May, 2010 1 commit
-
-
Gerald Pfeifer authored
-
- 20 Apr, 2010 1 commit
-
-
Gerald Pfeifer authored
-
- 19 Apr, 2010 1 commit
-
-
Alexandre Julliard authored
-
- 09 Nov, 2009 1 commit
-
-
Rob Shearman authored
winhlp32: Restore the original window proc for the richedit control before freeing the winhelp window memory.
-
- 22 Sep, 2009 1 commit
-
-
Eric Pouech authored
-
- 24 Jul, 2009 1 commit
-
-
Owen Rudge authored
-
- 29 Jun, 2009 1 commit
-
-
Eric Pouech authored
-
- 04 Jun, 2009 1 commit
-
-
Stefan Stranz authored
-
- 01 Jun, 2009 6 commits
-
-
Eric Pouech authored
-
Eric Pouech authored
-
Eric Pouech authored
-
Eric Pouech authored
-
Eric Pouech authored
-
Eric Pouech authored
-
- 06 May, 2009 1 commit
-
-
Rein Klazes authored
-
- 06 Apr, 2009 1 commit
-
-
Michael Stefaniuc authored
-
- 24 Mar, 2009 1 commit
-
-
Dylan Smith authored
-
- 12 Mar, 2009 1 commit
-
-
Dylan Smith authored
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.
-
- 11 Mar, 2009 1 commit
-
-
Dylan Smith authored
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.
-
- 09 Mar, 2009 1 commit
-
-
Dylan Smith authored
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.
-
- 24 Feb, 2009 1 commit
-
-
Alexandre Julliard authored
-
- 02 Feb, 2009 1 commit
-
-
Marcus Meissner authored
-
- 09 Jan, 2009 1 commit
-
-
Alexandre Julliard authored
-
- 08 Jan, 2009 2 commits
-
-
Francois Gouget authored
-
Francois Gouget authored
-
- 05 Aug, 2008 1 commit
-
-
Kirill K. Smirnov authored
-
- 01 Aug, 2008 1 commit
-
-
Kirill K. Smirnov authored
-
- 14 Jul, 2008 2 commits
-
-
Eric Pouech authored
-
Eric Pouech authored
-