WPLOG32.ZIP   Four WordPerfect 5.2 for OS/2 and Windows macros

LOGMAC32.ZIP Different in name only (same macros) to differentiate between 
the Windows and OS/2 WordPerfect versions.  Depending on how the macro 
language changes between future releases of WPWin and WPOS/2, Windows 
compatibility may be discontinued - assuming, of course, I come up with
any other 'bright' ideas.

LogFiles.WCM
------------
        This macro will first cycle through all open documents, making note
of their names to be displayed in the LogFiles menu.  The user can then
click upon the files he/she would like excluded from the logging process.  
A maximum thirty-five character Work Profile name (see A Note About 
Profiles) is then assigned which identifies the group of logged files.  
Once the user clicks 'OK', the macro begins to log all selected files, 
adding the doc.'s name and cursor location in WPWP.INI.  With version
3.2, it is now possible to select which documents you would like closed as 
well as logged.  Thus, if you have 4 docs opened, you can have the macro 
log docs.  1-3, but close only docs. 2 and 4. This feature is not
available if the LogFiles menu has been turned off in LogState.
        Also new to version 3.2 is the elimination of the 4 Work-Profile
limit.  As a result, two more buttons have been added to LogFiles' dialog
box - Delete Profile and Edit Name.  The first deletes all the logging
information from the given profile, but leaves the [LogProfile] section in 
WPWP.INI with the single line ProfName=Free.  If/when you create another 
Work Profile, the macro will either add the information to the first 
[LogProfile] section with a ProfName=Free key or create another section if 
none is found.  The second button brings up another dialog box in which you 
can rename/edit the displayed Work Profile name.  This does not overwrite 
the logged information, simply the name which identifies that particular 
Work Profile.  
        LogFiles now minimizes the documents as the filenames are read. 
This not only improves performance by eliminating the need for WP to 
perform screen redraws, but it also helps to see exactly what's going on.  
With the addition of the Close Selective docs. feature, knowing what 
remains opened is important, especially if you intend to Resume another 
Work Profile.  Doc. windows can be returned to a previous state upon
macro completion (see LogState.WCM).
        It also struck me that it would be advantageous to have specific
profiles automatically resume in Express Mode, regardless of the default
setting in LogState's group box.  As a result, a check box has been added
below the Profile list box. This addition necessitated yet another addition,
mentioned in the next paragraph.
        The other addition is a mode overide.  If the Menu Prompt is
selected in LogState (the default setting), or if the specific profile
has not been marked as Express in LogFiles, you have a certain amount
of time when the macro first runs to switch to Express Mode.  The same
holds true for Express - hitting the ESC key will initiate a mode
opposite to the one that is currently active.

Resume.WCM
----------
        Resume reads the logged filenames in the selected Work Profile in
WPWP.INI and displays the filenames in a menu.  The user can choose to 
exclude some of the docs. from the list or fetch a different profile.  
Once 'OK' is selected, the macro opens the selected files and, using the 
cursor-location information logged previously, returns the cursor to its 
position when the file was originally logged.  You can use the Work 
Profiles generated by version 3.0.  If the macro is unable to retrieve the 
cursor information, a brief message will appear informing you of the 
problem, the cursor will remain at the top of the document, and the macro 
will resume operation.  You'll have to hunt up the [Comment | Logged[x]] 
(where [x] is either 1, 2, 3, or 4) yourself and remove it manually.  
Logging the file with version 3.1 and above will add the necessary 
information to the Work Profile in WPWP.INI.  
        As in version 3.0, if a file has been deleted or renamed by the
user between the LogFiles and Resume processes, the macro will simply 
inform the user that the file in question could not be opened, and resume 
operation.  
        If you would rather do without the cursor repositioning feature,
