WD6X: Handling Cross-Platform Differences in WordBasic |
Q128944
The information in this article applies to:
- Microsoft Word for Windows, version 6.0
- Microsoft Word for the Macintosh, version 6.0
- Microsoft Word for Windows NT, version 6.0
SUMMARY
Microsoft Product Supports Services offers an Application Note called "Handling Cross-Platform Differences in WordBasic" (XD1155). This document describes differences that you should address when you are creating macros that will run in Microsoft Word under the Macintosh, Microsoft Windows, and Microsoft Windows NT operating systems. This reference contains advanced material about programming macros in WordBasic and is intended for the advanced Word user.
Windows/MS-DOS
The following file is available for download from the Microsoft Download Center. Click the file name below to download the file:
For additional information about how to download Microsoft Support files, click the article number below to view the article in the Microsoft Knowledge Base:
Q119591 How to Obtain Microsoft Support Files from Online Services
Microsoft used the most current virus detection software available on the date of posting to scan this file for viruses. Once posted, the file is housed on secure servers that prevent any unauthorized changes to the file.
Macintosh
The following file is available for download from the Microsoft Download Center. Click the file name below to download the file:
For additional information about how to download Microsoft Support files, click the article number below to view the article in the Microsoft Knowledge Base:
Q119591 How to Obtain Microsoft Support Files from Online Services
Microsoft used the most current virus detection software available on the date of posting to scan this file for viruses. Once posted, the file is housed on secure servers that prevent any unauthorized changes to the file.
THE TEXT OF XD1155
==================
======================================================================
Microsoft(R) Product Support Services Application Note (Text File)
XD1155: HANDLING CROSS-PLATFORM DIFFERENCES IN WORDBASIC
======================================================================
Revision Date: 3/95
No Disk Included
The following information applies to Microsoft Word, version 6.0.
---------------------------------------------------------------------
| INFORMATION PROVIDED IN THIS DOCUMENT AND ANY SOFTWARE THAT MAY |
| ACCOMPANY THIS DOCUMENT (collectively referred to as an Application |
| Note) IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER |
| EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE IMPLIED |
| WARRANTIES OF MERCHANTABILITY AND/OR FITNESS FOR A PARTICULAR |
| PURPOSE. The user assumes the entire risk as to the accuracy and |
| the use of this Application Note. This Application Note may be |
| copied and distributed subject to the following conditions: 1) All |
| text must be copied without modification and all pages must be |
| included; 2) If software is included, all files on the disk(s) |
| must be copied without modification (the MS-DOS(R) utility |
| diskcopy is appropriate for this purpose); 3) All components of |
| this Application Note must be distributed together; and 4) This |
| Application Note may not be distributed for profit. |
| |
| Copyright (C) 1995 Microsoft Corporation. All Rights Reserved. |
| Microsoft, MS-DOS, and Windows are registered trademarks and |
| Windows NT is a trademark of Microsoft Corporation. |
| Apple, Mac, and Macintosh are registered trademarks and PowerTalk |
| and QuickDraw are trademarks of Apple Computer, Inc. |
--------------------------------------------------------------------
INTRODUCTION
============
This Application Note describes differences that you should address
when you are creating macros that will run in Microsoft Word under the
Macintosh(R), Microsoft Windows, and Microsoft Windows NT(TM)
operating systems. This reference contains advanced material about
programming macros in WordBasic and is intended for the advanced Word
user.
The information in this Application Note applies to Microsoft Word
versions 6.0, 6.0a, and 6.0c for Windows, Microsoft Word version 6.0
for the Macintosh, and Microsoft Word version 6.0 for Windows NT.
WARNING: ANY USE BY YOU OF THE CODE PROVIDED IN THIS ARTICLE IS AT
YOUR OWN RISK. Microsoft provides this macro code "as is" without
warranty of any kind, either express or implied, including but not
limited to the implied warranties of merchantability and/or fitness
for a particular purpose.
PLATFORM DIFFERENCES IN WORDBASIC
=================================
When you are writing cross-platform macros, consider whether the
platform requires different system-specific functionality in
WordBasic. A different parameter or an entirely different command may
be necessary for the macro to run on both the Macintosh and the
Windows operating systems.
Most Word for Windows macros work correctly in Word for the Macintosh
and Word for Windows NT without modification. However, areas of a
macro that deal with operating-system-specific areas may require minor
revision.
Areas that may require extra attention include:
- Specifying filenames and paths
- Using settings files
- Working with DDE
- Calling external routines or libraries
DETERMINING THE CURRENT OPERATING SYSTEM
========================================
AppInfo$()
A cross-platform macro should determine the current operating system,
or platform, if the macro contains platform-specific commands.
Otherwise, the macro may return a WordBasic error when run on a
different operating system.
The WordBasic AppInfo$(1) function will identify which platform is
being used when the macro is run. AppInfo$(1) will return the
following strings for each platform:
Platform Return Value
-----------------------------
Macintosh "Macintosh xxx"
Windows "Windows xxx"
Windows NT "Windows NT xxx"
In the return values listed above, "xxx" represents the version number
of the operating system being used.
You can store the string returned by the function in a variable that
can be used to determine which WordBasic commands to execute later in
the macro.
The following sample macro illustrates how to use the AppInfo$(1)
function:
Sub MAIN
REM Determine Platform
REM ------------------
PlatformVar = 0
If Instr(AppInfo$(1), "Macintosh") <> 0 Then
Platformvar = 1
ElseIf Instr(AppInfo$(1), "Windows NT") <> 0 Then
PlatformVar = 2
End If
REM Remainder of Macro
REM ------------------
Select Case PlatformVar
Case 0
REM WORD FOR WINDOWS COMMANDS GO HERE
Case 1
REM WORD FOR MACINTOSH COMMANDS GO HERE
Case 2
REM WORD FOR WINDOWS NT COMMANDS GO HERE
Case Else
Print "Invalid value"
End Select
End Sub
The Instr() function determines which string AppInfo$(1) is returning
and sets the PlatformVar variable appropriately. If "Macintosh" is
returned, PlatformVar is set to 1. If "Windows NT" is returned,
PlatformVar is set to 2. Because PlatformVar is initially set to 0,
the "Windows" platform corresponds to a value of 0. The If statements
then evaluate which WordBasic commands to execute based on whether
PlatformVar is set to 0, 1, or 2.
TIPS FOR CREATING CROSS-PLATFORM MACROS
=======================================
Choose one platform for writing and editing cross-platform macros and
use it consistently. Avoid editing macros on more than one platform if
you are developing macros in a version of Word that does not recognize
WordBasic commands supported by Word on another platform. For example,
if you write a macro in Word 6.0a for Windows, and then the macro is
moved to Word 6.0 for the Macintosh, edited, and moved back to Word
for Windows and edited, Word for Windows will remove Macintosh-
specific commands from the macro. This situation occurs because Word
6.0 and 6.0a for Windows don't recognize the Macintosh commands. For
more information, please see the sections regarding converting cross-
platform macros in this Application Note.
If you are writing the macro in a version of Word that does not
recognize WordBasic commands supported by Word on another platform,
test a copy of the macro on the other platform. Note any changes that
are required for the macro to run correctly and then add the commands
to the original.
Decide whether to distribute the macro in an execute-only format. If
the macro is formatted as execute-only, it cannot be edited. Use the
MacroCopy statement with the ExecuteOnly parameter set to 1. Because
the action cannot be reversed, be sure to make a copy of the macro
before setting it to execute-only.
OPENING FILES
=============
Files$()
The Files$() WordBasic function returns the first filename that
matches the file specification parameter. In Windows, the file
specification can contain the MS-DOS wildcard characters (the asterisk
and question mark); on the Macintosh, the MacID$ command is used to
specify files of a certain type.
The following Word for Windows example returns the first file ending
in ".doc" in the current directory:
a$ = Files$("*.doc")
The following Word for the Macintosh example returns the first file
that has the Word 6.0 for the Macintosh document file type:
a$ = Files$(MacID$("W6BN"))
Note that the Macintosh example uses MacID$, a Macintosh-specific
WordBasic command that converts an application signature or file type
to a value that can be used with other commands, including Files$().
To determine the file type, use a resource editor program (for
example, ResEdit). The file type for Word 5.1 for the Macintosh
documents is "WDBN." The file type for Microsoft Excel 5.0 for the
Macintosh spreadsheets is "XLS5."
OPENING MORE THAN ONE FILE AT A TIME
====================================
FileOpen
Word for Windows and Word for Windows NT support opening more than one
file at a time with a single FileOpen command. For example, to open
the two files, FIRST.DOC and SECOND.DOC, use the following FileOpen
command:
FileOpen .Name = "FIRST.DOC SECOND.DOC"
Word for the Macintosh will open only one file per FileOpen command.
Therefore, you must expand the above FileOpen command to two commands,
as in this example:
FileOpen .Name = "First"
FileOpen .Name = "Second"
LONG FILENAMES AND SPACES
=========================
Both Word for the Macintosh and Word for Windows NT support the use of
long filenames, including those with one or more spaces.
To open a document whose name contains spaces and to prevent Word for
Windows NT from treating the name as separate document names, you must
enclose the entire name in quotation marks by adding the quotation
mark character, CHR$(34), to the beginning and end of the long
filename. The following WordBasic macro command opens a single
document called "FIRST.DOC SECOND.DOC":
FileOpen .Name = Chr$(34) + "FIRST.DOC SECOND.DOC" + Chr$(34)
Word for the Macintosh allows quotation marks to be used as part of
the filename. Because the Macintosh version of the FileOpen command
accepts only one filename, you must explicitly omit the quotation mark
characters [that is, CHR$(34)]. The Macintosh version of the FileOpen
command above would look like this:
FileOpen .Name = "First Second"
USING SETTINGS FILES
====================
In Windows, Word settings are stored in a text file called
WINWORD6.INI. On the Macintosh, settings are stored in a file called
Word Settings (6). In Windows NT, Word settings are stored in the
Windows NT Registry. Use the SetPrivateProfileString command and
GetPrivateProfileString$() function to change or retrieve settings in
the WINWORD6.INI file, Word Settings (6) file, or the Windows NT
Registry.
The GetPrivateProfileString$() function is used differently depending
upon the platform. The syntax for GetPrivateProfileString$() is
GetPrivateProfileString$(Section$,KeyName$,Filename$)
where Section$ is the name of the section in the settings file,
KeyName$ is the key whose setting will be retrieved, and Filename$ is
the path and filename for the settings file.
The following examples show how to retrieve the DOC-PATH setting for
each platform:
Windows
a$ = GetPrivateProfileString$("Microsoft Word","DOC-
PATH","WINWORD6.INI")
Macintosh
a$ = GetPrivateProfileString$("Microsoft Word", "DOC-PATH","Word
Settings (6)")
Windows NT
a$ =GetPrivateProfileString$("HKEY_CURRENT_USER\Software\
Microsoft\Word\6.0\Options","DOC-PATH","")
On Windows and the Macintosh, do not specify a path for the settings
file because this path defaults to a particular location for those
operating systems. Windows keeps the WINWORD6.INI file in the Windows
directory. The Macintosh keeps the Word Settings (6) file in the
Preferences folder in the System folder. If you specify the path to
the settings file, an empty string will be returned when the macro
attempts to read a setting and the file is not located where precisely
specified. In Word for NT, the path to the key in the Registry is the
first parameter in parenthesis.
USING WORD ADD-IN LIBRARIES AND WINDOWS DYNAMIC-LINK LIBRARIES
==============================================================
In Word 6.0, routines stored in external libraries can be called as
functions or subroutines by WordBasic macros. In Word for Windows and
Word for Windows NT, the libraries can be either Word add-ins (WLLs)
or Windows dynamic-link libraries (DLLs), or they can be executable
files (.EXEs). In Word for the Macintosh, only routines in WLLs can be
called. The Declare statement specifies the name of the routine, the
library file in which it is stored, and any argument types the routine
takes.
When a Word for Windows macro is converted to Word for the Macintosh,
any Declare statements that refer to DLLs will return the WordBasic
error 543, "Unable to open specified library." This error occurs
because the Windows libraries (USER.EXE, KRNL386.EXE, and GDI.EXE) do
not exist on the Macintosh.
When you convert a Word for Windows macro to Word for Windows NT, make
sure that any Declare statements use 32-bit conventions. If the
function being called is a Windows API function, there are some
general rules you can use to determine the 32-bit Windows NT
equivalent API function. For the most accurate information, consult
the "Microsoft Win32 Software Developer's Kit."
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.
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 application programming interface (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 in Windows, DLL functions in Windows NT are case sensitive. For
the Declare statement to work, the case of the function name must
exactly match the actual case of the function name.
The following two examples
demonstrate the use of the four 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
When you are experimenting with external routines, be sure to save
your work often. An invalid argument passed to a routine could result
in unpredictable behavior in Word or in other applications.
For more information regarding standard Windows function libraries
such as GDI.EXE and USER.EXE, see the "Microsoft Windows Programmer's
Reference, Volume 2." For a list of the appropriate module and library
for each function, see "Volume 1." Windows NT functions are documented
in the "Microsoft Win32 Programmer's Reference, Volume 3" and "Volume
4."
In addition, the "Microsoft Word Developer's Kit, Second Edition,"
contains tools for creating add-ins that interact directly with Word
using the Microsoft Word application programming interface (Word API).
WORKING WITH DYNAMIC DATA EXCHANGE (DDE)
========================================
DDE is a protocol WordBasic can use to extract information from other
applications or to send commands to other applications. When a client
application (the application requesting information or sending
commands) begins a DDE conversation, it must specify the name of the
application (the server) and the subject of the conversation (the
topic).
Below are the DDE application names for Microsoft Word:
Windows:
"WinWord" or "WordDocument"
Windows NT:
"WinWord" or "MSWord" or "WordDocument"
Macintosh:
"WinWord" or "MSWord"
The instructions used to initiate DDE conversations are the same in
Windows and on the Macintosh, but because DDE application names are
usually different on different platforms, separate instructions are
necessary for each platform. Use MacID$() to specify an application on
the Macintosh if you use AppIsRunning() and Shell instructions when
you are initiating a DDE conversation.
The following example initiates a DDE conversation with Microsoft
Excel for the Macintosh or Microsoft Excel for Windows. In this
example the DDERequest$() command is used to get a list of the
currently supported topics, which are then inserted into the current
document.
Sub MAIN
REM First Determine Platform
PlatformVar = 0
If Instr(AppInfo$(1), "Macintosh") <> 0 Then
Platformvar = 1
ElseIf Instr(AppInfo$(1), "Windows NT") <> 0 Then
PlatformVar = 2
End If
REM Then Perform the Commands
Select Case PlatformVar
REM The Mac Commands:
Case 1
If AppIsRunning(MacID$("XCEL")) = 0 Then
Shell MacID$("XCEL"), 4
End If
chan = DDEInitiate("Excel", "System")
topics$ = DDERequest$(chan, "Topics")
Insert topics$
REM The Windows and Windows NT Commands:
Case 0, 2
If AppIsRunning("Excel") = 0 Then
Shell "c:\EXCEL5\EXCEL.EXE", 4
End If
chan = DDEInitiate("Excel", "System")
topics$ = DDERequest$(chan, "Topics")
Insert topics$
Case Else
End Select
End Sub
NOTE: When an application runs on more than one platform, the same
application may have a different application name in Windows and on
the Macintosh. Because of these differences, it is better to use OLE
automation for macros that will run on more than one platform. OLE
automation is another protocol that allows an application to share
data with or control another application. For more information
regarding OLE automation, please see the "Microsoft Word Developer's
Kit, Second Edition" pages 181 through 190.
CONVERTING CROSS-PLATFORM MACROS
================================
Word 6.0, 6.0a, 6.0c for Windows --> Word 6.0 for the Macintosh
---------------------------------------------------------------
A macro created in Word version 6.0, 6.0a, or 6.0c for Windows that
contains Macintosh-specific WordBasic commands will return the
following error when run in Word 6.0 for the Macintosh unless you
"dirty" the macro first:
WordBasic Error 124, "Unknown Command, Subroutine, or Function"
A macro is considered "dirty" if it has been changed since it was last
saved. To avoid the WordBasic Error 124 message in this case and
enable the Macintosh-specific commands, transfer the template to the
Macintosh operating environment, and (before you run the macro) open
the macro in Word 6.0 for the Macintosh. Edit the macro by inserting a
space or adding a comment, and then close and save the macro.
After you edit and save (that is, dirty) the macro in Word for the
Macintosh, the Macintosh-specific commands should run without error.
Dirtying the macro in Word for the Macintosh is necessary only once.
Ideally, you should dirty the macro once prior to distributing the
macro to other Macintosh Word users.
Macintosh-specific commands are those WordBasic commands that are
available only on the Macintosh platform. The following example
contains the Macintosh-specific command MacID$().
Sub Main
a$ = MacID$("TEXT")
End Sub
Word 6.0 or 6.0a for Windows <--> Word 6.0 for the Macintosh
------------------------------------------------------------
If you create a macro in Word for the Macintosh and copy the template
that contains the macro to Word 6.0 or 6.0a for Windows, Word
permanently removes the Macintosh-specific WordBasic commands from the
macro when you edit and save the macro in Word 6.0 or 6.0a for
Windows. Word does not restore the Macintosh commands when you
transfer the macro back to the Macintosh platform, and as a result,
the macro will not run correctly on the Macintosh.
The following Macintosh Word 6.0 macro contains a Macintosh-specific
function named MacID$.
Sub MAIN
a$ = MacID$("TEXT")
End Sub.
If you open, edit, and save changes to the above cross-platform macro
in Word 6.0 or 6.0a for Windows, the macro will appear as shown below
when reopened in Word 6.0 for the Macintosh:
Sub MAIN
a$ = ("TEXT")
End Sub
NOTE: The Macintosh-specific command MacID$ was deleted.
Word 6.0c for Windows <--> Word 6.0 for the Macintosh
-----------------------------------------------------
Word 6.0c for Windows does not delete unknown (Macintosh-specific)
commands from your Word for the Macintosh macros when you transfer
them to Word 6.0c for Windows. Word 6.0c will instead display
"Unrecognized_Statement" in place of the Macintosh commands.
If you create the following macro in Word 6.0 for the Macintosh
Sub Main
a$ = MacID$("TEXT")
End Sub
and open the template that contains the macro in Word 6.0c for
Windows, the macro will appear as follows:
Sub Main
a$ = Unrecognized_Statement33134("TEXT")
End Sub
The "33134" number is the token identification number for the "MacID$"
command. Word 6.0c for Windows does not delete any unrecognized
Macintosh WordBasic commands.
If you transfer the template that contains the macro back to Word 6.0
for the Macintosh, you must dirty the macro in Word for the Macintosh.
In other words, you must open the macro in Word for the Macintosh,
make a small change such as adding a space, and save the macro. This
action changes the token IDs back to the Macintosh-specific WordBasic
commands, such as MacID$(). Dirtying the macro in Macintosh Word is
necessary only once. Ideally, you should dirty the macro once before
distributing the macro to other Word for the Macintosh users.
Word 6.0 for Windows NT <--> Word 6.0 for the Macintosh
-------------------------------------------------------
Note that Macintosh-specific WordBasic statements and functions are
recognized by Word 6.0 for Windows NT.
DETERMINING WHETHER QUICKDRAW(TM) IS INSTALLED
============================================
GetSystemInfo$()
QuickDraw GX is Apple(R)'s new version of QuickDraw, which is the
language the Macintosh uses to draw images to the screen. If
installed, QuickDraw GX provides the means for Word 6.0 to access
different Page Setup options available under QuickDraw GX.
When you write a macro that contains Macintosh-specific commands
referring to QuickDraw GX, such as FileMacPageSetupGX or
FileCustomMacPageSetupGX, the macro must first determine whether
QuickDraw GX is installed.
You can use the GetSystemInfo$(519) function to determine whether
QuickDraw GX is installed on the system under which the macro is
running. The return value of GetSystemInfo$(519) is "Yes" if QuickDraw
GX is installed and "No" if it is not. The following macro illustrates
one way the GetSystemInfo$(519) function can be used:
Sub MAIN
If GetSystemInfo$(519) = "Yes" Then
MsgBox "QuickDraw GX is installed on this system."
Else
Msgbox "QuickDraw GX is not installed on this system."
End If
End Sub
STATEMENTS AND FUNCTIONS USED ONLY ON THE MACINTOSH
===================================================
The following table lists WordBasic statements and functions that are
valid only when Word is running on the Macintosh. A WordBasic
statement or function that is only available in Word for Macintosh
will generate an "Unknown command" error if run on the Windows
platform.
Word for the Macintosh Statements and Functions
-----------------------------------------------
EditCreatePublisher
EditPublishOptions
EditSubscribeOptions
EditSubscribeTo
EditFindBorder
EditFindFrame
EditFindTabs
EditReplaceBorder
EditReplaceFrame
EditReplaceTabs
FileCustomMacPageSetupGX
FileDocumentLayout
FileMacPageSetup
FileMacPageSetupGX
ListCommands
Outline
Outline()
Shadow
Shadow()
MacScript
MacScript$()
MountVolume
AOCEAddRecipient
AOCEAuthenticateUser()
AOCEClearMailerField
AOCECountRecipients()
AOCEGetRecipient$()
AOCEGetSender$()
AOCEGetSubject$()
AOCESendMail
AOCESetSubject
FileAOCEAddMailer
FileAOCEDeleteMailer
FileAOCEExpandMailer
FileAOCEForwardMail
FileAOCENextLetter
FileAOCEReplyAllMail
FileAOCEReplyMail
FileAOCESendMail
FilePrintOneCopy
FileQuit
ShowClipboard
Note on QuickDraw GX: QuickDraw GX must be installed in order to use
the FileCustomMacPageSetupGX, and FileMacPageSetupGX commands.
QuickDraw is the language the Mac(R) uses to draw images to the screen
and interpret print files. QuickDraw GX is Apple's new optional
version of QuickDraw included with System Software 7.5. If installed,
QuickDraw GX provides the means for Word 6.0 to access different Page
Setup options.
Note on PowerTalk(TM) and AOCE: The WordBasic Apple Open Collaboration
Environment (AOCE) commands require that PowerTalk be installed on
your Macintosh. PowerTalk is the client software for AOCE technology.
It is integrated into Apple's System 7 Pro and 7.5 operating systems.
AOCE facilitates collaboration among users through electronic mail,
voice mail, and fax messages.
STATEMENTS AND FUNCTIONS USED ONLY IN WINDOWS AND WINDOWS NT
============================================================
The following table lists WordBasic statements and functions that are
valid only when Word is running under Windows or Windows NT. The
commands listed below are not available and generate "Unknown Command"
errors when run under Word for the Macintosh.
Word for Windows and Windows NT Statements and Functions
--------------------------------------------------------
AppHide
AppMaximize
AppMaximize()
AppMinimize
AppMinimize()
AppMove
AppRestore
AppRestore()
AppSendMessage
AppShow
AppSize
AppWindowHeight
AppWindowHeight()
AppWindowPosLeft
AppWindowPosLeft()
AppWindowPosTop
AppWindowPosTop()
AppWindowWidth
AppWindowWidth()
Connect
ControlRun
Environ$()
ExitWindows
FilePrintSetup
HelpWordPerfectHelp
HelpWordPerfectHelpOptions
MicrosoftAccess
MicrosoftPublisher
MicrosoftSchedule
RunPrin(((TM)))anager
ToggleScribbleMode
MISCELLANEOUS WORDBASIC ISSUES
==============================
Using the GetProfileString$() function returns an invalid path setting
----------------------------------------------------------------------
Using the GetProfileString$() function to return a path setting in the
Word Settings (6) file results in a path that contains "garbage"
characters or symbols (that is, corruption).
To avoid having the function return unusable information, use the
GetPrivateProfileString$() function. For example:
Sub MAIN
a$=GetPrivateProfileString$("Microsoft Word", "USER-DOT-PATH",
"Word Settings (6)")
MsgBox a$
End Sub
Note that the GetPrivateProfileString$() function requires that the
settings file name be specified. In this case it is Word Settings (6).
When retrieving values from the Word Settings (6) file with the
GetPrivateProfileString$() function, do not specify a path for the
Word Settings (6) parameter because this path defaults to the
Preferences folder in the System folder.
Using WordBasic commands to control the size or position of a custom
dialog box returns WordBasic Error 135 in Word 6.0 for the Macintosh
--------------------------------------------------------------------
The following commands, which control the size or position of user
dialog boxes in Word 6.0 for Windows, are not available in Word 6.0
for the Macintosh and return errors:
AppSize
AppMove
AppWindowHeight
AppWindowWidth
AppWindowPosTop
AppWindowPosLeft
The AppSize command is used to control the height and width of a
custom dynamic dialog box by placing the dialog box in the case
structure of a dialog box function. (The case structure defines which
dialog box functions will be performed based on the user's input, or
action.)
The following AppSize command refers to the dialog box title, Title$,
as defined earlier in the initialization of the dialog box; and the
numbers refer to the width and height of the dialog box.
AppSize Title$ 300,400
The DlgFocus statement does not work in Word 6.0 for the Macintosh
------------------------------------------------------------------
The DlgFocus statement, which is used within a dialog box function to
set the focus on a dialog box control (for example, a push button)
while the dialog box is displayed, does not work in Word 6.0 for the
Macintosh.
When a dialog box control has the focus, it is active and responds to
keyboard input. Push buttons with the focus appear to have a darker
ring around them.
The command does not return a WordBasic error when the macro is run,
but the focus is not set to the desired control.
In the following example, the DlgFocus statement in Case 1 of the
dialog box function sets the focus to the control specified by
MyControl1. This statement sets the focus correctly in Word 6.0 for
Windows.
Sub Main
Begin Dialog UserDialog 320, 144, "Microsoft Word", .MyDlgFunction
OKButton 10, 6, 88, 21
CancelButton 10, 30, 88, 21
PushButton 57, 101, 88, 21, "Mybutton", .MyControl1
End Dialog
Dim dlg As UserDialog
x = Dialog(dlg)
End Sub
Function MyDlgFunction(identifier$, action, suppvalue)
Select Case action
Case 1
DlgFocus "MyControl1"
Case Else
End Select
End Function
Word for the Macintosh doesn't support selected SendKeys keystrokes
-------------------------------------------------------------------
The Word 6.0 for the Macintosh WordBasic macro language fails to send
certain noncharacter keystrokes when using the SendKeys statement. Due
to a system limitation, the full set of keystrokes are not supported
on the Macintosh. See online Help in Word for a list of keystrokes
that are supported.
Word for the Macintosh doesn't display underlined access keys
-------------------------------------------------------------
When you create a user dialog box with WordBasic and run the macro
that contains the dialog box in Word for the Macintosh, designated
access keys (or shortcut keys) do not appear with an underline.
However, although the characters are not underlined, the access keys
do, in fact, work as expected. After the user presses the COMMAND
key for a moment, an underline will appear under the specified
characters. (It is not necessary to "turn on" the underline in
Word 6.0 for Windows; the access keys are always underlined.)
NOTE: You can add access keys to a dialog box to allow quick access to
items from the keyboard. When an access key is defined for an item in
a user dialog box, the user can press COMMAND + the specified
character to select or clear a check box, pull down a list, or choose
a command button. You can specify the access letter in the WordBasic
Dialog Editor by typing an ampersand in front of the letter in the
Text$ box; for example, "C&heck Box" in line 6 of the macro below
will display an underscored "h" in the dialog box.
To automatically display shortcut keys in a dialog box upon running a
macro (without the user having to first press the COMMAND key), add a
MenuMode statement to the macro. To see how to add the MenuMode
statement, see the example below.
Sub MAIN
MenuMode
Begin Dialog UserDialog 320,144, "Microsoft Word"
OKButton 10, 6, 88, 21
CancelButton 10, 30, 88, 21
CheckBox 150, 84, 100, 18, "C&heck Box", .CheckBox1
End Dialog
Dim dlg As UserDialog
n = Dialog(dlg)
End Sub
WordBasic sort order and table ANSI sort order are not the same
---------------------------------------------------------------
WordBasic uses a different ANSI character sort order than that used by
the Sort Text command on the Table menu in Word.
Furthermore, the ANSI character sort order differs between Word for
the Macintosh and Word for Windows, both for WordBasic and for the
Sort Text command. In other words, there are four different ANSI
character sort orders.
The specific sort order of ANSI characters is relevant when you write
WordBasic macros that compare items based on their sort order. The
sort order is predictable for alphabetic and numeric characters (for
example, A comes before B, 3 comes before 4, and so forth). However,
the sort order for the remaining characters is not predictable, so a
sort order list is helpful. For example, to determine whether "!" is
greater or less than "?", you must refer to a sort order list (or run
a SortArray macro to sort the characters).
The following macro determines the WordBasic sort order of ANSI
characters and inserts into the open document each character followed
by a tab and the corresponding ASCII code value.
Sub MAIN
REM Construct a 2 variable array
Dim c$(255), a(255)
For i = 1 To 255
c$(i) = Chr$(i)
a(i) = I
Next i
REM Compares 2 characters at a time to determine sort order
For i = 1 To 254
For j = i + 1 To 255
If c$(i) > c$(j) Then
REM If 1st var > than 2nd var compared then switch them
temp$ = c$(i)
c$(i) = c$(j)
c$(j) = temp$
temp = a(i)
a(i) = a(j)
a(j) = temp
REM Inserts the characters and their values in a document
Print i, j
EndIf
Next j
Next i
For i = 1 To 255
Insert c$(i) + Chr$(9) + Str$(a(i))
InsertPara
Next i
End Sub
To determine the table sort order, select the characters that have
been inserted into a document as a result of the above macro, convert
the tab-delimited text to a two-column table, and sort on the first
column.
Certain GetSystemInfo$() function types
are different when used in Word for Windows NT
----------------------------------------------
Using the following function types with GetSystemInfo$() in Word for
Windows NT return an empty string:
- Type 23. With Word for Windows, type 23 returns the MS-DOS version
number. With Word for Windows NT, type 23 returns an empty string
because Windows NT does not run with MS-DOS.
- Type 25. With Word for Windows, type 25 returns the percent of
system resources available. With Word for Windows NT, type 23
returns an empty string because Windows NT does not have resource
restrictions as Windows does.
- Type 27. With Word for Windows, type 27 returns the mode under
which Windows is running: "standard" or "386 enhanced." With Word
for Windows NT, type 27 returns an empty string because Windows
mode Windows NT does not have a standard or 386 enhanced mode as
Windows 3.x does.
Additional query words:
Keywords : kbappnote kbfile kbmacro winword ntword macword word6
Issue type :
Technology : kbWordSearch kbWordWSearch kbWordMSearch
Last Reviewed: November 4, 2000 |
