| C H A P T E R 10 | Part 3 Upgrading to Microsoft Office | Microsoft Office Resource Kit |
| Upgrading from Previous Versions of Microsoft Office |
|
|
This chapter tells you what to expect when you or your workgroup upgrades from a previous version of Microsoft Office.
The remaining chapters in Part 3, "Upgrading to Microsoft Office," provide detailed information about upgrading from individual Office 97 and Office 98 applications.
|
|
Note Exchange Client users cannot use Outlook views, custom forms, or custom commands.
To continue sharing information with Exchange Client users, Outlook users can:
For more information about using Outlook as your email client, see Chapter 13, "Upgrading to Microsoft Outlook."
Upgrading Your Office 95 Scheduling Application
Note Schedule+ 95 users cannot open or read an Outlook calendar file and they cannot view an Outlook user's free/busy details.
To continue sharing information with Schedule+ 95 users, Outlook users can:
For more information about using Outlook as your scheduling application, see Chapter 13, "Upgrading to Microsoft Outlook."
The Office Binder application included in Office 97 can open Office 95 binders, but it cannot save in Office 95 Binder format. Nor can Office 97 binder sections be moved to Office 95 binders.
Office 97 binder documents are not supported by previous versions of Office for Windows. If you want to work with binder documents on a computer running a previous version of Office for Windows, you must first unbind the binder into its component sections.
To
unbind sections in a binder (Windows 95 or Windows NT
Workstation 4.0 only)
The sections in the binder document are saved as separate files in the folder that contains the binder. The original binder remains intact.
Note The Unbind command is not available in Windows NT Workstation 3.51 or Windows 3.x.
To
unbind sections in a binder (Windows NT Workstation 3.51
only)
The sections in the binder document are saved as separate files in the folder that contains the binder. The original binder remains intact.
 | Tools and Utilities The Office Resource Kit Tools and Utilities include the Unbind utility for Windows 3.x. For more information about installing this utility, see "Office 97 Unbind Utilities" in Appendix A, "Microsoft Office Resource Kit Tools and Utilities." |
| | Note The Office 98 Value Pack for the Macintosh includes the Unbind Utility that separates Office 97 binders into their component files. You must install the Unbind Utility from the Office 98 Value Pack. For more information about the Value Pack, see "Installing Value Pack Components" in Chapter 4, "Installing Microsoft Office." |
|
For more information about using Outlook as your email client, see Chapter 13, "Upgrading to Microsoft Outlook."
Upgrading Your Office 4.x for the Macintosh Electronic Mail Client
 | Small, fast, and simply designed, Microsoft Outlook Express version 4.0 for the Macintosh represents a major step forward in Internet communication. Outlook Express can replace Microsoft Internet Mail and News for the Macintosh, the e-mail application included with Microsoft Internet Explorer version 3.01, which shipped in Office 4.x. When your workgroup upgrades to Outlook Express, users can continue sharing information with Internet Mail and News users. Outlook Express users can: |
For more information about using Outlook Express as your e-mail client, see Chapter 19, "Switching to Microsoft Outlook."
Upgrading Microsoft Office Manager for Windows
 | In Office 95 for Windows, the Office Shortcut Bar replaced the Microsoft Office Manager from Office 4.x. Office 97 includes an updated Office Shortcut Bar. |