click on the radio button marked Leave Cursor at Top in LogState's Cursor 
Repositioning group box.  If repositioning is turned off, the cursor will 
remain at the top of the document after it has been opened by Resume.  You 
can also turn Position and Line repositioning off.  See the description for 
LogState for more on this.  As a result of the addition of the Close 
Selective docs. feature, Resume first cascades all opened docs., which 
allows you to see what docs are currently opened to avoid opening a doc.
that is already so.  Doc. windows can be returned to a previous state upon
macro completion (see LogState.WCM).  If you happen to select a file that is
opened, Resume will try to open it.  In the OS/2 version, at least, WP
gives you the choice of either cancelling the doc. opening or going ahead
and opening it as a read-only file.  Opening it isn't a problem, but 
choosing not to load it is.  It sends an Error message to Resume, which 
causes the macro to branch to an ONERROR label which I used in case a user 
attempted to open more docs. than WP would allow.  There was no way out of 
this catch-22 as far as I could see except by issuing an ONERROR CALL 
statement before the files are loaded.  In that case, if you do try to open 
a file that is already opened, and you choose not to load it when WP 
prompts you, the error message will be diverted away from the official 
error label.  In essence, this means that the macro will continue loading 
the files checked off in Resume's menu, but if you try to exceed the doc.  
limit, you won't get a warning telling you that such-and-such a file was 
not opened.  Instead, the macro will end abruptly but peacefully.  It was
one or the other, and I thought the one was more useful than the other.
        One final addition is a mode overide.  If the Menu Prompt is
selected in LogState (the default setting), or if the specific profile
has not been marked as Express in LogFiles, you have a certain amount
of time when the macro first runs to switch to Express Mode.  The same
holds true for Express - hitting the ESC key will initiate a mode
opposite to the one that is currently active.

LogState.WCM
------------
        This macro allows the user to specify whether the File-Selection
prompt should appear when LogFiles and Resume are run.  LogState can be run 
from either of the two other macros in order to configure LogFiles and 
Resume.  N.B. The macro must first be compiled; otherwise, an error 
message will be generated by WP.  To turn File-Selection prompts back on,
run LogState again.  Turning the File-Selection prompt Off will not give 
you access to the Work Profiles or Selective doc. closing in LogFiles, 
however.  The last Work Profile you selected will be active until it is 
changed.  Alternatively, you can press the ESC key when LogFiles or Resume
first run in order to access the Interactive mode for that specific session.
        New to version 3.2 is the Close Documents at Log Time menu.
Selecting Close All Documents simply checks off all the documents that are 
listed in LogFiles' dialog box.  Selecting Close Selective Documents simply 
leaves the check boxes empty in LogFiles' dialog box.  If File-Selection 
menus are turned off, Logfiles will log and close all opened documents.  
        Also new to version 3.2 is the ability to launch LogFiles or Resume
directly from LogState.  N.B. Both macros must first be compiled in order 
to launch them directly from LogState; otherwise, WP will generete an error 
message, and LogState will terminate.  After you've made your menu 
selections, clicking on either the LogFiles or Resume button will first 
save the LogState selections to WPWP.INI and then launch LogFiles or 
Resume.  
        As stated above, LogState can also turn Position or Line and
Position repositioning off or shorten the timeout length.  This is 
accomplished by clicking on the Timeouts button.  When cursor repositioning 
is selected, the cursor first moves to the page logged in WPWP.INI.  The 
macro then looks at the line number and estimates whether it lies on the 
top or bottom half of the page.  If at the bottom, the cursor is 
repositioned to the bottom of the page and counting begins from there, 
moving up one line at a time.  Finally, the macro attempts to match the 
cursor location with that found in WPWP.INI.  Like the line repositioning, 
character repositioning first estimates whether the cursor should go in the 
first or the second half of the line.  If the first half, then the cursor 
is moved to the right one character at time.  For these reasons, Line and 
Position Counters in the Cursor Repositioning Timeout dialog box cannot 
exceed 50.  There wouldn't be much point in specifying a larger number, 
since it would take too long for a timeout to occur if the cursor was 
unable to find its previous location, and most sheets of paper will only 
hold a maximum of 80 characters by 66 lines.  To turn either Line or 
Position repositioning off, change the number in the appropriate counter to 
1. This will also disable the Timeout error message in Resume.  I added 
these timeout procedures to take into account significant editing of a 
document between logging processes and possible errors in WP's reporting 
cursor location (this happened to me once).  For example, if the first log 
reports cursor location on Pg 10, Ln 6.67", and Pos 3.68", but you delete 
everything from Pg 10, Ln 1.00" on later and then try to Resume the 
document still later, obviously, the cursor will never find its old 
location.  The repositioning loop would go on endlessly since it would 
continue looking for a Ln number it could never reach.  This is a problem 
only for Ln and Pos repositioning.  To avoid a possible conflict, I've also 
added a small verification routine when the Page reposition is executed.  
If, using the previous example, you deleted everything from Pg 9 on, the 
cursor would first land on Pg 9 without giving an error, and start looking 
for the old cursor location on the wrong page.  To prevent this, the macro 
checks the page number it lands on.  If it doesn't match the logged page 
number, repositioning stops and the cursor remains on whichever page it 
happens to be when the error occurs.
        Two additional group boxes have been added to version 2.0, both of
