Afrow UK
9th August 2011 15:35 UTC
SysLink control
I'm trying to get SysLink to work on Windows XP. The control itself works fine, but when closing the installer (if the control is on the main UI) or when moving from a custom page (if the control is on a custom page) the installer will crash (mod name is comctl32.dll).
Code to add the link to the outer (main) UI:
System::Call `user32::CreateWindowExW(i 0, w 'SysLink', w 'Blah blah <A>blah blah</A>.', i ${WS_CHILD}|${WS_VISIBLE}|${WS_TABSTOP}, i 0, i 0, i 100, i 100, i $HWNDPARENT, i 0, i 0, i 0)`
Code to add the link to a nsDialogs page:
nsDialogs::CreateControl SysLink ${WS_CHILD}|${WS_VISIBLE}|${WS_TABSTOP} 0 10u 10u -20u 10u `Blah blah <A>blah blah</A>.`
Pop $R0
You can handle the nsDialogs page link clicks by adding a nsDialogs OnNotify callback:
Function BlahLink_Notify
Pop $R0
Pop $R1
Pop $R2
${If} $R1 = ${NM_CLICK}
${OrIf} $R1 = ${NM_RETURN}
System::Call `*$R2(i, i, i, i, i .R3)`
${If} $R3 == 0 ; link index
ExecShell open `http://www.google.com`
${EndIf}
${EndIf}
FunctionEnd
I'm not sure what to try next really to fix this crash. Any suggestions?
Stu
Anders
9th August 2011 16:38 UTC
It dies in CLink::~CLink, my guess is a bad pointer or something. IIRC NSIS uses GWL_USERDATA, if the link control does the same there will be trouble...
This sort of works (as long as you don't click cancel):
SysLink
xpstyle on
>Function custleave
System
::Call 'user32::SetParent(i $SysLink,i 0)'
>ShowWindow $SysLink 0
FunctionEnd
>Function custcreate
nsDialogs::Create 1018
nsDialogs::CreateControl SysLink ${WS_CHILD}|${WS_VISIBLE}|${WS_TABSTOP} 0 10u 10u -20u 10u `Blah blah <A>blah blah</A>.`
>pop $SysLink
nsDialogs::Show
FunctionEnd
page custom custcreate custleave
>
Afrow UK
9th August 2011 17:06 UTC
Ah right that must be it then. From the MSDN page:
Why does calling SetWindowLong(Handle, GWL_USERDATA, (long)5) where Handle is a SysLink control, makes the application non-responsive and crash on an XP system? It seems the syslink control is using itself the GWL_USERDATA when it should definitely not, since it is supposed to be reserved for the application.
--
The GWL_USERDATA value belongs to the window class. You are misinterpreting the word "application"; in this context it means "for use by somebody other than the operating system." it doesn't mean "the thing that ends in .EXE".
Stu
Anders
9th August 2011 17:38 UTC
I did not verify that the problem is GWL_USERDATA, but if it is; you could create a plugin that adds HWNDs to a safe list and exclude them from the color handling by subclassing their parent