id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
258	bugfix: hard crash when using _ClipBoard_GetData, (from the Clipboard UDF)	autoit@…	Gary	"This one's been around a while, and I think maybe I've fixed it. Or something. I'm sure this will help someone, since I've seen this problem go unanswered in the archived bug report forum!

I found this proposed change by looking at examples given for the Clipboard API in other programming languages, and the one *difference* that they all had in common was to lock and copy the memory when reading from the clipboard.

{{{
Func _ClipBoard_GetData_Carefully($iFormat = 1)
Local $hMemory, $tData

Local $hMemoryDest, $hLock

If Not _ClipBoard_IsFormatAvailable($iFormat) Then Return SetError(-1, 0, 0)
If Not _ClipBoard_Open(0) Then Return SetError(-2, 0, 0)
$hMemory = _ClipBoard_GetDataEx($iFormat)
_ClipBoard_Close()
If $hMemory = 0 Then Return SetError(-3, 0, 0)
Switch $iFormat
Case $CF_TEXT, $CF_OEMTEXT

;THIS WAS BAD: $tData = DllStructCreate(""char Text[8192]"", $hMemory)

$tData = DllStructCreate(""char Text[8192]"") ; do it this way so it is allocated...?
$hMemoryDest = DllStructGetPtr($tData)

; so let's lock that clipboard memory down and make our own for-sure copy.
$hLock = _MemGlobalLock($hMemory)
If $hLock = 0 Then Return SetError(-4, 0, 0)
; OK, $hLock should now be the pointer into the clipboard memory
_MemMoveMemory($hLock, $hMemoryDest, 8192)
_MemGlobalUnlock($hMemory)
; OK *now* we should have our own, good copy.

Return DllStructGetData($tData, ""Text"")
Case $CF_UNICODETEXT
Return _WinAPI_WideCharToMultiByte($tData)
Case Else
Return $hMemory
EndSwitch
EndFunc ;==>_ClipBoard_GetData_Carefully
}}}
"	Bug	closed	3.2.13.0	Standard UDFs	3.2.10.0	None	Fixed	clipboard