which set document window behaviour upon completion of LogFiles and Resume.
In LogFiles, the doc. windows are normally left minized.  You can change
this by clicking on a specific radio button, either Maximize, Tile, Cascade,
or Minimize.  In Resume, doc. windows are normally left cascaded.  By
clicking on the appropriate radio button in LogState, you can have Resume
maximize the doc. windows upon exit, or, alternatively, have the doc.
windows tiled or cascaded (if anyone feels a need to have docs. minimize
themselves upon macro completion, drop me a line and I'll implement it).
        The behaviour of the 'Timeouts' push button has also been altered to
reflect the state of the 'Leave Cursor at Top' radio button in the 'Cursor 
Repositioning' group box.  If it is, the 'Timeouts' button will read 
'Refresh Dialog Box' rather than 'Timeouts...'.  This serves two purposes:  
to avoid confusion if the 'Leave Cursor at Top' button is selected 
(in which case Timeouts are irrelevant) and to have the macro redraw 
the dialog box in the event that the 'Leave Cursor at Top' radio 
button is deselected and the user desires to change timeout defaults.

MenuLog.WCM
-----------
        This is a small macro that will add the above three macros to
WordPerfect's File menu.  If you're like me, you're not overly fond of 
using a mouse and/or a button bar.  By running this macro, you can press 
the Alt+F, / keys to gain easy access to LogFiles, Resume, or LogState.  If 
you haven't got the /m-macroname switch already when launching WP, just add 
it as a parameter, e.g.  /m-menulog.  If you've already got a startup 
macro, simply add a Run statement at the end of the original startup macro, 
e.g.  Run("macropath\menulog.wcm") where macropath is the location of the 
MenuLog macro.  It is important that the Run statement be last (before a 
Quit statement, obviously), because MenuLog ends with a Return statement, 
which is required by LogState.  The reason why LogState calls MenuLog is 
that the Document Logging and Resume Profile submenus reflect the state of 
menu prompts.  If you turn Resume's File-menu prompt off, for example, the 
submenu item will read 'Resume Profile... - Express' as opposed to simply
'Resume Profile...' This is to help people like myself with short 
memories.  There shouldn't be a problem if you've got some of your own 
items added to the File Menu, because MenuLog attempts to add the 'Log /
Resume' item only immediately after Save As...; if it encounters an 
error, it tries to delete an item bearing the 'Log / Resume' name and then
attempts, once again, to add 'Log / Resume' to the File Menu.  If you
encounter difficulties (like MenuLog appearing to be caught in an endless 
loop), try including your own items in MenuLog and then running it.  By 
default, MenuLog is not invoked by LogState.  If you would like to have 
LogState add and dynamically update the 'Log / Resume' menu item in WP's 
File Menu, click on the Menu button in LogState, and click on the 'Add Log 
/ Resume to File Menu' checkbox.  

A Note About Profiles
---------------------
        By 'profile' I mean a working environment.  It's easier to think of
Work Profiles as different projects you are working on.  LogProfile2, for 
example, could contain the documents you had opened while working on 
Chapter Two of a book, whereas LogProfile1 could contain the document list 
from your work on an article you intend to continue at a later time.  All 
Profiles are user-definable in that the user can assign a descriptive name 
of up to 35 characters to each profile.  Using the above example, 
LogProfile2 could be be named 'Chapter Two' and LogProfile1 'Article - 
needs a conclusion'.  In LogFiles, the profile names can be edited (by 
pressing the 'Edit Names...' button) or you can add a new Work Profile
simply by typing a new name in the drop box.  In Resume, profiles cannot be
changed - what you see is what WPWP.INI reports.


Cleaning up WPWP.INI
--------------------
        If you've used a version of LogFiles earlier than 3.0, you'll have
to clean up your WPWP.INI file unless you don't mind having useless 
information stored in it.  WPWP.INI is normally stored in your \os2 
directory for OS/2 users, \os2\mdos\winos2 directory for WinOS/2 users, or 
\windows directory for Windows users.  Open the file using any ASCII text 
editor, and delete the section called [Log-Resume].  It should look 
something like this:  

          [Log-Resume]
          Doc1=[the document name goes here]
          Doc2=[ditto]
          NumberOfFiles=2

The reason for this cleanup is that version 3.x of LogFiles and Resume 
looks for sections called [LogProfile{x}], where {x} is a number from 1
up. The keys in the [LogProfile{x}] sections remain the same except for a
few additions.  Once you've made the appropriate deletion, save WPWP.INI 
as an ASCII file.  Note, however, that some ASCII editors leave an 
end-of-file marker (^Z) at the end of the file.  If this is the case, 
the macros will continue to function, but if you try editing WPWP.INI, 
you won't see what lies beyond the ^Z mark.  For OS/2 users, bear in 
mind, also, that long filenames may be wrapped to the next line, and 
the text editor may append a CR/LF code at the end of the first line, 
thereby effectively truncating the filename.  If this happens, Resume 
will report a file-not-found error.  

Bugs
----
        There are no known bugs, except for those that are generated by WP
for OS/2 5.2.  According to WPOS/2 Tech. support, the inability to use
mnemonics as short-cuts to various options in a menu has been documented 
and is expected to be corrected in a later release (perhaps 6.0).  
Similarly, pressing <Enter> to proceed or <Esc> to dismiss a dialog box
do not function properly.  This falls under the mnemonic bug just mentioned.
A pointing device, therefore, is required.  As far as I know, none of this
Applies to WPWin 5.2.  
        For some reason the 'Yes!' parameter in the FileSave(Variable; 
WordPerfect51!; Yes!)  command does not overwrite an existing file without 
prompting the user as it's supposed to; instead, it invariably brings up 
the FileSaveAs dialog box at least on my system.  Omitting the Yes! parameter 
seems to have cleared up the problem, but it may need to be added in an 
interim or future releases of WP for OS/2 and/or for WPWin 5.2.  If you 
find a bug, please contact me at

        G9026163@mcmail.cis.McMaster.CA

The address should be valid for the next year or so.  
        What is known are the following limitations:  if you use accented 
characters in your filenames, Resume may choke (and bring WordPerfect down 
with it).  This may only be a limitation on the OS/2 version - I haven't 
tried it on WPWin.  If you're a rapid mouse clicker, one of the macros may 
go into Pause mode (this usually happens only with LogState).  If it appears 
that a macro isn't doing anything, check WordPerfect's Macro menu.  If you 
see a check mark beside the Pause option, simply click on it to uncheck 
Pause and the macro will resume.  

Acknowledgments
---------------
        I'm not much of a programmer.  My motto is, if it works, great.
Many thanks must go to Ulrich Brinkman, who, way back in March '93 
suggested using the DLLCall command to write and read the information to 
WPWP.INI instead of to a WP document as I had originally done.  Richard 
Reiner is largely responsible for version 3.0 of the WPWin set, since he 
graciously permitted me to mofidy his LastFour macro, thereby allowing the 
user to select the files he/she wants logged and/or reopened.  He also 
permitted me to modify his NamedMrk macro to search for a specific 
[Comment] rather than simply any [Comment] in the same version.  Richard 
has also been exceptionally patient with me in helping to debug the various 
macros and full of ideas for improvements.  

