CompuServe Messages

Howard The problem is WinWord NT, not Win95. Win95 should behave exactly the same as Win3.x, but WinWord NT is known to behave differently than 16-bit WinWord. If you have any knowledge of WinWord macros, you can modify the macros yourself to make them work properly. Of course, if I had a recent build of Win95 I'd be happy to test it out and do it for you…but I don't (my usual NYC sources seem to have dried up<g>). Anyway, the following is a Microsoft doc that outlines the differences between 16-bit WinWord macros and 32-bit WinWord macros. Hope it helps. David Porting WordBasic Macros to Word for Windows NT ——————————————————————– The information in this article applies to: – Microsoft Word for Windows NT, version 6.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 Wor d\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. KBCategory: kbusage kbmacro kbenv KBSubcategory: