1.1.29.00 Win32 API Call `EnumClipboardFormats` Fails

[TLM]

[lexikos: Topic moved from Bug Reports.]

When I try to enumerate clipboard formats using DllCall( "EnumClipboardFormats", uint, *0 or 1* ) in the latest version I only return 0 now where in the previous build I returned the correct clipboard formats.

[swagfag]

this works for me win10 x64 1.1.29.00 w64

Code: Select all

MsgBox, % "calling OpenClipboard(),`nreturned: " DllCall("OpenClipboard", "Ptr", 0)
MsgBox, % "OpenClipboard()`nLastError: " DllCall("GetLastError")

MsgBox, % "calling EnumClipboardFormats(0),`nreturned: " format := DllCall("EnumClipboardFormats", "UInt", 0)
MsgBox, % "EnumClipboardFormats(0)`nLastError: " DllCall("GetLastError")

MsgBox, % "calling EnumClipboardFormats(format)`nreturned: " format := DllCall("EnumClipboardFormats", "UInt", format)

[lexikos]

It works for me also.

There is an issue with WinMove which may have indeterminate effects. If that's not the cause, I will need a script to reproduce the problem.

Side note: You should generally use A_LastError to get the error code set by the last DllCall, not DllCall("GetLastError"), which may be affected by internal code or other commands.

[TLM]

I'm starting to think this has less to do with the function call..
Anyway I've modified this function to display the clipboard formats:

Code: Select all

EnumClipFormats()
{
	FmtArr := [], DllCall( "OpenClipboard" )

	While ( DllCall( "CountClipboardFormats" ) >= a_index )
	{
    	FmtArr.Push( fmt := DllCall( "EnumClipboardFormats", uint, a_index = 1 ? 0 : fmt ) )
    	TempStr .= "Clipboard Format " a_index . ": " fmt "`n"
	}

	DllCall( "CloseClipboard" )
	
	msgbox % TempStr

	Return FmtArr
}

In 1.1.28.02 copying text from notepad returns:

Code: Select all

Clipboard Format 1: 13
Clipboard Format 2: 16
Clipboard Format 3: 1
Clipboard Format 4: 7

In 1.1.29.00 I get

Code: Select all

Clipboard Format 1: 0
Clipboard Format 2: 0
Clipboard Format 3: 0
Clipboard Format 4: 0

[swagfag]

well, for me on win10 x64 with both 1.1.28.02 and 1.1.29.00, the function doesnt work unless a nullptr or any other hwnd is passed to OpenClipboard
checking A_LastError as Lexikos suggested, yields 1418 - ERROR_CLIPBOARD_NOT_OPEN(Thread does not have a clipboard open.)
happens regardless if compiled or just ran as a script

[TLM]

hrmm will test a hwnd & on Win10 later today..
edit: adding the script handle to OpenClipboard() did work in 1.1.29.00
( although now I'm not sure why it worked without one before )
thanks

[swagfag]

i dont know either, its supposed to be an optional parameter anyway

[nnnik]

The Stack might have had a Ptr Sized 0 on top of it and popping it when exiting the function might have coincidently not made a difference.
( e.g. when a function chooses to restore the stack to a previous pointer rather than removing its own parameters from the stack )
Also optional in the terms of C++ means that it can be 0 not that it can be omitted.

[TLM]

Thanks, yea I was under the assumption that optional ment either or. It also still doesn't answer why 1.1.28 doesn't need a null pointer or handle and 1.1.29 does..
Anyway, I guess I'll have to update scripts with calls that have optional parameters.

[nnnik]

I tried to explain that in my first 2 sentences - but without a background in assembly and how a CPU works I guess you will never understand them

[TLM]

lol I was referring to the function's documentation

[lexikos]

It also still doesn't answer why 1.1.28 doesn't need a null pointer or handle and 1.1.29 does..

The implied question is based on a false presumption. Both versions require the parameter to be specified. When you don't specify it, you get indeterminate/undefined behaviour. That does not necessarily mean crashing; it means no one can say what will happen. The function's documentation is for C and up; it will not tell you what happens when you omit the parameter, because you cannot omit the parameter. (You could via an incorrectly typed function pointer, in which case the spec probably says either "undefined" - i.e. anything goes - or doesn't specify - i.e. anything goes.)

Slight changes in code can affect how code for other parts of the program are generated, which may affect what values are on the stack (or the uninitialized portion of memory which the stack will occupy).