Revision History:
================
Logfiles.WCM
------------
        1.0:    (Feb. '93) Initial WPWin 5.2 release.
        1.1:    Added If statement to correct the creation of a blank
                document if only one doc. is logged.
        2.0:    (Mar.  '93) Ulrich Brinkmann's implementation of DLLCall
                code to log files in WPWP.INI.  
        3.0:    (Jul.  '93) Incorporated and modified some of Richard
                Reiner's LastFour.WCM code to allow user either to log all
                currently opened documents or a selection.  Replaced two
                consecutive [Comment] codes by one [Comment] containing the
                string 'Logged[x]', where '[x]' is a number from 1 to 4.
                R.R.'s code for extracting the contents of a [Comment],
                comparing it to a specified string, and deciding whether 
                the [Comment] is the one we want or whether the macro
                should keep looking makes the one [Comment] possible. 
                Added the ability to bypass the File-Selection menu.  
                Added max. 4 user-defined profiles.  
                (Aug.  '93) Some modifications made for WPOS/2 5.2, to
                accommodate HPFS and the quirky way WPOS/2 cycles
                through open docs.  'Previous Doc' doesn't seem to
                do what it's supposed to, i.e.  it doesn't work at all! 
        3.1:    (Aug.  '93) Did away with the [Comment] method of keeping
                track of the cursor location altogether, which allowed me
                to bypass the Save() command if a document has not been
                modified a real time-saver in the long run!  
                Added a small checking routine to ensure that the cursor is
                at the MainEditScreen before proceeding with the logging
                process.  This is necessary if, for example, the cursor is
                in a Foot/Endnote.  If it is, a Close() command is issued,
                and the cursor returns to MainEditScreen.  
        3.2:    (Sept. '93) Added Selective Doc. Closing in LogFiles menu
                (this feature is not available if you've turned the menu
                off in LogState).  Also added a DocMinimize() command to
                speed processing up a little and to allow the user to see
                which docs. remain open after the logging process.  Removed
                the 4 Work-Profile limit and added the Delete and Edit
                buttons.  Improved some of the code for more reliable
                performance and eliminated the NumberOfFiles= key for each
                [LogProfile]. Eliminated redundant code.
                Added doc. window behaviour upon completion of macro.
                (Oct. '93) Added the 'Resume - Express' checkbox and the
                manual overide.

Resume.WCM
----------
        1.0:    (Feb. '93) Initial Release.
        2.0:    (Mar. '93) Ulrich Brinkmann's implementation of DLLCall 
                code to fetch the filenames from WPWP.INI before opening.
        3.0:    (Jul. '93) Inclusion of Richard Reiner's code from
                LastFour.WCM to enable user to select what docs. he/she
                would like opened.
                Improved error handling Abort! message no longer 
                encountered if full document roster is used;
                Resume won't grind to a halt if a file to be reopened no
                longer exists Added the ability to bypass the 
                File-Selection menu. Added max. four user-defined profiles.
                (Aug. '93) Some modifications for the WPOS/2 5.2 version, 
                to accommodate HPFS.
        3.1:    (Aug. '93) By eliminating the [Comment] method of keeping
                track of the cursor location at log time, I've managed to
                shave 30 seconds off a two document resumption (a small,
                informal, and very unscientific in-house test).  Of course,
                if cursor repositioning is turned off, you'll shave even
                more off processing time.
        3.2:    (Sept. '93) Added a WindowCascade() command so that the 
                user can see the documents that are being opened, and
                choose the one he/she would like to edit after Resume is
                complete. I think clicking on the Maximize button is easier
                than going the Window | Doc. menu route.
                Added timeout routines for cursor relocation.
                Eliminated redundant code.
                Added doc. window behaviour upon completion of macro.
                (Oct. '93) Implemented the mode overide in accordance with
                the profile-specific express mode.

LogState.WCM
------------
        1.0:    (Jul. '93) Initial release as LogPrmpt.WCM
                (Aug. '93) Added ability to turn cursor repositioning ON or
                OFF
                Name change from LogPrmpt.WCM to LogState.WCM to reflect
                additional function.
        2.0:    (Sept. '93) Added ability to run LogFiles and Resume
                directly from LogState. Added Close Documents at Log Time
                items.
                Added the Repositioning push button and accompanying
                dialog box to configure the cursor repositioning timeout
                parameters for Line and Position.
                Added the  Menu  button and dialog box to activate MenuLog
                whenever LogState is run.
                Added the LogFiles and Resume Document Window group boxes.
                Changed the behaviour of the 'Timeouts...' push button to
                reflect the state of the 'Leave Cursor at Top' radio button.

MenuLog.WCM
-----------
        1.0     (Sept. '93) Initial release

Paul H. Caron                                G9026163@mcmail.cis.McMaster.CA 
(3 October 1993)