|
|
Which API Should Your Solution Code Call?
When you write solution code for your own use, you write it for the version of the Office application you have and for your operating system. Distributing this solution to others, however, means that you have to make it also work on their computers, which may use different versions of Windows and Office applications.
While the operating system isn't an issue, whether the Office application is 16bit or 32bit is important. The application, and not the operating system, determines which API you use in porting your solution code: you must use 16bit APIs with 16bit applications, and 32bit APIs with 32bit applications.
Note Office (including 32bit Access and 32bit Microsoft Project) products do not run on Win32s®. Because FoxPro does run on this operating system, however, FoxPro programmers should use the same rules for choosing the API. Also, the Win32s, Windows NT, and Windows 95 operating systems do not have identical sets of API calls. For more information, see the Win32 SDK documentation in the Development Library (in particular, see the Compatibility Tables in the Win32 Programmer's Reference, Vol. 5).
To write calls to the Win32 API, you must do the following:
What Is an API Call?
An API call in C, Visual Basic, or other languages places a series of values (parameters) at a location in memory (the stack) and then requests the operating system or DLL to execute a function (the procedure call) using the values provided. The function reads the values (call stack) and executes its function code using those values or the data that the values point to.
If a result is returned, it is placed at another location (return register) for the calling application to use. This is shown in the following illustration. To ensure accuracy, the number of bytes of data on the stack is verified before and after the procedure is called. The message "Bad DLL calling convention" appears when the wrong number of bytes are in the stack.
In practical terms, Windows API calls are how applications request
services (screen control, printers, memory, and so forth) from
the operating system. There are approximately 300 API calls in
Windows 3.0, over 700 API calls in Windows 3.1, and over
1,000 API calls in Windows 95. These API calls are packaged
in executable files and DLLs found in the Windows folder —
User.exe, Gdi.exe, and one of the following
KERNEL files:
Krnl286.exe, Krnl386.exe, or Kernel32.dll.
To call an API from your solution code, use these four steps:
The following is a simple example for the GetVersion API
call that obtains the version of Windows that is running. The
GetVersion API call is located in KERNEL under 16bit
Windows and does not use any parameters (so the Declare
statement has empty parentheses). The following Declare
statement is written for 16bit Windows for use by Visual
Basic for Applications:
By comparison, here is the same function as it would be used by
an Office 97 application running on 32bit Windows:
Declare Function GetVersion Lib "KERNEL" () As Long
Although the Windows API name stays the same, the location of
the API has changed to KERNEL32. Because you are calling
from a 32bit application, you must make a 32bit API
call. The parameter data type, on the other hand, did not change
(it remained a Long). In general, the function parameters
change more and require more attention than the parameters of
the return value. Understanding the differences between 16bit
API calls and 32bit API calls is essential to porting your
solution code to Windows 95.
Declare Function GetVersion Lib "KERNEL32" () As Long
What Are the Differences Between a 16bit and a 32bit Windows API?
As shown in the previous example, most 32bit Windows API calls have the same name or a very similar name to the 16bit API calls. In fact, the documentation may show the same arguments, with the only apparent difference being the library name change from KERNEL to KERNEL32. However, the code must handle the following changes in addition to the name change:
Case Sensitivity
The first issue in moving to 32bit Windows API calls is
case sensitivity in the name of the function. API calls under
16bit Windows are not case sensitive and work if you enter
the function name as GetVERSION, GeTvErSiOn, or
getversion. In other words, in 16bit Windows the
following statements are equivalent:
Declare Function GetVersion Lib "KERNEL" () As Long
Declare Function GeTvErSiOn Lib "KERNEL" () As Long
API calls under 32bit Windows, however, are casesensitive
for the function call and must be correctly entered in the Declare
statement. In other words, the following statements are not equivalent
in 32bit Windows:
Declare Function GetVersion Lib "KERNEL32" () As Long
Declare Function GeTvErSiOn Lib "KERNEL32" () As Long
The easiest way to handle this change is to always use the Alias
control word. The contents of an Alias string map to the
actual API call name (which is case sensitive), but the function
name used in code, which appears between Function
and Lib, is
not case sensitive and does not change if you type it different
ways in your code or use the same name for variables or procedures.
Using the Alias control word, the GetVersion function
(32bit Windows) would be entered as:
Declare Function GetVersion Lib "KERNEL32" Alias "GetVersion" () As Long
The case of API names doesn't matter when writing code: as long as you enter the function name correctly in the Alias string, and you spell the function name in code the same way as in the Declare statement, the function is automatically mapped by Visual Basic or Visual Basic for Applications back to the correct Declare function.
Note The Alias control word is the single most important thing you can use in preparing to switch to 32bit operating systems because it means you only have to change the contents of the Declare statement and not every instance of the function being called in your code.
Unicode or ANSI Options
Both the Windows NT and Windows 95 operating systems have two API interfaces. One interface is based on the American National Standards Institute (ANSI) character set, where a single byte represents each character. The other interface was created for the Unicode character set, where two bytes represent each character. All 16bit Windows operating systems and applications use the ANSI character set. All 32bit versions of Windows add Unicode to allow foreign language characters to be represented. C programmers handle this by setting a flag in their include file (*.h). The flag causes hundreds of macros throughout the C include files to select the correct Unicode or ANSI functions. All western language versions of Office products use ANSI for Visual Basic for Applications code. Therefore, programmers using current versions of Visual Basic for Applications or other macro languages should always use the ANSI version of the API call. When using the Win32api.txt file, this choice is made for you. For more information about this file, see "Change of Parameter Data Type," later in this section. To distinguish the ANSI version from the Unicode version, the ANSI version adds an A to the end of the API name, and the Unicode version adds a W. (W is for wide, as in the width of the bytes provided for characters.) The name of an API call includes either the character A or W at the end of the API name only if the API requires parameters with string (character) data types.
The Win32 SDK documentation in the Development Library does not record the permutations of the name of the API call. The documentation gives only the name of the root function and its library name. The actual name of the API in the library can be one of the following:
To understand the differences, see the following diagram showing the amount of data the API expects to find on possible call stacks for an example function (the 16bit version is padded because 16bit Windows always pads the stack to 16 bits).
The three possible declarations for MyAPICall are shown
in the following example, organized to make comparison easier.
All of the statements use the Alias control word so that
the function name used in code (MyAPICall) does not have
to change even if the name of the function called is appended
with an A or a W:
'16 bits
Declare function MyAPICall Lib "MYDLL.DLL" Alias "MyAPICall" (
ByVal hwndForm As Integer,
ByVal lpstrCaption$,
ByVal hAccKey As String,
ByVal iMagicNumber As Integer
) As Integer
'32bit ANSI
Declare function MyAPICall Lib "MYDLL32.DLL" Alias "MyAPICallA" (
ByVal hwndForm As Long,
ByVal lpstrCaption$,
ByVal hAccKey As String,
ByVal iMagicNumber As Long
) As Long
'32bit UNICODE * For illustration only.
Declare function MyAPICall Lib "MYDLL32.DLL" Alias "MyAPICallW" (
ByVal hwndForm As Long,
ByVal lpstrCaption$,
ByVal hAccKey As String,
ByVal iMagicNumber As Long
) As Long
Any one of these declarations would add the function MyAPICall to your application; you can only have one MyAPICall function.
This code sample introduces the ByVal keyword, which allows you to pass Visual Basic parameters to a API function by value. By Value is the default for functions written in C and is therefore the default for Windows API calls. The reason you must use ByVal is that Visual Basic and Visual Basic for Applications default to ByRef (By Reference passes a pointer to the value rather than the value itself), which is not what API calls expect. ByVal can also be used to convert a Visual Basic string to a nullterminated C string. ByVal is included in the Declare statements in Win32api.txt, so you know when to use it.
Note For more information about ByVal, see the Microsoft Developer Network (MSDN) article Q110219 How to call Windows API from VB, or published references such as PC Magazine Visual Basic Programmer's Guide to the Windows API by Dan Appleman, published by ZiffDavis Press.
The easiest way to get the new required parameter data types for 32bit API functions is to copy the appropriate API Declare statement from Win32api.txt into your source code.
| | Tools and Utilities The Office Resource Kit Tools and Utilities include the Visual Basic declaration file called Win32api.txt. For more information about viewing Win32api.txt, see "Visual Basic Win32 API Declarations" in Appendix A, "Microsoft Office Resource Kit Tools and Utilities." |
Either you misspelled the function name or you have a problem with case in the function name. Functions are casesensitive in Win32; they are not casesensitive in 16bit Windows.
Usually, this error is caused by having the wrong size or arguments, but it may also occur for some of the reasons described under Error 53.
Windows checks the loaded libraries for matches; if the DLL is not loaded, Windows attempts to load the DLL from disk. Many functions available in the 16bit Windows on Windows (WOW) layer on Windows NT Server are not available directly on Windows NT Workstation.
Calling the 16bit Windows and Win32 GetProfileString function from a 16bit and a 32bit solution gives a confusing set of error messages. The 16bit application call finds KERNEL and fails to find KERNEL32, while the 32bit application finds KERNEL32 and fails to find KERNEL. The general cause of this error is a mismatch of calls and operating systems. The solution is to write code that works in both 16bit and 32bit environments.
Writing a Single Code Base for 16bit and 32bit Office Applications
If users in your workgroup are running both 16bit and 32bit versions of an Office application — Excel 5.0 and 97, for example — should you put the 16bit API call or the 32bit API call in your solution? Excel, for example, is not like Visual Basic version 4.0, which allows conditional compilation of code into the executable files, but instead runs solution code in workbook files which may be opened in either the 16bit or the 32bit version of the application. The solution is to put both the 16bit API call and the 32bit API call inside an If...Then...Else control structure.
With 32bit applications using the same solution code as 16bit applications, you do not know which API to call in the solution code. Your code must determine whether the application is 16bit or 32bit in order to make the correct API call. Each application makes this determination using a set of different questions:
Is the host application 16bit Access 2.0 or earlier, or 32bit Access 95 or 97?
Is the host application 16bit Excel 5.0 or earlier, or 32bit Excel 5.0 for Windows NT operating system or 32bit Excel for Windows 95 or 97?
Is the host application 16bit Microsoft Project version 3.0, or 32bit Microsoft Project version 4.0 or later?
Is the host application 16bit Word 6.0 or earlier, or 32bit Word 6.0 for Windows NT or Word for Windows 95 or 97?
If you make the wrong API call, an error occurs. The solution code must determine whether the application is a 16bit application or a 32bit application, so it can make the appropriate call.
The solution is to put every API call into a wrapper —
a Visual Basic procedure or an Excel 4.0 macro.
This wrapper routinely checks the bitness of
the application and selects the appropriate API call. Place these
wrappers in separate modules so that your code can be easily reused.
Some API calls (for example, GetPrinterDriveDirectory and
GetWinMetaFileBits) are not available in all 32bit
operating environments, which means that the structure of an API
wrapper can become as complex as this:
Function MyAPICall$(ByVal Args)
If Engine32() Then
'Select is rarely needed
Select Case OS32() 'Based on GetVersionEx API
Case 0 'Win32s
....
Case 1 'NT 3.1
....
Case 2 'NT 3.5
....
Case 3 'Windows 95
....
End Select
Else '16bit
....
End If
End Function
An API wrapper this complex is the exception, however, and not the rule.
Compiled languages, such as FoxPro and Visual Basic, build 16bit or 32bit application executable files. The executable file targets either 16bit API calls or 32bit API calls. You can determine the appropriate API calls while building the application. You can select the calls in one of two ways: either by having all the 16bit declarations in one file and all the 32bit declarations in another file and manually switching them in a project; or by using the #IF... #ELSE... directives and conditional compilation supported by Visual Basic 4.0.
If you must support Visual Basic version 3.0 and Visual Basic 4.0 applications concurrently, separate files may reduce code maintenance. If you support FoxPro, you have no problem using 16bit API calls from compiled 32bit FoxPro solutions because the RegFN functions automatically thunk from the 32bit layer to the 16bit layer if needed.
Compiled 32bit languages may require some minor differences in API calls depending on the 32bit operating system. For example, developers must program context menus differently for Windows 95 than for Windows NT operating systems.
Determining Whether a 32bit Application Is Running
In the previous section, writing applicationindependent code is achieved by adding code for both 16bit and 32bit scenarios. However, you still need to determine in source code whether the application is a 32bit application or a 16bit application.
The code in the following examples determines whether these are 32bit applications.
Function Engine32%()
If instr(Application.OperatingSystem,"32") then Engine32%=True
End Function
Function Engine32
If Val(GetSystemInfo$(23)) > 6.3 Or Len(GetSystemInfo$(23))= 0 _
Then Engine32 = 1 Else Engine32 = 0
End Function
Function Engine32% ()
If SysCmd(7) > 2 Then Engine32% = True
End Function
Note The Application.OperatingSystem property in Excel and Microsoft Project does not return the version of Windows you have installed, but the layer of Windows that the application is running on, for example, the 16bit subsystem in Windows NT Workstation.
Putting It All Together
For examples of code for particular applications, you should consult the MSDN, and find the article entitled Corporate Developer's Guide to Office 95 API Issues. For information about connecting to MSDN, see "Microsoft Developer Network" in Appendix E, "Other Support Resources."
The following simple example may help you understand some issues.
Declare Function GetTickCount32 Lib "KERNEL32" Alias "GetTickCount" () _
As Long
Declare Function GetTickCount16 Lib "USER" Alias "GetTickCount" () _
As Long
Function GetRightTickCount() As Long
If Engine32%() Then
GetRightTickCount = GetTickCount32()
Else
GetRightTickCount = GetTickCount16()
End If
End Function
In this example, the GetTickCount API has the same name for both 16bit Windows and 32bit Windows, so you must use an Alias control word to change the function name in at least one of the Declare statements. In the example, the names in both Declare statements are changed to GetTickCount32 and GetTickCount16. Next, depending on the application's bitness, GetTickCount is mapped to the correct API function name (GetTickCount32 or GetTickCount16) and its associated API call. In this example, GetTickCount in your code is mapped to GetTickCount32 (in the GetTickCount function), which is in turn mapped to GetTickCount in KERNEL32, when Engine32% is True.
Word Sample DeclareMethod Solution
Word has a different Declare format and syntax. The Word solution is more complex because you cannot place both the 16bit and 32bit Declare statements in the same macro. The solution is to create three macro libraries: APICALL16 and APICALL32, which contain the Declare statements for each operating environment; and a 16bit/32bit interoperability macro, APICALLS.
First, create a macro library called APICALL16. This macro
contains all the 16bit API Declare statements.
'This is APICALL16 all 16bit Declare statements are placed here.
Declare Function GetTickCount16 Lib "USER" Alias "GetTickCount"() _
As Long
Function GetTickCount
GetTickCount = GetTickCount16
End Function
Second, create a macro library called APICALL32. This macro
contains all the 32bit API Declare statements.
'This is APICALL32 all 32bit Declare statements are placed here.
Declare Function GetTickCount32 Lib "KERNEL32" Alias "GetTickCount"() _
As Long
Function GetTickCount
GetTickCount = GetTickCount32
End Function
Third, create a macro library called APICALLS. This macro
contains Engine32 and the procedures your solution code
calls.
'This is APICALLS no Declare statements may be in this macro.
Function Engine32
Engine32 = 0
If Val(AppInfo$(2)) > 5 Then
OS$ = GetSystemInfo$(23)
If Val(OS$) > 6.3 Or Len(OS$) = 0 Then Engine32 = 1
End If
End Function
Function GetTickCount
If Engine32 Then
GetTickCount = APICall32.GetTickCount
Else
GetTickCount = APICall16.GetTickCount
End If
End Function
'Other API function calls are placed here.
You can now call this function from your solution code. You must
preface your calls with APICALLS. For example:
Sub MAIN
MsgBox Str$(APICalls.GetTickCount)
End Sub
To
convert Word solutions to run on 16bit and 32bit products
This process allows existing calls in other modules to be left untouched. After the developer defines and tests these macros, the developer can add them to Normal.dot and reuse the macros in other solutions so as to cut conversion time.
This section has so far focused on the issue of updating Windows API calls — but the issues for solution code that calls 16bit DLLs that you have bought, developed, or used is exactly the same. The developer must change all 16bit DLL Declare calls in solution code to 32bit calls. This requires creating a 32bit version of the DLL (at least) and possibly changing the Declare statement (or, in Excel 4.0 macros, the Register function).
This also means a separate DLL must exist for both the 16bit application and the 32bit application. For file management, the name of the 32bit DLL should include 32 at the end. The developer must recompile the DLL as a 32bit Ansi.dll. The parameters passed to the DLL must use the stdcallpassing protocol to talk to 32bit Visual Basic for Applications, instead of the PASCALpassing protocol used with 16bit Windows. Place the calls for the 16bit and 32bit versions of the DLL in a wrapper similar to the API wrapper described previously.
For more information about recompiling applications, see Chapter 1, "Porting 16bit Code to 32bit Windows," in Programming Techniques from the Microsoft Visual C++® version 2.1 documentation in the Development Library, or see your C compiler documentation.
When you do not have the source code of a DLL, your solution is to use thunking to port your solution to Windows 95. Thunking enables direct 16bit and 32bit calls but requires much more work than simply changing the Windows API call. If you cannot change or recompile the 16bit DLL, you must write a new 32bit DLL wrapper to access the 16bit DLL. The 32bit application calls to this 32bit wrapper DLL, which then calls the original 16bit DLL.
Thunking allows parameters to be pushed correctly on the stack, enables a DLL of a different bitness to load in your process, and converts memory addresses from offset (32bit) to segment::offset (16bit). Even if you do the thunking work, however, some issues remain. For example, pointers to memory locations require additional work in 16bit and 32bit scenarios.
There are several ways to thunk, depending on your operating system: Windows 95 and Windows NT thunk differently. For an overview of thunking across the Windows operation systems, as well as references to more information about thunking, see Diving into the Requirements for the Windows 95 Logo in the Development Library.
Most developers writing solution code know the C language, and the following information is provided to assist them in using their knowledge of C to create Declare statements for Visual Basic and Visual Basic for Applications using the tools they already have.
Working from C Declarations
Apart from the API location changing (from KERNEL to KERNEL32), the main issue in moving from 16bit API calls to 32bit API calls is the change in the size of parameter data types. Some background information may help you understand what has changed and why. Windows 3.x was designed for the Intel 80286 CPU, where the hardware handles data two bytes at a time, or in 16bit words. Windows 95 was designed for later CPUs, where the hardware can handle data four bytes at a time, or in 32bit words. The following list shows how Visual Basic represents an Integer as opposed to how Windows represents an int:
To illustrate how this change in size can affect a call, recall the fictional MyAPICall API used earlier. The MyAPICall call needs the handle to the application's window (HWND), a string, a character, and an integer to be placed on the stack. In C, the function would be:
int MyAPICall (HWND hwndForm, LPSTR lpstrCaption, TCHAR tchAccKey, _
int iMagicNumber)
Each parameter has two parts: the data type (HWND, LPSTR,
TCHAR, int) and the field name (hwndForm,
lpstrCaption, tchAccKey, iMagicNumber). Each
data type requires a specific number of bytes to represent it.
Each field name has some oddlooking characters as a prefix —
these characters (known as Hungarian notation) indicate the data
type, such as int or lpstr.
Windows has many data types that API calls use as parameters.
The following table shows some of the more significant data types
used by Windows 95 API calls. Many Windows data types use
the C data type of int. (When int changed from 16bits
to 32bits, the related Windows data types also changed.)
| C data type | Size in Windows 3.x and Windows for Workgroups 3.x (16bit) | Size in Win32s, Windows NT operating system, and Windows 95 (32bit) |
| unsigned int, UINT, int | 2 bytes | 4 bytes |
| short | 2 bytes | 2 bytes |
| long | 4 bytes | 4 bytes |
| char, CHAR | 1 byte | 1 byte |
| WORD | 2 bytes | 2 bytes |
| Handle (hWnd, hDC, hMenu) | 2 bytes | 4 bytes |
| LPSTR | 4 bytes | 4 bytes |
| WCHAR | 2 bytes | 2 bytes |
| TCHAR (ANSI or Unicode) | 1 byte | 1 or 2 bytes |
| POINT | 4 bytes | 8 bytes |
Thus, converting the MyAPICall API call from C, the declarations
for MyAPICall using Visual Basic for Applications, Access
Basic, or WordBasic would be as follows (organized to make comparison
easier):
'16 bits
Declare Function MyAPICall Lib "MYDLL.DLL" Alias "MyAPICall" (
ByVal hwndForm As Integer,
ByVal lpstrCaption As String,
ByVal hAccKey As String,
ByVal iMagicNumber As Integer
) As Integer
'32 bits
Declare Function MyAPICall Lib "MYDLL32.DLL" Alias "MyAPICall" (
ByVal hwndForm As Long,
ByVal lpstrCaption As String,
ByVal hAccKey As String,
ByVal iMagicNumber As Long
) As Long
A final tool you may find useful is the following table, which maps C language declaration data types to their Visual Basic equivalents.
| C language declaration data type | Visual Basic equivalent | Called with this variable |
| Boolean | ByVal B As Boolean | Any Integer or Variant variable |
| Pointer to a string (LPSTR) | By Val S As String | Any String or Variant variable |
| Pointer to an integer (LPINT) | I As Integer | Any Integer or Variant variable |
| Pointer to a long integer (LPDWORD) | L As Long | Any Long or Variant variable |
| Pointer to a structure (for example, LPRECT) | S As Rect | Any variable of that userdefined type |
| Integer (INT, UINT, WORD, BOOL) | ByVal I As Integer | Any Integer or Variant variable |
| Handle (32 bit, HWND) | ByVal H As Long | Any Long or Variant variable |
| Long (DWORD, LONG) | ByVal L As Long | Any Long or Variant variable |
| Pointer to an array of integers | I as Integer | The first element of the array, such as I(0) |
| Pointer to a void (void*) | V As Any | Any variable (use ByVal when passing a string) |
| Void (function return value) | Sub Procedure | Not applicable |
| NULL | As Any | ByVal 0& |
| Char (TCHAR) | ByVal Ch As String | Any String or Variant variable |
|
Using the Win32 Programmer's Reference
The two primary sources for Win32 API information are the Win32
Programmer's Reference and a list of Microsoftsupplied
Win32 Declare statements for Visual Basic, such as Win32api.txt.
The Development Library contains a listing with explanations of
the entire Win32 API set in the Win32 Programmer's Reference.
For more information about the Development Library, see "Microsoft
Developer Network," in Appendix E, "Other
Support Resources."
|
|
