I'm currently updating a document for our company that no longer runs when used on a 64bit Microsoft Office suite (32bit remains fine).
I understand that functions and declarations require the 'Ptrsafe' word to be added - but when I add it to this function it tells me the syntax is wrong
Private PtrSafe Function executeSingle(Optional rurl As String = vbNullString, _
Optional qry As String = vbNullString, _
Optional complain As Boolean = True, _
Optional sFix As String = vbNullString _
) As cJobject
I have no idea why though...it works fine if you remove PtrSafe. Any ideas?
You should only need to use the "Declare" statement when you declare a reference to an external procedure in a dynamic-link library (DLL). It is always recommended that you use the PtrSafe keyword when doing this. Like A.S.H. said, you don't need to do this for your own functions. See this link for more info.
Here is an example from MSDN of the correct syntax for using PtrSafe. It includes conditional compilation syntax, which might be useful in your situation:
Declare PtrSafe Function GetActiveWindow Lib "User32" () As LongPtr
#If Vba7 Then
' Code is running in 32-bit or 64-bit VBA7.
#If Win64 Then
' Code is running in 64-bit VBA7.
#Else
' Code is not running in 64-bit VBA7.
#End If
#Else
' Code is NOT running in 32-bit or 64-bit VBA7.
#End If
Related
As continuous to this question: How to convert 32 bit VBA code into 64 bit VBA code, I wrote the following vba access code:
#If VBA7 Then
Private Declare PtrSafe Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long
#Else
'The folowing line is ilegal in Access 2019:
Private Declare Function GetOpenFileName Lib "comdlg32.dll" Alias "GetOpenFileNameA" (pOpenfilename As OPENFILENAME) As Long
#End If
This code runs fine on Access 2013 but fails on Access 2019. The Else case is illegal on 2019.
What is wrong?
Nothing is wrong.
VBA7 is True for Access 2007 and later, so the Else part will never run in a newer Access.
You will need Access 2003 or earlier to check out the Else part.
In many of my .NET projects I declare library functions that are used globally. The DLLs that contain these functions are registered when the product is installed so the declaration is simple:
eg.
Declare Sub SomeFunction Lib "SomeLib.dll" (ByVal CommonStr As String, ByVal
WhichVar As Integer)
However, when I'm debugging/developing I often need to explicitly reference the path of the dll like this:
Declare Sub SomeFunction Lib "C:\Usethisone\SomeLib.dll" (ByVal CommonStr As String, ByVal
WhichVar As Integer)
My problem is that I have occasionally forgotten to remove the file path when sending the code to QA so it gets sent back.
So, how can I code this so I don't need to remember to change this path every time I send a project out for testing? The Declares, of course, are in the declaration section of the class so I can't use any If logic to switch declarations ( eg. If testingfile.txt Exists then use testing declaration).
I've also thought of creating a global dll that I could inherit from - one with the production declarations and one with the testing declarations - but that is a major change at a low level. I'm afraid it either just wouldn't work, would cause reference issues and/or would not be approved by management.
Any simpler ideas out there?
You can use Conditional Compilation in Visual Basic
#If DEBUG
Declare Sub SomeFunction Lib "C:\Usethisone\SomeLib.dll" (ByVal CommonStr As String, _
ByVal WhichVar As Integer)
#Else
Declare Sub SomeFunction Lib "SomeLib.dll" (ByVal CommonStr As String, _
ByVal WhichVar As Integer)
#End If
If you use the Debug configuration, you get the code for development, if you use the Release configuration you get the production version of the code.
Note that the #If is evaluated at compile time, not at runtime. Only the matching code is compiled. The other one is discarded.
See also: #If...Then...#Else Directives.
In VB.NET as in C# you can use the preprocessor directive #if...#else...#end if to declare two different versions of your dll, one for the DEBUG compilation and one for the RELEASE compilation
#if DEBUG Then
Declare Sub SomeFunction Lib "C:\Usethisone\SomeLib.dll" (ByVal CommonStr As String, ByVal
WhichVar As Integer)
#else
Declare Sub SomeFunction Lib "SomeLib.dll" (ByVal CommonStr As String, ByVal
WhichVar As Integer)
#end if
Now when you compile to send your app to the QA you just switch to Release and you have the correct implementation to send
Side note: Take a look at the difference between Declare and the DllImport attribute
I'm using this Windows API call in 32-bit Excel, and it's working fine:
Declare Function WNetGetConnection Lib "MPR.DLL" _
Alias "WNetGetConnectionA" ( _
ByVal lpszLocalName As String, _
ByVal lpszRemoteName As String, _
lSize As Long) As Long
I'm told that a small percentage of our corporate users will soon be going to 64-bit Excel. I don't have access to 64-bit Excel and I haven't been able to find any coworkers nearby who do.
According to this file, if I'm reading it correctly...
http://www.cadsharp.com/docs/Win32API_PtrSafe.txt
...this is the correct syntax of that function for 64-bit Excel:
Declare PtrSafe Function WNetGetConnection Lib "MPR.DLL" _
Alias "WNetGetConnectionA" ( _
ByVal lpszLocalName As String, _
ByVal lpszRemoteName As String, _
lSize As Long) As Long
But is that correct? The only difference is adding PtrSafe. Should it point to a different, 64-bit version of MPR.DLL? Also, should lSize be LongLong rather than Long?
But is that correct?
Yes. But don't take my word for it. Get a copy of Office and test it.
The only difference is adding PtrSafe. Should it point to a different, 64-bit version of MPR.DLL?
No. Windows chooses the appropriate DLL for the bitness of your process. For standard WinAPI components, you should only use the DLL name, and never a full path. Windows will pick the correct one.
Also, should lSize be LongLong rather than Long?
It should be ByRef Long. The WNetGetConnection documentation shows the function prototype:
DWORD WNetGetConnection(
_In_ LPCTSTR lpLocalName,
_Out_ LPTSTR lpRemoteName,
_Inout_ LPDWORD lpnLength
);
DWORD is a 32 bit unsigned integer.1 LPDWORD is a pointer to a DWORD, which in VB(6/A) is ByRef lpnLength As Long.
As a bonus:
In the Windows API LONG is also 32 bit. This does not change whether you're running 32 or 64 bit. (sizeof(DWORD) == sizeof(LONG) == sizeof(INT))
VBA Data Types
1Fun Fact: VBA doesn't have unsigned integer types, since VB6 didn't have them. VB6 came out in '98.
A brand-new never-before-used single user license for Office 2016 is running about $150 as of 7-Oct-15. It's also available through the MSDN subscription programs. It's also available at many fine retailers. (I'm intentionally not posting links.)
I found this answer:
Declare Function SetComputerName Lib "kernel32" Alias "SetComputerNameA" ( _
ByVal lpComputerName As String _
) As Long
but it dont work for me,
could you please show me how to change computer name in vb.net
You may not simply paste Declared definitions from VB6 to VB.NET.
In .NET you don't use Alias "SetComputerNameA" to call ANSI version of the function. The runtime manages this, and VB now supports both Ansi and Unicode.
VB6's Long matches to VB.NET's Integer.
Declare Auto Function SetComputerName Lib "kernel32" (ByVal lpComputerName As String) As Integer
I noticed that Office 2010 comes with Visual Basic for Applications 7.0. However I can't seem to find much documentation on what changes were made. Does anyone have a summary of the changes, or any resources describing the differences?
There's not a whole lot that has changed between VBA6 and VBA7. VBA7 was introduced to support 64-bit versions of both Office and Windows (see below on what those differences are). Here are the key changes:
64-bit support, primarily for API
calls. This is both used to make your code work with your OS/Office version as well as others' (i.e. someone on Office 2003/WinXP)
If you are on a 64-bit version of
Windows, but are on a 32-bit version
of Office, you can declare API calls
like below.
.
#If Win64 Then
Declare PtrSafe Function GetTickCount64 Lib "kernel32"() As LongLong
#Else
Declare PtrSafe Function GetTickCount Lib "kernel32" () As Long
#End If
If you are on a 64-bit version of
Windows, and are on a 64-bit version
of Office, you can declare API calls
like:
.
#If VBA7 Then
Declare PtrSafe Function FindWindow Lib "user32" Alias "FindWindowA" ( _
ByVal lpClassName As String, _
ByVal lpWindowName As String) As LongPtr
#Else
Declare Function FindWindow Lib "user32" Alias "FindWindowA" (ByVal _
lpClassName As String, ByVal lpWindowName As String) As Long
#End If
To support this, there are:
Three new keywords (2 data types and
1 modifier): LongPtr, LongLong and PtrSafe
One new function: CLngLng() (i.e.
Int64)
The new compilation constants as used
above: VBA7 and Win64
This piece on MSDN has more on the changes in VBA 7 for Office 2010:
http://msdn.microsoft.com/en-us/library/ee691831(loband).aspx#odc_office2010_Compatibility32bit64bit_IntroducingVBA7CodeBase
VBA7 is compatible with 64-bit versions of Office.
There are other changes as well... I'm having users in the field report that code which functioned properly in 2007 no longer works and shows errors.
Example, this works in VBA6 (Excel 2007)
PRINT STRING$(80,"=")
mynewdata = MID$(mydata, 15,4)
It prints out a line made of "=" characters as a visual break, then looks at mydata, jumps over 15 characters and gets 4 of them, the result is stored in mynewdata. It fails in VBA7 (Excel 2010).
I did find a potential workaround...
PRINT VBA.STRING$(80,"=")
mynewdata = VBA.MID$(mydata, 15,4)
OR
PRINT VBA.STRING(80,"=")
mynewdata = VBA.MID(mydata, 15,4)
A complete list of changes would still be helpful... and/or a file converter.