Hi I have recently installed MS Access 2010 on my Windows Server 2003 32-bit. Since then one of my VBA scripts isn't running properly. MS Access is quitting unexpectedly giving this error with Kernel32 module.
I have used this line in my VBA code.
Private Declare Function CreateProcessA Lib "kernel32" (ByVal _
lpApplicationName As Long, ByVal lpCommandLine As String, ByVal _
lpProcessAttributes As Long, ByVal lpThreadAttributes As Long, _
ByVal bInheritHandles As Long, ByVal dwCreationFlags As Long, _
ByVal lpEnvironment As Long, ByVal lpCurrentDirectory As Long, _
lpStartupInfo As STARTUPINFO, lpProcessInformation As _
PROCESS_INFORMATION) As Long
Previously I use to have MS Access 2003 version and I never had any problem. Is there any compatibility issue with MS Access 2010-Windows Server 2003-Kernel32. Please help. Thanks
While I can't offer any specific guidance regarding the kernel32 issue you have encountered, I would make the recommendation that you start eliminating 32-bit Windows API calls from your code. Such calls will prevent your code from compiling under 64-bit versions of Access unless you tweak the declarations to make them "pointer safe" (ref: here), and in many of the more common cases where Win32 API calls were used there are more generic methods available now, like the FileDialog object for manipulating "File Open" and "File Save" dialogs.
In this case I would investigate the .Exec and .Run methods of the WScript.Shell object. There is a description of those methods (and the differences between them) here.
Related
Most of us just 'assume' that a file ending in '.docx' is a Word Document.
If I right-click on the file and show properties, then the properties window shows
Microsoft Word Document (.docx)
I want to know whether I can get that information programmatically.
IE, there's a way to declare
Private Declare Function FindExecutable Lib "shell32.dll" Alias "FindExecutableA" _
(ByVal lpFile As String, _
ByVal lpDirectory As String, _
ByVal lpResult As String) As Long
and use that to find what program is associated with the file.
If there is, WHAT is the call I need to make Windows give me the file type?
I am trying to create a macro that connects me to Essbase at the push of a button and am using the syntax found here https://docs.oracle.com/cd/E12825_01/epm.111/esb_client.pdf
I keep getting the error message that Essexcln.xll is not found. Is there any way around this error? I have done a file search on my computer and the file is no where to be found.
This is the full code I am using.
Declare PtrSafe Function EssVConnect Lib "ESSEXCLN.XLL" (ByVal sheetName As Variant, ByVal username As Variant, ByVal password As Variant, ByVal server As Variant, ByVal application As Variant, ByVal database As Variant) As Long
Sub Conn()
X = EssVConnect(Null, "email#email.com", "password", "http:", "h", "hg6")
End Sub
I'm guessing you have Smart View installed, but not the classic Excel add-in, which was the predecessor to Smart View. In order to find that .XLL file, you'll need to install the old add-in. Do note that it is not officially supported anymore. That are equivalent functions in the Smart View plugin that you can use instead. There is at least one alternative to the classic Excel add-in if you are looking for full VBA compatibility: the Dodeca Excel Add-in, although it is not free.
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.)
If I'm using Visual Basic to run an executable using the Shell() command, how would I run that executable as an administrator? My method works, at least in practice, but one executable won't run properly and I think that's the issue.
Here's an example of the command I'm trying to run.
Shell("%temp%\ninite.exe")
Edit: Sorry, this is VB.net, not VBA. I put a bad tag on there.
To stay strictly in VBA with no .NET dependencies, you should be able to use the ShellExecute Win32 function.
Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" ( _
ByVal hWnd As Long, _
ByVal lpOperation As String,
ByVal lpFile As String, _
ByVal lpParameters As String, _
ByVal lpDirectory As String, _
ByVal nShowCmd As Long) As Long
You can pass "runas" to lpOperation instead of the more usual "open" (commonly called the verb). Note that this may cause a dialog box to come up prompting the user for credentials.
A better way might be to use the CreateProcess or CreateProcessAsUser function which is probably the most powerful way to launch anything in Windows, but that is certainly more complex and I cannot tell you the details of how to get it to work right.
I have some VB 6.3 code that's normaly used on a 32 bit machine.
But I am now trying to run it on a 64bit machine and the code doesn't work.
It was programmed in VBA (autodesk)
Can someone help me with converting?
Declare Function OpenProcess Lib "kernel32" (ByVal dwDesiredAccess As Long, ByVal bInheritHandle As Long, _
ByVal dwProcessID As Long) As Long
Declare Function GetExitCodeProcess Lib "kernel32" (ByVal hProcess As Long, lpExitCode As Long) As Long
See Compatibility Between the 32-bit and 64-bit Versions of Office 2010 for a list of affected API calls and examples of conditional compilation to call either the 32- or 64-bit Declare statement depending on the bitness.