Porting 16-Bit WordBasic Macros to 32-Bit WordBasic Macros |
Q120767
Most Word for Windows macros work correctly in Word for Windows NT without
modification. However, areas of a macro that deal with operating-system-
specific areas may require minor revision.
The following WordBasic commands either behave somewhat differently or
require special consideration when being used with Word for Windows NT:
Declare
ExitWindows
FileOpen
GetPrivateProfileString$() and SetPrivateProfileString
GetProfileString$() and SetProfileString
GetSystemInfo$()
Shell
ToolsAdvancedSettings
The name of the DLL containing the function typically has "32" appended to the end of the name. For instance, the equivalent of "kernel" in Windows 3.x is "kernel32" in Windows NT. However, there are exceptions to this.Rule 2: Use the ANSI version of the function.
Functions that use strings are typically available in two versions: ANSI and Unicode. Word for Windows NT is an ANSI application and must, therefore, use ANSI API functions. The ANSI version of API functions have an "A" appended to the end of the function name. For instance, the Windows 3.x function "GetWindowsDirectory" is "GetWindowsDirectoryA" under Windows NT.Rule 3: Integer parameters are 32-bit.
For all functions under Windows 3.x that use the type Integer, Windows NT uses Long.Rule 4: Function names are case sensitive.
Unlike Windows, DLL functions in Windows NT are case sensitive. For the Declare statement to work, the case of the function name must match the actual case of the function name exactly.
The following examples demonstrate the use of the three rules above:Declare statement for use with Word under Windows 3.x:Declare statement for use with Word for Windows NT:Declare Function getwindowsdirectory Lib "Kernel"(WinDir As String, nSize As Integer) As IntegerDeclare Function GetWindowsDirectoryA Lib "Kernel32"(WinDir As String, nSize As Long) As Long
FileOpen "FIRST.DOC SECOND.DOC"
This WordBasic macro command opens a single document called "FIRST.DOC
SECOND.DOC":
FileOpen Chr$(34) + "FIRST.DOC SECOND.DOC" + Chr$(34)
If the macro being written uses a string variable to store the macro name
and it is not known at design time whether the filename will contain
spaces, the string should have quotation marks added to it, or the FileOpen
command should include the Chr$(34) functions, as shown in the example
below:
FileOpen Chr$(34) + TheFileName$ + Chr$(34)
This guarantees that the file will always be successfully opened, whether
it contains spaces or not.
x$ = GetPrivateProfileString$("Microsoft Word", "WORKGROUP-DOT-PATH",
"WINWORD6.INI")
An equivalent function in Word for Windows NT is as follows:
x$ = GetPrivateProfileString$("HKEY_CURRENT_USER\Software\Microsoft\
Word\6.0\Options", "WORKGROUP-DOT-PATH", "")
Type Description Difference
---- -------------------------- --------------------------------------
23 MS-DOS Version Number Since Windows NT does not run with
MS-DOS, this function returns an empty
string instead of a version number.
25 Available Resources Windows NT does have resource
restrictions as Windows does. Calling
this function with Word for Windows NT
will return an empty string.
27 Windows Mode Windows NT does not have a Standard or
386 Enhanced Mode as Windows 3.x does.
Calling this function with Word for
Windows NT will return an empty string.
Shell Chr$(34) + "Example Executable" + Chr$(34) + " /c test" For additional information about similar issues in Microsoft Excel, please see the following article in the Microsoft Knowledge Base:
Q131525 XL: Can't Run Macro That Calls 16-bit DLL in 32-bit MS Excel
Additional query words: winword 6.0 ntword wordnt 16-bit 16 bit convert macro word7 6.0a 6.0c 7.0 word95 word6
Keywords :
Issue type :
Technology : kbWordSearch kbWord700Search kbZNotKeyword3 kbWord700 kbWord600NT
|
Last Reviewed: November 5, 2000 © 2001 Microsoft Corporation. All rights reserved. Terms of Use. |