I got the code from :
https://www.developerfusion.com/thread/46191/how-to-capture-picture-using-webcam-in-vb60/
However while using this code I got an compilation 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 PtrSafe attribute.
I used :
#If VBA7 Then
Private Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal ms As LongPtr)
#Else
Private Declare Sub Sleep Lib "kernel32" (ByVal ms as Long)
#End If
It doesnt work.
The conditional compilation (#If VBA7) is not necessary unless your DB needs to run onOffice 2007or lower. If oldest version isOffice 2010you just need
Private Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal ms As Long)
becauseVBA7convertsLongPtrto data-typeLongon Office x86 and toLongLongon Office x64.
Recognize the argumentmsstays aLongas it is no Pointer/Handle. See How to convert Windows API declarations in VBA for 64-bit for more information.
If you need to support old Office-Versions before VBA7 use:
#If VBA7 Then
Private Declare PtrSafe Sub Sleep Lib "kernel32" (ByVal ms As Long)
#Else
Private Declare Sub Sleep Lib "kernel32" (ByVal ms as Long)
#End If
Related
Currently, my console application can return Integer values from the console application via the kernel32 function ExitProcess.
Public Declare Sub ExitProcess Lib "kernel32" (ByVal uExitCode As Long)
How do I return string values from the console application to the batch file?
I want to return string values like Successfully transformed 100 batches... etc.
On most platforms (and also in Windows) process exit codes are integer values, but you could write string data to the standard output stream by using the GetStdHandle and WriteFile functions.
Update As requested, I´ll serve you an example.
First, you´ll need to import some more Windows functions and define the required constants. In addition to the before-mentioned GetStdHandle and WriteFile methods, the AttachConsole and FreeConsole methods are also required.
Private Const ATTACH_PARENT_PROCESS As Long = -1
Private Declare Function AttachConsole Lib "Kernel32" ( _
ByVal dwProcessId As Long) As Long
Private Declare Function FreeConsole Lib "Kernel32" () As Long
Private Const STD_OUTPUT_HANDLE As Long = -11&
Private Declare Function GetStdHandle Lib "Kernel32" ( _
ByVal nStdHandle As Long) As Long
Private Declare Function WriteFile Lib "Kernel32" ( _
ByVal hFile As Long, _
ByVal lpBuffer As String, _
ByVal nNumberOfBytesToWrite As Long, _
ByRef lpNumberOfBytesWritten As Long, _
lpOverlapped As Any) As Long
In my sample project, I just added a Module and defined a Sub Main method - this serves as the entry point for the app. Please notice, that you don´t get any output from the app when running it from the VB6 IDE debugger. You´ll need to compile it, and run it from a terminal window (for instance cmd.exe).
The first thing to do is to attach to the console of the parent process (which is the console of the terminal window). Otherwise, the GetStdHandle method will return zero.
Dim handle As Long
AttachConsole (ATTACH_PARENT_PROCESS)
handle = GetStdHandle(STD_OUTPUT_HANDLE)
Once the console handle is obtained, the WriteFile method can be used to print text to the console.
Dim s As String
Dim numberOfBytesWritten As Long
s = "Hello World."
WriteFile handle, s, Len(s), numberOfBytesWritten, ByVal 0&
Before finally calling ExitProcess, the FreeConsole method is used to detach the process from the parent console.
In the new 64-bit version of Excel 2016 on OSX I obtained through update today, the conditional compilation doesn't seem to be followed when checking for function definitions that don't have PtrSafe defined (as would be the case for 32-bit platforms). In this example, we have different definitions of the same function for different platforms, and when Excel loads the add-in it dies and complains about the third definition not having a PtrSafe in the function declaration (but of course it doesn't because it is for a 32-bit platform).
Is there any way of making Excel not die when it hits this code in VBA? Or is this just a bug in 64-bit Excel 2016 on OSX? Seems like an obvious bug to me. Where do I report bugs in Excel?
#If Mac Then
' Even though the functions are exported with a leading underscore, Excel 2011 for Mac doesn't want the leading underscore as part of name
Private Declare PtrSafe Function get_global_param_string_private Lib "libCoolProp.dylib" Alias "get_global_param_string" (ByVal param As String, ByVal Output As String, ByVal n As Integer) As Long
#ElseIf Win64 Then
Private Declare PtrSafe Function get_global_param_string_private Lib "CoolProp_xls_x64.dll" Alias "get_global_param_string" (ByVal param As String, ByVal Output As String, ByVal n As Integer) As Long
#Else
Private Declare Function get_global_param_string_private Lib "CoolProp_xls_std.dll" Alias "_get_global_param_string#12" (ByVal param As String, ByVal Output As String, ByVal n As Integer) As Long
#End If
Unless the API function itself is different for 64 and 32 bit windows it suffices to use the VBA7 switch (which starts at Office 2010) for Windows:
#If Mac Then
' Even though the functions are exported with a leading underscore, Excel 2011 for Mac doesn't want the leading underscore as part of name
Private Declare PtrSafe Function get_global_param_string_private Lib "libCoolProp.dylib" Alias "get_global_param_string" (ByVal param As String, ByVal Output As String, ByVal n As Integer) As Long
#ElseIf VBA7 Then
Private Declare PtrSafe Function get_global_param_string_private Lib "CoolProp_xls_x64.dll" Alias "get_global_param_string" (ByVal param As String, ByVal Output As String, ByVal n As Integer) As Long
#Else
Private Declare Function get_global_param_string_private Lib "CoolProp_xls_std.dll" Alias "_get_global_param_string#12" (ByVal param As String, ByVal Output As String, ByVal n As Integer) As Long
#End If
I have Visual Basic for Applications code that uses WinHttp and works flawlessly with 32-bit Office 2010 running on 32-bit Windows XP. The same code fails to run properly on 64-bit Office 2013 on 64-bit Windows 8, even though it compiles fine.
The problem is that WinHttpCrackUrl() returns an error 87 "The parameter is incorrect" on Windows 8.
I have double-checked and triple-checked that all pointers are declared as LongPtr in the code where appropriate. What am I doing wrong?
Here is the code that runs fine on 32-bit Excel/Windows, but fails to run on 64-bit Excel/Windows:
Private Type URL_COMPONENTS
dwStructSize As Long
lpszScheme As LongPtr
dwSchemeLength As Long
nScheme As Long
lpszHostName As LongPtr
dwHostNameLength As Long
nPort As Long
lpszUserName As LongPtr
dwUserNameLength As Long
lpszPassword As LongPtr
dwPasswordLength As Long
lpszUrlPath As LongPtr
dwUrlPathLength As Long
lpszExtraInfo As LongPtr
dwExtraInfoLength As Long
End Type
Private Declare PtrSafe Function WinHttpCrackUrl Lib "WinHTTP" ( _
ByVal pwszUrl As LongPtr, _
ByVal dwUrlLength As Long, _
ByVal dwFlags As Long, _
ByRef lpUrlComponents As URL_COMPONENTS) As Long
Sub Test()
Dim result as Long
Dim URLComp As URL_COMPONENTS
Dim mURL as String
mURL = "http://www.stackoverflow.com" & vbNullChar
With URLComp
.dwStructSize = Len(URLComp)
.dwHostNameLength = -1
.dwSchemeLength = -1
.dwUrlPathLength = -1
End With
result = WinHttpCrackUrl(StrPtr(mURL), 0, 0, URLComp)
' Prints 1 on 32-bit Excel/Windows (indicating success)
' Prints 0 on 64-bit Excel/Windows (indicating failure)
Debug.Print result
' Prints 87 on 64-bit Excel/Windows ("The parameter is incorrect.")
Debug.Print err.LastDllError
End Sub
The struct is aligned in the C++ code, but VBA structs are packed. In 32 bit, for your struct, it does not matter since all members have alignment 4. But in 64 bit the pointers need 8 byte alignment and the struct has some extra padding. Put it in like this:
Private Type URL_COMPONENTS
dwStructSize As Long
padding1 As Long
lpszScheme As LongPtr
dwSchemeLength As Long
nScheme As Long
lpszHostName As LongPtr
dwHostNameLength As Long
nPort As Long
lpszUserName As LongPtr
dwUserNameLength As Long
padding2 As Long
lpszPassword As LongPtr
dwPasswordLength As Long
padding3 As Long
lpszUrlPath As LongPtr
dwUrlPathLength As Long
padding4 As Long
lpszExtraInfo As LongPtr
dwExtraInfoLength As Long
padding5 As Long
End Type
I guess you'll want some conditional compilation to switch better 32 and 64 bit versions but I must confess to having no idea how to do that with VBA.
Currently I am trying to implement a timer class in VBA. For that purpose I use the SetTimer and KillTimer functions of the Windows API...
This is the interface from Msdn:
UINT_PTR WINAPI SetTimer(
__in_opt HWND hWnd,
__in UINT_PTR nIDEvent,
__in UINT uElapse,
__in_opt TIMERPROC lpTimerFunc
);
And this is the way I declared the function wihtin my VBA-Module:
Private Declare Function SetTimer Lib "user32" (ByVal Handle As Long, _
ByVal TimerIDHandle As Any, _
ByVal ElapseTime As Long, _
ByVal AddressOfAndYourHandlerFunctionName As Long) As Long
'TimerIDHandle is of Type Any so I can pass Nothing to the function
I then Call the function this way:
Dim TimerID As Long
TimerID = SetTimer(Application.hWndAccessApp, ByVal 0&, Timer.Timeout, AddressOf TimeOutHandler)
As Vba does not accept a "Null" I have tried implementing "ByVal 0&". Is this the right way to do it?
Anyway...I call this function several times from the same Application and the function always returns 1 as an Identifier even though, according to Msdn, the function should return a unique ID for each timer that is created in the Window handle of the current Access Application.
Furthermore when I created only one timer the Callback function gets Called, but the Timer ID is given as 0, whereas the Settimer-Function returned a 1 at the time of initialization.
Here is my Callback Function Header:
Private Sub TimeOutHandler(ByVal WindowHandle As Long, _
ByVal TimerMessage As Long, _
ByVal TimerID As Long, _
ByVal ElapsedTime As Long)
Where am I wrong?
Any help is greatly appreciated of course ;-)
It worked. If it failed then it would have returned 0. You get a 0 for TimerID in the callback because you passed a 0 for the nIDEvent argument when you created the timer. You'll need to use the value that SetTimer returned to call KillTimer(). Think of it as a timer 'handle'.
You'll never get this code working in 64-bit mode so just declare the 2nd argument as Long.
I am using VB.NET and need to activate a certain window. Is this possible? If so, how?
You will need to use the Win32 API to do this.
First, find window you want to bring to front by calling FindWindow to obtain its handle, and then use SetForegroundWindow API to bring it to the foreground.
PInvoke contains declarations for these methods.
There are 2 solutions, one using Window API and another using pure VB.Net
you can use SetForegroundWindow(iHandle)
example with FindWindow to obtain Window handle
Public Declare Function SetForegroundWindow Lib "user32.dll" (ByVal hwnd As Integer) As Integer
Public Declare Auto Function FindWindow Lib "user32.dll" (ByVal lpClassName As String, ByVal lpWindowName As String) As Integer
Dim hWnd As Integer
hWnd = FindWindow(strClassName, strWindowCaption)
If hWnd > 0 Then
SetForegroundWindow(hWnd)
End If
you can use AppActivate(iProcessId)
example with GetActiveAppProcess() to obtain input Window active process in an hook program
Dim hWnd As IntPtr
Dim inputProcess = GetActiveAppProcess()
hWnd = GetActiveAppProcess().MainWindowHandle
AppActivate(inputProcess.Id)
'you can also use SetForegroundWindow
'SetForegroundWindow(inputProcess..MainWindowHandle)
SendKeys.Send("^v")