If you've used WordPerfect for Windows for a while, chances are you will eventually have to convert a macro created in a Windows 3.1 version of WordPerfect to a Windows 95/98/NT version of WordPerfect. This article will help you be aware of the common problems that you might run into in converting your macros.
In many cases, macros will convert straight across without any problems. But more complex macros may prove to be challenging to convert.
First, Recompile
Macros created in WPWin 6.x cannot be run in a different version of WordPerfect without first being recompiled. So, the first step is to open the macro in the new version of WordPerfect. If you don't see the macro toolbar after opening an older macro, click Tools > Macro > Macro Toolbar to turn it on. Then click the Save & Compile button.
(Note: If converting macros from WPWin 7 to WPWin 8, you'll need to recompile your macros in WPWin 8 to have them work properly in WPWin 8, but you are not likely to have as many problems as when converting from WPWin 6.x to WPWin 7/8 for Windows 95.)
If all goes well, no errors will appear, and your macro will be ready for a test run. Most commands that are used in earlier macros will convert over with no errors, so if the macro isn't too complicated, you're all set. But some Gotcha's can happen. Here are a few things to check.
If you get errors, tackle each message as you get them. Determine the problem, fix it, and recompile. Now let's discuss some of the errors that may occur.
Reserved Words
There are some new commands in WPWin 7 and 8. If you used the names of the new commands as variable or subroutine names, you're in for a bit of trouble. Once you have the problem isolated, though, it is easy to fix.
For example, if your macro calls a custom PROCEDURE called PrintDoc, an error will occur when you compile in WPWin 8, because there is a new command named PrintDoc in that version.
Or, if you used a variable called MAX in a macro, you'll need to change the variable's name to something like vMAX, since MAX is a reserved word in later versions.If your syntax looks OK, but the compiler insists there is an error, you may be using a reserved word. Check in the Command Inserter to see if a new command by the name of your label, PROCEDURE, or FUNCTION exists. You can also check the Reserved Word list in my book, or in the WordPerfect Macros online help. If it does, just rename your subroutine, then search through the entire macro for any instances of calling that procedure and change the name there also.
DLL Calls
There are several issues that may occur in macros that use DLL calls.
WP Shared Code
WordPerfect 6, 7, and 8 all use different versions of shared code. So if your macro calls a DLL function from the WordPerfect shared code, you'll need to change the name of the shared code library in the DLLLoad or DLLCall Prototype command.
The table below shows the filenames of the shared code libraries for the various versions of WPWin. Normally, you can just change the name of the shared library in the DLLLoad or DLLCall prototype command to correct errors caused by upgrading to a newer version of WPWin.
| WPWin 6.a/6.1/7 for Windows 3.1 | SHWIN20.DLL |
| WPWin 7 for Windows 95 | SHWIN70.DLL |
| WPWin 8 for Windows 95 | PFIT80.DLL |
LOWORD Values
Often in DLL calls used in WPWin 6.x macros, parameters were passed in to the DLL call with a modifier such as LOWORD or HIWORD. This was because Windows 3.1 required values in a 16-bit format, while WPWin stored values in a 32-bit format, even if there was only 16 bits of pertinent information. The LOWORD modifier told WordPerfect to pass just 16 bits of the information on to Windows 3.1.
But in Windows 95, you want to pass the entire 32 bits of a value to Windows. In most cases, you can just remove the LOWORD modifier from the DLL call.
SendMessage messages
Many WPWin 6.x macros used DLL calls to a function called SendMessage to perform tasks that weren't built in to WPWin. In Windows 95, a new command called SendMessageA was added. You should change the SendMessage functions in your macros to SendMessageA.
WordPerfect 7/8 for Windows 95 have new built-in commands that perform most of the same functions that you had to use DLL SendMessage calls for in WPWin 6.x. Where possible, you should convert your macros to use the built-in functions rather than using the DLL calls.
Many of the values that you passed into a SendMessage in WPWin 6.x have been changed in Windows 95. If there is not an equivalent built-in command for a particular SendMessage call, you'll need to determine what message was being sent in the Win 3.1 version of the macro, then find the correct value for that function in Windows 95.
The table below lists a few commonly-used SendMessage values, their Windows 3.1 value, their equivalent Windows 95 value, and the built-in PerfectScript command that can be used instead of the SendMessage command.
( See your Windows API documentation for description and full parameter requirements for each specific message.)
| Message | Win 3.1 Value | Win 95 value | WPWin command |
| LB_RESETCONTENT | 1029 | 388 | RegionResetList |
| LB_SETCURSEL | 1031 | 390 | RegionSelectListItem |
| LB_GETCURSEL | 1033 | 392 | RegionGetSelectedText |
| LB_GETCOUNT | 1036 | 395 | RegionGetListCount |
BIF vs INI vs Registry
WPWin 6.x used a binary Information File (BIF) for storing information. The BIF file was prone to becoming corrupted, and was less capable than the Windows 95 Registry, so starting with WPWin 7 for Win 95, WordPerfect itself no longer uses the BIF file. instead, it stores settings information in the Windows Registry.
PerfectScript still includes commands to write to and read from a BIF file, but I recommend that you convert your code to use the Registry to store data. Or, in the case where the data must be shared over a network by more than one person, store your data in an INI file.
True(er) Multitasking
Windows 95 does a better job at multitasking than Windows 3.1 did. But this causes some problems in certain types of macros.
For example, sometimes dialogs such as the PROMPT dialog, or a macro dialog will be displayed, but it will be behind the WordPerfect window. Since you can't see the dialog, it may appear as though WordPerfect has hung. But in reality it is just waiting for user input before it continues.
If this happens to you, press Alt+Tab a few times to see if you can get the dialog back on top. Sometimes the dialog will appear as an icon on the Task bar, which you can simply click to bring it forward. You can also use a DLL call to bring a window back to the top programmatically.
You may incorporate this routine in your own macros as needed
// This command goes at the point where you want to set a window as the foreground
SetWindow("caption of window")
// ******************************************
// SetWindow; brings the specified window to the front
// Input: The caption from the title bar of the window to bring forward
//********************************************
PROCEDURE SetWindow(vCaption) vhWnd:=Applocate(vCaption)
If(vhWnd > 32)
DLLCall Prototype SetWinFocus("user32"; "SetForegroundWindow"; Dword!; {hWnd})
SetWinFocus(vhWnd)
Endif
ENDPROC
Other Problems
Other conversion issues may crop up when you are attempting to convert macros. Obviously, the more complex the macro, the more likelihood of your having problems getting an earlier macro to work properly in a newer version of WPWin. The most common problems are covered in this article. With persistence, most problems can be overcome.
For a more complete list of SendMessage values, info on storing data to an INI file, get a copy of my WPWin 8 book. For information on storing data in the Registry, see the back issues of the PerfectScript Journal.
For information on ordering my book see my web page.