Porting 16-Bit WordBasic Macros to 32-Bit WordBasic Macros

ID: Q120767

The information in this article applies to:

Microsoft Word for Windows NT, version 6.0
Microsoft Word for Windows 95, version 7.0

SUMMARY

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

MORE INFORMATION

Declare

Because Word for Windows NT is a 32-bit application, any Declare statements must use 32-bit conventions.

If the function being called is a Windows API function, some general rules can be used to determine what the 32-bit equivalent API function is. For the most accurate information, however, it is best to consult a Win32 SDK guide.

Rule 1: Use the 32-bit version of the DLL.

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 Function getwindowsdirectory Lib "Kernel"(WinDir As
String, nSize As Integer) As Integer 
Declare statement for use with Word for Windows NT:
Declare Function GetWindowsDirectoryA Lib "Kernel32"(WinDir
As String, nSize As Long) As Long 

ExitWindows

In Windows, the ExitWindows WordBasic command ends the current Windows session and exits back to MS-DOS. Executing the ExitWindows WordBasic command in Word for Windows NT logs the current user off and returns to the Windows NT Welcome screen.

FileOpen

Word for Windows NT supports the use of long filenames, including those with one or more spaces. In Word for Windows and Word for Windows NT, the FileOpen command supports the ability to open more than one document at the same time by separating the two document names with spaces.

To open documents that contain spaces and not have Word for Windows NT assume they are separate document names, the entire name must be enclosed in quotation marks.

The following WordBasic macro command opens two documents simultaneously, one called "FIRST.DOC" and one called "SECOND.DOC":


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.

GetPrivateProfileString$() and SetPrivateProfileString

GetPrivateProfileString$() and SetPrivateProfileString support the same functionality in Word for Windows NT as they do in Word for Windows. However, new functionality was added so that these commands can also support the Windows NT Registry.

If the final parameter, the INI filename, is blank, Word for Windows NT assumes that the section parameter is a full path to a Windows NT Registry Key. The second parameter, key name, is used as the value name.

Because Word for Windows NT settings are stored in the Registry, any WordBasic application-private INI functions that previously used the WINWORD6.INI file need to be modified to work with the settings as they exist in the Registry.

For example, consider the following macro command that determines the workgroup path in Word for Windows:


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", "")

GetProfileString$() and SetProfileString

GetProfileString$() and SetProfileString in Word for Windows NT both function the same as they do in Word for Windows. However, in Windows NT, the settings the macro may read or set are not located in INI files.

In Word for Windows NT, you should use GetPrivateProfileString$() and SetPrivateProfileString instead of GetProfileString$() and SetProfileString to get or set Word settings. GetPrivateProfileString$() and SetPrivateProfileString access the Windows NT Registry, where the Word settings are located under Windows NT.

GetSystemInfo$()

The following GetSystemInfo$() function types are different when used in Word for Windows NT:


  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

Like FileOpen, the Shell WordBasic command now supports long filenames. If the program being launched by the Shell command contains spaces in its filename, quotation marks must be included around the name, but not around any command line parameters, if included.

For example, assume the name of the program to be launched is "Example Executable.exe" and needs the command-line parameters "/c test". The Shell command necessary to perform this action would be as follows:


Shell Chr$(34) + "Example Executable" + Chr$(34) + " /c test"

ToolsAdvancedSettings

ToolsAdvancedSettings can be used to modify Word-related settings in the WINWORD6.INI and WIN.INI files with Word for Windows. Under Word for Windows NT, this command still modifies settings in those INI files. However, since Word for Windows NT does not use those INI files to store its settings, any settings made with this command are ignored. Word for Windows NT settings are stored in the Windows NT Registry instead.

To modify or query Word for Windows NT Registry settings, use SetPrivateProfileString or GetPrivateProfileString$() instead.

REFERENCES

For additional information about similar issues in Microsoft Excel, please see the following article in the Microsoft Knowledge Base:

Q131525 "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 :
Version : WINDOWS:7.0; winnt:6.0
Platform : WINDOWS winnt
Issue type :