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.
Related
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 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
This question already has an answer here:
Simulate windowskey+L in visual basic?
(1 answer)
Closed 6 years ago.
How to lock computer using excel VBA?
Just in case, by "lock computer" I mean same effect when you do "start menu --> shutdown --> Lock".
For a x64 bit:
Option Explicit
Private Declare PtrSafe Function LockWorkStation Lib "user32.dll" () As Long
Private Sub LockStation()
LockWorkStation
End Sub
For x32 bit:
I think it's like this, can't test as I don't have a 32bit pc.
Option Explicit
Private Declare Function LockWorkStation Lib "user32.dll" () As Long
Private Sub LockStation()
LockWorkStation
End Sub
Happy coding.
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.