Unicode Ocx Vb6
2021年11月21日Download here: http://gg.gg/wz0a0
*Unicode Ocx Vb6 Keyboard
*Unicode Ocx Vb6 Font
May 23, 2012 Install MSHFLXGD.INF by right-clicking on it and pressing install. (This copies MSHFlxGd.ocx to c: windows system32) #4 didn’t register the OCX for me, so I manually called regsvr32 on the ocx. I’m not familiar with VB6, so that is just personal advice.Unicode Ocx Vb6 KeyboardNotes: This paper is presented here with the permission, and encouragement, of Microsoft. You may also download a Word Document version, if you’d prefer.
*Visual basic scrollbar control greece macro description sort responsible aide especially vb6 form skin ocx is cool button.ocx download. Investigate so that vb6-skin-ocx or beyond chief cooperate vessel cheer at that time elect reinstall but usercontrol.
*Hexagora Unicode Controls Internal Visual Basic 6.0 controls and classes are not Unicode. This is a big problem when you need to get Unicode data from people who use your programs (Chinese, Japanese, etc.). This library has been developed in order to fix VB6 Unicode limitations.
*Download vkUserControls (XP-Style OCX) for free. An ActiveX component (developed with Visual Basic 6.0) to use XP-style unicode controls for your VB applications: - 13 different graphical controls: ProgressBar, ListBox, TextBox. 3 other usefull controls: SysTray, Timer, MouseKeyEvents.Unicode Ocx Vb6 Font
VB5DLL.TXT Notes for Developing DLLs for use with Microsoft (R) Visual Basic (R) Version 5.00 (C) Copyright Microsoft Corporation, 1996
Contents 1 New Features 2 Calling Conventions 3 16/32-bit Conversion Issues 4 Passing and Returning Common Built-in Types 5 Passing and Returning Strings 6 Passing and Returning User-Defined Types 7 Passing and Returning Objects 8 Passing and Returning Arrays 9 Manipulating Variants 10 Passing Unicode Strings 11 Creating a Type Library 12 Compiling a 32-bit Unicode DLL 13 Creating a TypeLib For All The Functions In This Document 14 Additional Resources NOTE: The samples were created using VC++ 4.2, mktyplib version 2.03.3023. For older versions of VC++., you might need to include the header file ole2.h along with windows.h. 1: New Features * Ability to declare a parameter as an actual UDT type in a typelib. In prior versions, we had to use a declare statement. Refer to section 13 for more details. * Ability to declare void* as a parameter type in a typelib. Refer to section 13 for more details. 2: Calling Conventions Calling convention determines how arguments are passed onto the stack when a function is called and whether the caller or the called function cleans up the stack when the function returns. When using functions written in a different languages (C/C++, Fortran, etc...) with Visual Basic, it is important the dll functions are consistent with the Visual Basic convention. Visual Basic expects functions called from a dll to use the stdcall calling convention. For example in C/C++, you would specify that you want to use stdcall by specifying the identifier _stdcall in the function prototype and definition header. In Fortran, stdcall is the default. In Visual Basic 5.0, if you pass an argument ByVal by either specifying ByVal in the Declare statement or when calling the procedure, the actual value is passed on the stack.(the exception to the rule being the passing of strings, that are handled differently as detailed in section 5). However, if you don’t specify ByVal, a pointer to the value is passed on the stack. DLLs actually get loaded into memory only when a function in the DLL is called for the first time. 3: 16/32-bit Conversion Issues 1) Size of data types. Traditionally, in prior 16 bit versions of Visual Basic, if you needed a byte sized data type, you could use string*1. In Visual Basic 5.0, it is better to use the byte data type since string*1 is a Unicode string that takes 2 bytes. An integer in Visual Basic 5.0 still occupies 2 bytes. In contrast, an integer in a 32 bit DLL written in C/C++ occupies 4 bytes. If you need a 4 byte integer on the Visual Basic side, use a long data type. If you need a 2 byte integer on the C/C++ side use a short. 2) Calling functions from the Win32 API. In Win32, DLL procedure names are case-sensitive; In Win16, they are not. For example, this means that GetSystemMetrics and GETSYSTEMMETICS are distinct function names. However, in this case, only the former is correct as it exists in User32.dll. Now if the normal Declare Statement for this function: Declare Function GetSystemMetrics Lib ’User32’ (ByVal n As Integer) As Integer also exists somewhere else in the project, as say: (Say, the CAPSLOCK button accidentally goes ON when typing the function name) Declare Function GETSYSTEMMETRICS Lib ’User32’ (ByVal n As Integer) As Integer then, this will change the previous definition accordingly as well. This makes no difference on Win16 as function names are not case sensitive, but on Win32, a run-time error will occur because GETSYSTEMMETRICS does not exist in the DLL. To avoid this problem, it is recommended to use the Alias Clause as follows: Declare Function GetSystemMetrics Lib ’User32’ Alias GetSystemMetrics (ByVal n As Integer) As Integer By doing this, you make sure that the name used in the alias is not affected by a conversion (if any); so regardless of what case is used for the name in other parts of the code, the declaration will still refer to the correct procedure name in the DLL. 3) ANSI/UNICODE issues When converting a 16 bit DLL to a 32 bit DLL, perhaps one of the biggest concerns you will run into are the ANSI/UNICODE issues. When writing a DLL, you can consider an ANSI string as a one-byte-per-character string, and a UNICODE string as a two-byte-per-character string. Prior versions of Visual Basic 16 bit use either ANSI or DBCS strings. Visual Basic 5.0 uses UNICODE Strings. Because of this, there are some issues you need to be aware of when writing DLLs for use with Visual Basic 5.0. The 32-bit version of Visual Basic 5.0 maintains UNICODE strings internally. But whenever you pass a string to a DLL, Visual Basic will convert it to ANSI. If you do not want Visual Basic to convert your UNICODE string to ANSI, you should first place the string into a byte array, and then pass the address of the first element of the byte array. Note, however, that this is only true if you are using Declare statements for your DLL. If you create a type library, Visual Basic will use whatever type is indicated by the type library. Please refer to section 11 for more information on type libraries. 4) Exporting functions Normally when compiling 32-bit DLLs using a Microsoft Visual C++ compiler the _declspec keyword is used with the dllexport modifier attribute to enable you to export functions, data, and objects from a DLL. This attribute explicitly defines the DLL’s interface to its client, which can be an executable file or another DLL. Declaring functions as dllexport eliminates the need for a module-definition (.DEF) file, at least with respect to the specification of exported functions. dllexport replaces the _export keyword used earlier with 16-bit DLLs. However, when writing 32-bit DLLs that need to be called from Visual Basic 5.0, you need to export your function via the DEF file, by specifying all the function names with an EXPORTS statement. This is because the use of the stdcall calling convention mangles function names, which is the very nature of a C++ compiler, but VB does not understand mangled names. _declspec just puts it in the export table, but does not unmangle the function name. Even if you use a file with an extension of .C for your source code (so that the standard C compiler is used), you need to export functions using a DEF file. The following is an example of a typical DEF file: ; The DEF File LIBRARY vb5dll32 CODE PRELOAD MOVEABLE DISCARDABLE DATA PRELOAD MOVEABLE EXPORTS UpperCaseByRef @1 UpperCaseByVal @2 4: Passing and Returning Common Built-in Types The functions in this example demonstrate how to pass variables of common VB built-in types like Byte, Integer, Long, Boolean, Single and Double, both by value and by reference to a DLL, as well as how to return them. Each function, takes a variable of the type by value as its first parameter, and another variable of the same type by reference, as its second parameter. It assigns the byVal parameter to the byRef parameter (which is reflected back in VB), and then modifies the byVal parameter and returns it. #include <windows.h> #define CCONV _stdcall BYTE CCONV PassByte (BYTE byt, LPBYTE pbyt) { *pbyt = byt; return byt + 1; } short CCONV PassInteger (short intgr, short far *pintgr) { *pintgr = intgr; return intgr + 1; } short CCONV PassBoolean (short bln, short far *pbln) { *pbln = ~bln; return bln; } LONG CCONV PassLong (LONG lng, LPLONG plng) { *plng = lng; return lng + 1; } float CCONV PassSingle (float sng, float far *psng) { *psng = sng; return sng + (float)1.99; } double CCONV PassDouble (double dbl, double far *pdbl) { *pdbl = dbl; return dbl + 1.99; } Here is the DEF file. ;vb5dll32 DEF File LIBRARY vb5dll32 CODE PRELOAD MOVEABLE DISCARDABLE DATA PRELOAD MOVEABLE EXPORTS PassByte PassInteger PassBoolean PassLong PassSingle PassDouble The following Visual Basic code calls the above functions: Private Declare Function PassByte Lib ’vb5dll32.dll’ (ByVal byt As Byte, pbyt As Byte) As Byte Private Declare Function PassInteger Lib ’vb5dll32.dll’ (ByVal intgr As Integer, pintgr As Integer) As Integer Private Declare Function PassBoolean Lib ’vb5dll32.dll’ (ByVal bln As Boolean, pbln As Boolean) As Boolean Private Declare Function PassLong Lib ’vb5dll32.dll’ (ByVal lng As Long, plng As Long) As Long Private Declare Function PassSingle Lib ’vb5dll32.dll’ (ByVal sng As Single, psng As Single) As Single Private Declare Function PassDouble Lib ’vb5dll32.dll’ (ByVal dbl As Double, pdbl As Double) As Double Private Sub BuiltIntest() Dim i As Integer, b As Boolean, c As Byte Dim l As Long, s As Single, d As Double Dim ir As Integer, br As Boolean, cr As Byte Dim lr As Long, sr As Single, dr As Double i = 7 b = True c = Asc(’R’) l = 77 s = 0.7 d = 7.77 i = PassInteger(i, ir) Print i, ir b = PassBoolean(b, br) Print b, br c = PassByte(c, cr) Print Chr$(c), Chr$(cr) l = PassLong(l, lr) Print l, lr s = PassSingle(s, sr) Print s, sr d = PassDouble(d, dr) Print d, dr End Sub 5: Passing and Returning Strings Visual Basic maintains variable-length strings internally as BSTRs. BSTRs are defined in the OLE header files as OLECHAR FAR*. An OLECHAR is a UNICODE character in 32-bit OLE and an ANSI character in 16-bit OLE. A BSTR can contain NULL values because a length is also maintained with the BSTR. BSTRs are also NULL terminated so they can be treated as an LPSTR. Currently this length is stored immediately prior to the string. This may change in the future, however, so you should use the OLE APIs to access the string length. A subtle point is if you use a declare statement as opposed to a typelib in VB, the string is NOT coerced into an ANSI string. It is left as a UNICODE string. If you use a declare statement, then the string passed is coerced into an ANSI string. In the below example, please pay special attention to the comments. Please refer to section 10 for more information. You can pass a string from Visual Basic to a DLL in one of two ways. You can pass it ’by value’ (ByVal) or ’by reference’. When you pass a string ByVal, Visual Basic passes a pointer to the beginning of the string data (i.e. it passes a BSTR). When a string is passed by reference, Visual Basic passes a pointer to a pointer to the string data (i.e. it passes a BSTR*). Since VB coerces the UNICODE string to ANSI, it allocates temporary memory to store the ANSI string. VB recopies the UNICODE version of the string back to the passed in variable. The following table lists what Visual Basic will pass to a DLL function when passing a string. Version By Value By Reference ------------------------------------ 3.0 LPSTR HLSTR 4.0 BSTR BSTR* 5.0 BSTR BSTR* In Visual Basic 3.0, you could use the Visual Basic API routines to access and modify an HLSTR. In Visual Basic 5.0 you should use the OLE APIs to access a BSTR. The following table lists the Visual Basic 3.0 string-handling APIs, and the OLE equivalents. Visual Basic API OLE API -------------------------------------------------------- VBCreateHlstr SysAllocString/SysAllocStringLen VBCreateTempHlstr SysAllocString/SysAllocStringLen VBDerefHlstr* N/A VBDerefHlstrLen* N/A VBDerefZeroTermHlstr N/A VBDestroyHlstr SysFreeString VBGetHlstrLen SysStringLen VBResizeHlstr SysReAllocStringLen VBSetHlstr SysReAllocString NOTE: The BSTR is a pointer to the string, so you don’t need to dereference it. Example ------- The first function in this example takes a Visual Basic string by reference, and returns an uppercase copy of the string. The second function takes a Visual Basic string by value and also returns an uppercase copy of the string. This is similar to the UCase function in Visual Basic. In both cases, the DLL function modifies the passed string, which is reflected back in VB. This happens even when the VB string is passed ’ByVal’ because what is passed to the DLL function is a BSTR which is a char far*, and thus, it is possible to directly access the memory buffer pointed to by the BSTR. The DEF file is not included. #include <windows.h> #define CCONV _stdcall BSTR CCONV UpperCaseByRef(BSTR *pbstrOriginal) { BSTR bstrUpperCase; int i; int cbOriginalLen; LPSTR strSrcByRef, strDst; cbOriginalLen = SysStringByteLen(*pbstrOriginal); //We are planning to return bstrUpperCase if we are using a declare //statement, we need to use SysAllocStringByteLen instead of SysAllocStringLen //because of the coercion of ansi back to a unicode string on return of the //function. See Note #1 below. bstrUpperCase = SysAllocStringByteLen(NULL, cbOriginalLen); strSrcByRef = (LPSTR)*pbstrOriginal; strDst = (LPSTR)bstrUpperCase; for(i=0; i<=cbOriginalLen; i++) *strDst++ = toupper(*strSrcByRef++); SysReAllocString (pbstrOriginal, (BSTR)’Good Bye’); //On return of this function, bstrUpperCase will be coerced back to //a Unicode string if we are using a declare statement instead of a //typelib. See Note #1 below. return bstrUpperCase; } BSTR CCONV UpperCaseByVal(BSTR bstrOriginal) { BSTR bstrUpperCase; int i; int cbOriginalLen; LPSTR strSrcByVal, strDst; cbOriginalLen = SysStringByteLen(bstrOriginal); //We are planning to return bstrUpperCase if we are using a declare //statement, we need to use SysAllocStringByteLen instead of SysAllocStringLen //because of the coercion of ansi back to a unicode string on return of the //function. See Note #1 below. bstrUpperCase = SysAllocStringByteLen(NULL, cbOriginalLen); strSrcByVal = (LPSTR)bstrOriginal; strDst = (LPSTR)bstrUpperCase; for(i=0; i<=cbOriginalLen; i++) *strDst++ = toupper(*strSrcByVal++); SysReAllocString (&bstrOriginal, (BSTR)’Good Bye’); //On return of this function, bstrUpperCase will be coerced back to //a Unicode string if we are using a declare statement instead of a //typelib. See Note #1 below return bstrUpperCase; } The following Visual Basic code calls the above two UpperCase functions: Private Declare Function UpperCaseByRef Lib ’vb5dll32.dll’ (Str As String) As String Private Declare Function UpperCaseByVal Lib ’vb5dll32.dll’ (ByVal Str As String) As String Private Sub StringTest () Dim Str As String, NewStr As String Str = ’Hello World!’ MsgBox ’In VB, Before: ’ & Str NewStr = UpperCaseByRef(Str) MsgBox ’In VB, After: ’ & Str MsgBox ’In VB, CapsStr: ’ & NewStr Str = ’Hello World!’ MsgBox ’In VB, Before: ’ & Str NewStr = UpperCaseByVal(Str) MsgBox ’In VB, After: ’ & Str MsgBox ’In VB, CapsStr: ’ & NewStr End Sub Note #1: As an example, if we pass in the string ’abs’ and we used SysAllocStringLen, then it would allocate a string of length 6. On return of the function, it will coerce the string into Unicode also changing the prefixed length of the BSTR to 12 which is double the amount, therefore we would get a larger string and potential garbage characters. By using SysAllocStringByteLen, it allocates a string of length 3. On return, it coerces the ANSI string back to Unicode string of the proper length 6. 6: Passing and Returning User-Defined Types With Visual Basic 5.0, you can pass a user-defined type (UDT) by reference to a function. In addition to this, Visual Basic 5.0 also allows functions to return a user-defined type. You still cannot pass a UDT by value to a DLL function. A user-defined type is returned in the same way it would be with any other function, as demonstrated in code example below. It is important to make sure that the UDT as defined in Visual Basic is the same size as the C structure defined in the DLL by enforcing a strict one-to-one alignment of corresponding members in both UDTs. This can be a problem because VB5 uses dword (4-byte) alignment; while the DLL uses the ’Struct Member Alignment’ Compiler Option as specified by the program developer. Thus, an odd-sized string in VB may cause this problem. In a 32-bit Application, it is efficientoptimal to use a 4-byte Struct Member Alignment, which is what VB uses. In the 32 bit dll, please make sure that you select the 4-byte struct member alignment compiler setting. If you need to call a DLL function that takes a C struct by reference from VB, you should keep in mind a simple rule while designing its counterpart UDT in VB. The rule is that if the size of the struct member is less than the ’Struct Member Alignment’ size and if the next member can fit in the same alignment size then they will be packed together. Thus, the order in which the members are declared inside a struct is also important. For instance, in the example below, the ’byt’ member is packed together with the ’bln’ member because of the above rule and it is followed by a 1 byte padding because the next member which is a VARIANT structure is 16 bytes, which is greater than the 4 byte struct alignment size being used. However, if the location of the ’vnt’ member and the ’strg’ member were swapped, then there would be no padding and the 11 character of ’strg’ would occupy consequent memory locations immediately after the ’byt’ member. This is because the size of a char is 1 byte which is less than the alignment size of 4. Please refer to section 14 on other references that talk about structure padding. As already mentioned in section 3, another thing to keep in mind is that an integer in VB is always 2 bytes, whereas an ’int’ in C is 4 bytes on Win32, but 2 bytes on Win16. So, on Win32, this might pose a problem when using an array of integers in VB. The corresponding array of ’int’s in C will take up 2 extra bytes and a huge amount of padding may be required in the VB UDT. Hence a short is used, which is 2 bytes (on both win16 and win32). If the C type is int then the VB type will have to change from an integer to a long when going from 16 to 32 bits. Otherwise, if short and long are used in C, then the correspon
https://diarynote.indered.space
*Unicode Ocx Vb6 Keyboard
*Unicode Ocx Vb6 Font
May 23, 2012 Install MSHFLXGD.INF by right-clicking on it and pressing install. (This copies MSHFlxGd.ocx to c: windows system32) #4 didn’t register the OCX for me, so I manually called regsvr32 on the ocx. I’m not familiar with VB6, so that is just personal advice.Unicode Ocx Vb6 KeyboardNotes: This paper is presented here with the permission, and encouragement, of Microsoft. You may also download a Word Document version, if you’d prefer.
*Visual basic scrollbar control greece macro description sort responsible aide especially vb6 form skin ocx is cool button.ocx download. Investigate so that vb6-skin-ocx or beyond chief cooperate vessel cheer at that time elect reinstall but usercontrol.
*Hexagora Unicode Controls Internal Visual Basic 6.0 controls and classes are not Unicode. This is a big problem when you need to get Unicode data from people who use your programs (Chinese, Japanese, etc.). This library has been developed in order to fix VB6 Unicode limitations.
*Download vkUserControls (XP-Style OCX) for free. An ActiveX component (developed with Visual Basic 6.0) to use XP-style unicode controls for your VB applications: - 13 different graphical controls: ProgressBar, ListBox, TextBox. 3 other usefull controls: SysTray, Timer, MouseKeyEvents.Unicode Ocx Vb6 Font
VB5DLL.TXT Notes for Developing DLLs for use with Microsoft (R) Visual Basic (R) Version 5.00 (C) Copyright Microsoft Corporation, 1996
Contents 1 New Features 2 Calling Conventions 3 16/32-bit Conversion Issues 4 Passing and Returning Common Built-in Types 5 Passing and Returning Strings 6 Passing and Returning User-Defined Types 7 Passing and Returning Objects 8 Passing and Returning Arrays 9 Manipulating Variants 10 Passing Unicode Strings 11 Creating a Type Library 12 Compiling a 32-bit Unicode DLL 13 Creating a TypeLib For All The Functions In This Document 14 Additional Resources NOTE: The samples were created using VC++ 4.2, mktyplib version 2.03.3023. For older versions of VC++., you might need to include the header file ole2.h along with windows.h. 1: New Features * Ability to declare a parameter as an actual UDT type in a typelib. In prior versions, we had to use a declare statement. Refer to section 13 for more details. * Ability to declare void* as a parameter type in a typelib. Refer to section 13 for more details. 2: Calling Conventions Calling convention determines how arguments are passed onto the stack when a function is called and whether the caller or the called function cleans up the stack when the function returns. When using functions written in a different languages (C/C++, Fortran, etc...) with Visual Basic, it is important the dll functions are consistent with the Visual Basic convention. Visual Basic expects functions called from a dll to use the stdcall calling convention. For example in C/C++, you would specify that you want to use stdcall by specifying the identifier _stdcall in the function prototype and definition header. In Fortran, stdcall is the default. In Visual Basic 5.0, if you pass an argument ByVal by either specifying ByVal in the Declare statement or when calling the procedure, the actual value is passed on the stack.(the exception to the rule being the passing of strings, that are handled differently as detailed in section 5). However, if you don’t specify ByVal, a pointer to the value is passed on the stack. DLLs actually get loaded into memory only when a function in the DLL is called for the first time. 3: 16/32-bit Conversion Issues 1) Size of data types. Traditionally, in prior 16 bit versions of Visual Basic, if you needed a byte sized data type, you could use string*1. In Visual Basic 5.0, it is better to use the byte data type since string*1 is a Unicode string that takes 2 bytes. An integer in Visual Basic 5.0 still occupies 2 bytes. In contrast, an integer in a 32 bit DLL written in C/C++ occupies 4 bytes. If you need a 4 byte integer on the Visual Basic side, use a long data type. If you need a 2 byte integer on the C/C++ side use a short. 2) Calling functions from the Win32 API. In Win32, DLL procedure names are case-sensitive; In Win16, they are not. For example, this means that GetSystemMetrics and GETSYSTEMMETICS are distinct function names. However, in this case, only the former is correct as it exists in User32.dll. Now if the normal Declare Statement for this function: Declare Function GetSystemMetrics Lib ’User32’ (ByVal n As Integer) As Integer also exists somewhere else in the project, as say: (Say, the CAPSLOCK button accidentally goes ON when typing the function name) Declare Function GETSYSTEMMETRICS Lib ’User32’ (ByVal n As Integer) As Integer then, this will change the previous definition accordingly as well. This makes no difference on Win16 as function names are not case sensitive, but on Win32, a run-time error will occur because GETSYSTEMMETRICS does not exist in the DLL. To avoid this problem, it is recommended to use the Alias Clause as follows: Declare Function GetSystemMetrics Lib ’User32’ Alias GetSystemMetrics (ByVal n As Integer) As Integer By doing this, you make sure that the name used in the alias is not affected by a conversion (if any); so regardless of what case is used for the name in other parts of the code, the declaration will still refer to the correct procedure name in the DLL. 3) ANSI/UNICODE issues When converting a 16 bit DLL to a 32 bit DLL, perhaps one of the biggest concerns you will run into are the ANSI/UNICODE issues. When writing a DLL, you can consider an ANSI string as a one-byte-per-character string, and a UNICODE string as a two-byte-per-character string. Prior versions of Visual Basic 16 bit use either ANSI or DBCS strings. Visual Basic 5.0 uses UNICODE Strings. Because of this, there are some issues you need to be aware of when writing DLLs for use with Visual Basic 5.0. The 32-bit version of Visual Basic 5.0 maintains UNICODE strings internally. But whenever you pass a string to a DLL, Visual Basic will convert it to ANSI. If you do not want Visual Basic to convert your UNICODE string to ANSI, you should first place the string into a byte array, and then pass the address of the first element of the byte array. Note, however, that this is only true if you are using Declare statements for your DLL. If you create a type library, Visual Basic will use whatever type is indicated by the type library. Please refer to section 11 for more information on type libraries. 4) Exporting functions Normally when compiling 32-bit DLLs using a Microsoft Visual C++ compiler the _declspec keyword is used with the dllexport modifier attribute to enable you to export functions, data, and objects from a DLL. This attribute explicitly defines the DLL’s interface to its client, which can be an executable file or another DLL. Declaring functions as dllexport eliminates the need for a module-definition (.DEF) file, at least with respect to the specification of exported functions. dllexport replaces the _export keyword used earlier with 16-bit DLLs. However, when writing 32-bit DLLs that need to be called from Visual Basic 5.0, you need to export your function via the DEF file, by specifying all the function names with an EXPORTS statement. This is because the use of the stdcall calling convention mangles function names, which is the very nature of a C++ compiler, but VB does not understand mangled names. _declspec just puts it in the export table, but does not unmangle the function name. Even if you use a file with an extension of .C for your source code (so that the standard C compiler is used), you need to export functions using a DEF file. The following is an example of a typical DEF file: ; The DEF File LIBRARY vb5dll32 CODE PRELOAD MOVEABLE DISCARDABLE DATA PRELOAD MOVEABLE EXPORTS UpperCaseByRef @1 UpperCaseByVal @2 4: Passing and Returning Common Built-in Types The functions in this example demonstrate how to pass variables of common VB built-in types like Byte, Integer, Long, Boolean, Single and Double, both by value and by reference to a DLL, as well as how to return them. Each function, takes a variable of the type by value as its first parameter, and another variable of the same type by reference, as its second parameter. It assigns the byVal parameter to the byRef parameter (which is reflected back in VB), and then modifies the byVal parameter and returns it. #include <windows.h> #define CCONV _stdcall BYTE CCONV PassByte (BYTE byt, LPBYTE pbyt) { *pbyt = byt; return byt + 1; } short CCONV PassInteger (short intgr, short far *pintgr) { *pintgr = intgr; return intgr + 1; } short CCONV PassBoolean (short bln, short far *pbln) { *pbln = ~bln; return bln; } LONG CCONV PassLong (LONG lng, LPLONG plng) { *plng = lng; return lng + 1; } float CCONV PassSingle (float sng, float far *psng) { *psng = sng; return sng + (float)1.99; } double CCONV PassDouble (double dbl, double far *pdbl) { *pdbl = dbl; return dbl + 1.99; } Here is the DEF file. ;vb5dll32 DEF File LIBRARY vb5dll32 CODE PRELOAD MOVEABLE DISCARDABLE DATA PRELOAD MOVEABLE EXPORTS PassByte PassInteger PassBoolean PassLong PassSingle PassDouble The following Visual Basic code calls the above functions: Private Declare Function PassByte Lib ’vb5dll32.dll’ (ByVal byt As Byte, pbyt As Byte) As Byte Private Declare Function PassInteger Lib ’vb5dll32.dll’ (ByVal intgr As Integer, pintgr As Integer) As Integer Private Declare Function PassBoolean Lib ’vb5dll32.dll’ (ByVal bln As Boolean, pbln As Boolean) As Boolean Private Declare Function PassLong Lib ’vb5dll32.dll’ (ByVal lng As Long, plng As Long) As Long Private Declare Function PassSingle Lib ’vb5dll32.dll’ (ByVal sng As Single, psng As Single) As Single Private Declare Function PassDouble Lib ’vb5dll32.dll’ (ByVal dbl As Double, pdbl As Double) As Double Private Sub BuiltIntest() Dim i As Integer, b As Boolean, c As Byte Dim l As Long, s As Single, d As Double Dim ir As Integer, br As Boolean, cr As Byte Dim lr As Long, sr As Single, dr As Double i = 7 b = True c = Asc(’R’) l = 77 s = 0.7 d = 7.77 i = PassInteger(i, ir) Print i, ir b = PassBoolean(b, br) Print b, br c = PassByte(c, cr) Print Chr$(c), Chr$(cr) l = PassLong(l, lr) Print l, lr s = PassSingle(s, sr) Print s, sr d = PassDouble(d, dr) Print d, dr End Sub 5: Passing and Returning Strings Visual Basic maintains variable-length strings internally as BSTRs. BSTRs are defined in the OLE header files as OLECHAR FAR*. An OLECHAR is a UNICODE character in 32-bit OLE and an ANSI character in 16-bit OLE. A BSTR can contain NULL values because a length is also maintained with the BSTR. BSTRs are also NULL terminated so they can be treated as an LPSTR. Currently this length is stored immediately prior to the string. This may change in the future, however, so you should use the OLE APIs to access the string length. A subtle point is if you use a declare statement as opposed to a typelib in VB, the string is NOT coerced into an ANSI string. It is left as a UNICODE string. If you use a declare statement, then the string passed is coerced into an ANSI string. In the below example, please pay special attention to the comments. Please refer to section 10 for more information. You can pass a string from Visual Basic to a DLL in one of two ways. You can pass it ’by value’ (ByVal) or ’by reference’. When you pass a string ByVal, Visual Basic passes a pointer to the beginning of the string data (i.e. it passes a BSTR). When a string is passed by reference, Visual Basic passes a pointer to a pointer to the string data (i.e. it passes a BSTR*). Since VB coerces the UNICODE string to ANSI, it allocates temporary memory to store the ANSI string. VB recopies the UNICODE version of the string back to the passed in variable. The following table lists what Visual Basic will pass to a DLL function when passing a string. Version By Value By Reference ------------------------------------ 3.0 LPSTR HLSTR 4.0 BSTR BSTR* 5.0 BSTR BSTR* In Visual Basic 3.0, you could use the Visual Basic API routines to access and modify an HLSTR. In Visual Basic 5.0 you should use the OLE APIs to access a BSTR. The following table lists the Visual Basic 3.0 string-handling APIs, and the OLE equivalents. Visual Basic API OLE API -------------------------------------------------------- VBCreateHlstr SysAllocString/SysAllocStringLen VBCreateTempHlstr SysAllocString/SysAllocStringLen VBDerefHlstr* N/A VBDerefHlstrLen* N/A VBDerefZeroTermHlstr N/A VBDestroyHlstr SysFreeString VBGetHlstrLen SysStringLen VBResizeHlstr SysReAllocStringLen VBSetHlstr SysReAllocString NOTE: The BSTR is a pointer to the string, so you don’t need to dereference it. Example ------- The first function in this example takes a Visual Basic string by reference, and returns an uppercase copy of the string. The second function takes a Visual Basic string by value and also returns an uppercase copy of the string. This is similar to the UCase function in Visual Basic. In both cases, the DLL function modifies the passed string, which is reflected back in VB. This happens even when the VB string is passed ’ByVal’ because what is passed to the DLL function is a BSTR which is a char far*, and thus, it is possible to directly access the memory buffer pointed to by the BSTR. The DEF file is not included. #include <windows.h> #define CCONV _stdcall BSTR CCONV UpperCaseByRef(BSTR *pbstrOriginal) { BSTR bstrUpperCase; int i; int cbOriginalLen; LPSTR strSrcByRef, strDst; cbOriginalLen = SysStringByteLen(*pbstrOriginal); //We are planning to return bstrUpperCase if we are using a declare //statement, we need to use SysAllocStringByteLen instead of SysAllocStringLen //because of the coercion of ansi back to a unicode string on return of the //function. See Note #1 below. bstrUpperCase = SysAllocStringByteLen(NULL, cbOriginalLen); strSrcByRef = (LPSTR)*pbstrOriginal; strDst = (LPSTR)bstrUpperCase; for(i=0; i<=cbOriginalLen; i++) *strDst++ = toupper(*strSrcByRef++); SysReAllocString (pbstrOriginal, (BSTR)’Good Bye’); //On return of this function, bstrUpperCase will be coerced back to //a Unicode string if we are using a declare statement instead of a //typelib. See Note #1 below. return bstrUpperCase; } BSTR CCONV UpperCaseByVal(BSTR bstrOriginal) { BSTR bstrUpperCase; int i; int cbOriginalLen; LPSTR strSrcByVal, strDst; cbOriginalLen = SysStringByteLen(bstrOriginal); //We are planning to return bstrUpperCase if we are using a declare //statement, we need to use SysAllocStringByteLen instead of SysAllocStringLen //because of the coercion of ansi back to a unicode string on return of the //function. See Note #1 below. bstrUpperCase = SysAllocStringByteLen(NULL, cbOriginalLen); strSrcByVal = (LPSTR)bstrOriginal; strDst = (LPSTR)bstrUpperCase; for(i=0; i<=cbOriginalLen; i++) *strDst++ = toupper(*strSrcByVal++); SysReAllocString (&bstrOriginal, (BSTR)’Good Bye’); //On return of this function, bstrUpperCase will be coerced back to //a Unicode string if we are using a declare statement instead of a //typelib. See Note #1 below return bstrUpperCase; } The following Visual Basic code calls the above two UpperCase functions: Private Declare Function UpperCaseByRef Lib ’vb5dll32.dll’ (Str As String) As String Private Declare Function UpperCaseByVal Lib ’vb5dll32.dll’ (ByVal Str As String) As String Private Sub StringTest () Dim Str As String, NewStr As String Str = ’Hello World!’ MsgBox ’In VB, Before: ’ & Str NewStr = UpperCaseByRef(Str) MsgBox ’In VB, After: ’ & Str MsgBox ’In VB, CapsStr: ’ & NewStr Str = ’Hello World!’ MsgBox ’In VB, Before: ’ & Str NewStr = UpperCaseByVal(Str) MsgBox ’In VB, After: ’ & Str MsgBox ’In VB, CapsStr: ’ & NewStr End Sub Note #1: As an example, if we pass in the string ’abs’ and we used SysAllocStringLen, then it would allocate a string of length 6. On return of the function, it will coerce the string into Unicode also changing the prefixed length of the BSTR to 12 which is double the amount, therefore we would get a larger string and potential garbage characters. By using SysAllocStringByteLen, it allocates a string of length 3. On return, it coerces the ANSI string back to Unicode string of the proper length 6. 6: Passing and Returning User-Defined Types With Visual Basic 5.0, you can pass a user-defined type (UDT) by reference to a function. In addition to this, Visual Basic 5.0 also allows functions to return a user-defined type. You still cannot pass a UDT by value to a DLL function. A user-defined type is returned in the same way it would be with any other function, as demonstrated in code example below. It is important to make sure that the UDT as defined in Visual Basic is the same size as the C structure defined in the DLL by enforcing a strict one-to-one alignment of corresponding members in both UDTs. This can be a problem because VB5 uses dword (4-byte) alignment; while the DLL uses the ’Struct Member Alignment’ Compiler Option as specified by the program developer. Thus, an odd-sized string in VB may cause this problem. In a 32-bit Application, it is efficientoptimal to use a 4-byte Struct Member Alignment, which is what VB uses. In the 32 bit dll, please make sure that you select the 4-byte struct member alignment compiler setting. If you need to call a DLL function that takes a C struct by reference from VB, you should keep in mind a simple rule while designing its counterpart UDT in VB. The rule is that if the size of the struct member is less than the ’Struct Member Alignment’ size and if the next member can fit in the same alignment size then they will be packed together. Thus, the order in which the members are declared inside a struct is also important. For instance, in the example below, the ’byt’ member is packed together with the ’bln’ member because of the above rule and it is followed by a 1 byte padding because the next member which is a VARIANT structure is 16 bytes, which is greater than the 4 byte struct alignment size being used. However, if the location of the ’vnt’ member and the ’strg’ member were swapped, then there would be no padding and the 11 character of ’strg’ would occupy consequent memory locations immediately after the ’byt’ member. This is because the size of a char is 1 byte which is less than the alignment size of 4. Please refer to section 14 on other references that talk about structure padding. As already mentioned in section 3, another thing to keep in mind is that an integer in VB is always 2 bytes, whereas an ’int’ in C is 4 bytes on Win32, but 2 bytes on Win16. So, on Win32, this might pose a problem when using an array of integers in VB. The corresponding array of ’int’s in C will take up 2 extra bytes and a huge amount of padding may be required in the VB UDT. Hence a short is used, which is 2 bytes (on both win16 and win32). If the C type is int then the VB type will have to change from an integer to a long when going from 16 to 32 bits. Otherwise, if short and long are used in C, then the correspon
https://diarynote.indered.space
コメント