SetCursorPos Compile Error

[gruntingmonkey]

Hello Excelheads, I have some old code that I used to use many years ago. I have just loaded on my new work computer and I am getting a compile error:

"Compile error: The code in this project must be updated for use on 64-bit systems. Please review and update Declare statements and then mark them with the PtrSafe attribute."

Declare Function SetCursorPos Lib "user32.dll" (ByVal x As Long, ByVal y As Long) As Long
Sub Command2_Click()
End Sub

''''note this is an endless loop and can only be closed by pressing the ESC key
 MsgBox ("WARNING: This macro will cause an infinite loop. Press CTRL+BREAK to exit an infinite loop and then end the debugger")
Do
SetCursorPos 50, 50 '//// sets x & y position of mouse ( in pixels )
Application.Wait Now + TimeValue("00:00:05")

SetCursorPos 500, 500
Loop
End Sub

I have done some looking but don't understand the answers. I think I have to change the first line to something like:

Declare Function SetCursorPos Lib "user32.dll" (ByVal x As LongPtr, ByVal y As LongPtr) As LongPtr

Can anyone point out where I am wrong?

 

[Saurabhj]

Hi,

Please do change as below:

Declare PtrSafe Function SetCursorPos Lib "user32.dll" (ByVal x As LongPtr, ByVal y As LongPtr) As LongPtr

Thanks,
Saurabh

 

[John_w]

So that the declarations work on 32-bit and 64-bit Windows Office:

#If VBA7 Then
    Declare PtrSafe Function SetCursorPos Lib "user32.dll" (ByVal x As Long, ByVal y As Long) As Long
#Else
    Declare Function SetCursorPos Lib "user32.dll" (ByVal x As Long, ByVal y As Long) As Long
#End If

PS The x and y arguments and return value aren't addresses so using LongPtr is wrong.

 

[gruntingmonkey]

Fantastic, both answers work! I am confused why it matters about having long vs longPtr though. Can you explain in a little more depth if at all possible?

 

[RoryA]

There should not be any LongPtr variables in there. Nothing in there is a pointer or handle.

 

[John_w]

I meant Office, not Windows and have corrected my post.

Fantastic, both answers work! I am confused why it matters about having long vs longPtr though. Can you explain in a little more depth if at all possible?

You must use data types which match the API's signature. LongPtr is an alias which resolves to Long (32 bits) in 32-bit Office, or LongLong (64 bits) in 64-bit Office.

LongPtr, LongLong and PtrSafe are defined only in the VBA version 7 language, which comes with Office 2010 and later, hence the use of #If VBA7 Then so that these keywords are seen only when compiling on a VBA7 compiler and are ignored otherwise.

The code posted by Saurabhj won't compile on Office 2007 (VBA version 6) and earlier because it doesn't recognise LongPtr and PtrSafe. The declaration is correct on Office 2010+ 32-bit, because LongPtr resolves to Long (the correct data type for the x and y arguments and return value). On Office 2010+ 64-bit, LongPtr resolves to LongLong which would compile, but likely result in a run-time error.

More details here:

64-bit Visual Basic for Applications overview

Office VBA reference topic

docs.microsoft.com