I need to get code to retrieve the Windows userID for the current session in VB (for Access 2013) on a 64-bit system.
I've tried the solution suggested at How to get logged-in user's name in Access vba?, but apparently this doesn't work on my 64-bit machine. I've also tried to figure out how to integrate the info at http://msdn.microsoft.com/en-us/library/office/gg278832.aspx, but I can't figure it out.
I am a NOVICE VB programmer, so I really need the actual code to do this. (I can [probably] figure out how & why the code does what it does after I see it, but I can't come up with it from scratch at this point.)
I'm hoping this answer will be helpful to others, too.
Thanks so much!
Aloha,
-pt
This should work, too:
Dim wshNet As Object
Set wshNet = CreateObject("WScript.Network")
MsgBox "Hello, " & wshNet.UserName & "!"
Set wshNet = Nothing
The answer you linked to works on a 32 bit version of access. For 64 bit versions, you need to use a pointer-safe signature:
Private Declare PtrSafe Function GetUserName Lib "advapi32.dll" Alias
"GetUserNameA" (ByVal lpBuffer As String, nSize As LongPtr) As Long
(it might work with nSize As Long - I don't have a 64-bit access at hand)
Related
I am developing an app in VB.NET (for a customer with hardware using FTDI USB serial chip. Communication uses FTD2XX library and the respective Nuget package (FTD2XX.Net v1.2.1). After some update of Visual Studio (probably update to 17.1, but I am not sure) all functions except a few stopped working. Current VS version is 17.1.1.
For instance, it is possible to obtain number of devices attached by the FTDI driver:
Friend Declare Function FT_CreateDeviceInfoList Lib "FTD2XX.DLL" (ByRef lngNumDevs As Integer) As Integer
...
Dim ftStatus As Integer
Dim numDevices As Integer
ftStatus = FT_CreateDeviceInfoList(numDevices)
In the above snippet ftStatus result = 0 (i.e. OK) and numDevices is set to 1 (correct).
Problem starts when I want to do something serious:
Friend Declare Function FT_GetComPortNumber Lib "FTD2XX.DLL" (ByVal lnghandle As Integer, ByRef lplComPortNumber As Integer) As Integer
Friend Declare Function FT_Open Lib "FTD2XX.DLL" (ByVal iDevice As Integer, ByRef lnghandle As Integer) As Integer
Friend Declare Function FT_Close Lib "FTD2XX.DLL" (ByVal lnghandle As Integer) As Integer
Dim portHandle as Integer
Dim cpNumber as Long
For i% = 0 To 255
ftStatus = FT_Open(i, portHandle)
If ftStatus = FT_OK Then
ftStatus = FT_GetComPortNumber(portHandle, cpNumber)
ftStatus = FT_Close(portHandle)
' here is some non-essential code registering that port at index i% exists...
End If
Next
In the above code, FT_Open returns ftStatus = 0 (FT_OK) and sets a value for portHandle.
However, the next call, FT_GetComPortNumber, returns ftStatus = 1 (FT_INVALID_HANDLE) and the value passed to cpNumber is 0xFFFF (shows as positive, but in fact should be -1, I guess...). What is worse, FT_Close() also returns FT_INVALID_HANDLE and the port remains open. I verified it by trying to open the port from another app - access denied.
Sometimes it seems that FT_Write and FT_Read functions work despite this mess, but in my last try I could not any communication with the hardware at all.
I tried to use System.IO.Ports.SerialPort as possible workaround but that does not work at all. On top of that, I need to use bit-bang on RTS, because it controls supply voltage and reset of the hardware connected to the other side of the FTDI chip. Without possibility to bring RTS down for hundreds of milliseconds and then hold it up all the time I cannot control the hardware. AFAIK System.IO.Ports.SerialPort provides no possibility to do that.
What could be the solution?
After much trial and error, it appears to be a problem in compile configuration.
Open Solution properties Window and click on the Compile tab.
Then click on "Advanced Compile Options"
If the "Remove integer overflow checks" checkbox is not checked, check it!
I have no idea how an integer overflow check can garble a 32-bit number not involved in any arithmetic operation whatsoever, but this is what really happened. I consider this a bug in Visual Basic compiler used in Visual Studio 17.1.6 (and a number of previous versions), but I did not dig deeper in this topic.
#HansPassant writes:
The declarations are wrong, it must be lnghandle As IntPtr. The difference between Integer and IntPtr matter when you run the app in 64-bit mode. Prone to happen when targeting .NETCore, as likely in VS2022.
-- Hans Passant
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'm trying to use RFID Contactless Smart Card (T8/D8 Series) for my final project.
But i have problem acessing the dcrf32.dll file in my form.
There are 3 things included in RFID Package, (therefore : 12 smartcards, an usb port, and a driver CD)
In the driver CD, there are so many sample project in some programming language, except VB.NET, i tried them one by one, and that's work.
There is a folder named "win32-dll", it have 3 files inside (dcrf32.dll, dcrf32.h, dcrf32.lib). I have to copy them all in every sample program that i want to use.
They also have example in VB.6, when i try to run it, no problems at all. It works.
(i also put those 3 dcrf files in the %windows%\System32 folder).
But, when i try to build my own project with Visual Studio 2010 and using VB.NET programming language, i have a problem calling the dcrf32.dll file.
I migrate the VB6 source code to VB.NET, it has error when giving parameters to dc_init function.
Can anybody help me? Where is my fault?
Here are the links that important to solve my problems :
Here
I just need help with my first button, and you don't have to help me with the other button like in VB 6 example program.
I just wanna know how to connect the dcrf32 files, and why in VB.NET it has error but in VB 6 it works properly.
I wonder it.
The problem that you are having is dealing with your Declare Functions and the fact there are changes to the size of integers and longs etc. in VB.Net. Look at this Link and this Code Project Article on using PInvoke.
i.e. An Integer in VB6 is a Short in VB.Net, A Long in VB6 is an Integer in VB.Net. The % in your Declares is a VB6 Integer and will become a short.
Declare Auto Function dc_init Lib "dcrf32.dll" (ByVal port as Short, ByVal baud As Integer) As Integer
Declare Auto Function dc_exit Lib "dcrf32.dll" (ByVal icdev As Integer) As Short
Declare Auto Function dc_request Lib "dcrf32.dll" (ByVal icdev As Integer, ByVal mode as Short, tagtype As Integer) As Short
Declare Auto Function dc_anticoll Lib "dcrf32.dll" (ByVal icdev As Integer, ByVal bcnt as Short, snr As Integer) As Short
...
I have inherited a VB6 application from a friend of a family member, who wants to have some enhancements done to it.
I haven’t developed in VB for more than 3 years (I’m currently developing in MS Dynamics Ax).
I’ve recently upgraded my hardware and am now running Win7. The last time I worked with the app (about a year and a half ago) was on a WinXP platform, and everything worked fine. Now when I run the app (through code) on Win7, I get an error when trying to read from the registry.
Yes, I am running VB as administrator.
The code to read from the registry is:
Public Function sReadRegistry(ByVal hKeyRoot As Long, _
ByVal sSubKey As String, _
ByVal sValueName As String) As String
Dim r As Long
Dim sData As String * 255
Dim lDataSize As Long
Dim sTempVal As String
Dim readValue As String
lDataSize = 255
'Get the Value Requested
lDataSize = 255
r = VRegReadString(hKeyRoot, sSubKey, sValueName, sData, lDataSize)
If r Then
sTempVal = ""
Else
sTempVal = Left$(sData, lDataSize - 1)
End If
sReadRegistry = sTempVal
End Function
The “VRegReadString “ is declared within a module; and is declared as follows:
Declare Function VRegReadString Lib "VREG" (ByVal hKeyRoot As Long, ByVal sSubKey As String, ByVal sValueName As String, ByVal sData As String, ByRef lDataSize As Long) As Long
It complains about the “VREG” library…
The error I get is: “File not found: VREG”.
Is there a reference or component that I forgot to select? Can somebody please help with a solution?
Thanks in advance.
Seeing that the function declaration is an import from an external library called "VREG", you are probably missing the actual library itself, i.e. VREG.DLL. Unfortunately, this doesn't seem to be a common library, so you'd have to come up with it yourself.
Good news is, though, accessing the registry is not really hard and can be done with just the bare Windows API, especially seeing that VREG.DLL does not really seem to add a good deal of abstraction to the regular API. Take a look at these functions:
Registry Functions
...which you can use to easily re-write registry access, provided you fail to procure the needed DLL from somewhere.