Opened 2 years ago
Closed 2 years ago
#3982 closed Bug (Works For Me)
_ClipPutFile should not free memory
| Reported by: | Nine | Owned by: | J-Paul Mesnage |
|---|---|---|---|
| Milestone: | Component: | AutoIt | |
| Version: | 3.3.16.1 | Severity: | None |
| Keywords: | Cc: |
Description (last modified by )
As per discussion here and MSDN :
$aCall = DllCall("kernel32.dll", "ptr", "GlobalFree", "handle", $hGlobal) If (@error Or $aCall[0]) And Not $iError Then $iError = @error + 90 $iLastError = _WinAPI_GetLastError() EndIf
should be removed from the script.
Attachments (0)
Change History (8)
comment:1 by , 2 years ago
| Owner: | set to |
|---|---|
| Status: | new → assigned |
comment:2 by , 2 years ago
The function _ClipPutFile() uses SetClipboardData. MSDN state that if SetClipboardData succeeds, the system owns the object identified by the hMem parameter. The application may not write to or free the data once ownership has been transferred to the system, but it can lock and read from the data until the CloseClipboard function is called.
comment:3 by , 2 years ago
| Description: | modified (diff) |
|---|
comment:4 by , 2 years ago
I understand what you write again
just post a repro script to show where the error can occur
in what I post I don't see any error the _clipget get the right info
comment:5 by , 2 years ago
I don't know what can happen if you release the object owned by the system or specific cases that will cause an error but can we assume that Microsoft knows what they are talking about when they say that the object it's managed by the system? It might work in 99% of cases without any errors and produce an error in some niche cases. I think we should follow MSDN guidance and fix possible errors that might appear in some cases. It's just best practice.
comment:6 by , 2 years ago
Just produce a script that will provide the error with the current implementation.
for me the Clipget does not produce any error even if the the GlobalFree is executed before the CloseClipboard
comment:7 by , 2 years ago
There is not a systematic error when freeing the memory. It is a recommandation of MSDN. I think it should be enough.
comment:8 by , 2 years ago
| Resolution: | → Works For Me |
|---|---|
| Status: | assigned → closed |
Sorry I will close and except another Ticket with a script repro

Hi,
I don't see any reason to change the UDF
The following script work fine