I know we can find it using & in C/C++ or some way in C#. What is the way in VB.NET?
Actually, this answer can indeed make the VB5/VB6 VarPtr function available in VB.Net. Just fix the errors in the declaration. I tried using it with memcpy to copy Integers and it worked.
Declare Function VarPtr Lib "MSVBVM60.DLL" Alias "VarPtr" (ByRef Variable As Integer) As Integer
From MicroSoft Support i suggest a solution here:
Let a be an integer variable and address is a long variable which holds the address of a
Declare Function adresMemory Lib "msvbvm50.dll" Alias "VarPtr" _
(ByVal Var As Integer) As Long
Dim a As Integer = 10
Dim address As Long = adresMemory(a)'<------ address holds the address of variable a
Related
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 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)
The answer to my question may already be out there, but I am having no success synthesizing the data into a coherent solution. Your advice is appreciated.
I am writing a "User Control" application using Visual Basic (.NET 3.5) and Visual Studio 2012. I have been given a DLL file which contains functionality that I must access. Additionally, I have been given corresponding .LIB and .H files, which I am told will be necessary to properly make use of the DLL. I believe the DLL was written in C.
I have also been provided with some older VB code which is said to make use of the DLL's functions one that DLL is "included" (or something) in the project. As you can probably tell, my grasp on this is tenuous at best. Here is the VB code:
Private Declare Function SF_AddToCommandQueue Lib "SFrmUt80.dll" Alias "_SF_AddToCommandQueue#8" _
(ByVal CmdCode As Integer, ByVal strParam As String) As Boolean
Private Declare Function SF_FlushCommandQueue Lib "SFrmUt80.dll" Alias "_SF_FlushCommandQueue#4" _
(ByVal strWindowTitle As String) As Boolean
Private Declare Function SF_GetUserName Lib "SFrmUt80.dll" Alias "_SF_GetUserName#8" _
(ByVal strBuffer As String, ByVal BufferSize As Integer) As Integer
Private Declare Function SF_GetUserID Lib "SFrmUt80.dll" Alias "_SF_GetUserID#0" _
() As Integer
Private Declare Function SF_GetCmdType Lib "SFrmUt80.dll" Alias "_SF_GetCmdType#0" _
() As Integer
Private Declare Function SF_GetCmdFilename Lib "SFrmUt80.dll" Alias "_SF_GetCmdFilename#8" _
(ByVal strBuffer As String, ByVal BufferSize As Integer) As Integer
Private Declare Function SF_GetRegisteredMsg Lib "SFrmUt80.dll" Alias "_SF_GetRegisteredMsg#0" _
() As Integer
Hoping this is not too vague, I am wondering how I go about integrating this DLL file into my solution, so that I may make use of its functionality in VB .NET.
Your wisdom is very much appreciated. Thank you!
The .H-files won't be of much use to you, as you don't use them in the managed environment. You would actually just include the DLLs into your solution (i.e. add them to the project in the Solution-Explorer).
VS does the rest for you, all you need to do is, as you already did, declare the functions from the library in your source-code and call the functions.
On MSDN there is an article on this.
I have a vb6 project in which I use a dll library to do some tasks. For that, I add a module which declares all functions of that library such as:
Declare Function myFunction Lib "abcdapi.dll" (ByVal hVar1 As Long, ByVal hVar2 As Long) As Long
When I call this function (and many other similar) I'm able to do the work and correct Long pointer is returned. But when I try to do the same thing by VB.net (by importing the same library using dllimport and calling the same function), I get no result. although it does return some pointer but that doesn't produce correct result.
Private Const ABCD As String = "abcdapi.dll"
<DllImport(ABCD)>
Public Shared Function myFunction(ByVal hVar1 As IntPtr, ByVal hVar2 As IntPtr) As IntPtr
End Function
When I try to call the above function, it doesn't work. I even tried creating a dll in my vb6 project using the function and try to use imports keyword to call that new dll but that doesn't work either. What could be the issue and how do I make it work.
The docos you referenced show:
TM1IMPORT TM1_BOOL TM1API TM1ValBoolGet(TM1U hUser, TM1V vBool );
Is it possible that TM1U and TM1V are defined as 32 bit data types in that API and you are running your .NET code on a 64 bit machine, making your IntPtr a 64 bit data type? (If the API came with C header files you can see how those data types are defined). Try recompiling your .NET code to "x86" and try it again.
I just copied this code from your comment above:
the function call is below:
ibOK = TM1ValBoolGet(hUser, voTemp)
In VB.net: <<< I assume here you meant VB6
Declare Function TM1ValBoolGet Lib "tm1api.dll" (ByVal hUser As Long, ByVal vBool As Long) As Integer
In vb.net:
<DllImport(TM1APIDLL)> Public Shared Function TM1ValBoolGet(ByVal hUser As IntPtr, ByVal vBool As IntPtr) As Integer
End Function
It is probably a typo, but that return type in your VB6 is not the same as the one in VB.NET. A VB6 Integer is 16 bits and an Integer in VB.NET is 32 bits.