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
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
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 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
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.
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.