Re-opening files (Robert's response)

[TBaehr@xxxxxxxx]

Robert, you're right -- I use command override in a U2 file as
part of my routine for re-opening files. You bring up some
thought-provoking and important issues. Here is my response to
your response.

My goal in creating the capability was several-fold. 1. I wanted
to make the process of recording information automatic and
totally invisible to the user.
All the same commands and dialog boxes would appear to operate as they do
"out of the box." 2. I was suffering from 'feature envy' -- most
other applications list at least the last 4 files opened. 3. I
love making XyWrite howl a little by inveigling it to do what it
wasn't designed to do. I've been doing it since before I worked
for Xyquest and I'm still doing it now as an ex-employee. 4. I
wanted to extend the usual ability of other apps by giving the
user the ability to save info about endless numbers of files but
also prune or re-start the list at will. 5. I needed the feature
in my own work.

As for command override, I'm well aware of its dangers. The
tricky part was to get Call and New (and a bunch of other stuff)
to gather up command line arguments and pass them thru. There's
quite a bit of code I wrote for the original sample U2 file
(SAMPLE.SET) that allows a programmer to manage command-line
stuff including switches and arguments. I've had a couple of
commands backfire on me. In one, I got the Copy and Move
function calls to re-select the text at the destination -- as
some other applications do. But it was screwing up XyWrite's
internal routines. But for New and Call, there has been no
problem in running the command override in the past couple of
years. And I use XyWrite heavily -- at least several hours a
day. I see nothing wrong in appropriating existing XyWrite
capabilities as long as I leave their original functions intact.
But it is tricky.

I did create for the original Xy4 release a routine that saves
the state of all open files. Not as elaborate as Carl's, as you
describe it, since it doesn't save screen colors. It does store
window sizes and locations, and view modes for each file,
however, along with the other stuff like cursor position, delete
stack, save/get set, and bookmarks. Since this was a new
feature, I felt I could make it a separate routine and not try to
meld it in with some kind of shutdown routine. This is one feature I do use every day
-- switching from project to project and saving the state of each
one to a set of named session files.

I'm of two minds about reusable code. While it can be a great
time-saver, some of us really enjoy inventing stuff -- even if it means reinventing the
XPL wheel. And some of us have different goals: for instance, my
goal for making the file re-open routine invisible and automatic.
 There are some aspects of reusable code that I more unreservedly
endorse -- checking routines to see if a window is available,
little bits of code that strip off a file extension or identify
the path part of a filename, routines that split any string into
left and right portions, etc. We tried to get a lot of this
stuff into the "Global Subroutines" in XY4.DLG and its Windows
counterpart when we were develping it at Xyquest. One of my
long-term goals is to document this stuff for this XyWrite group
so that others can use it in their programming -- the attraction
being that this stuff is available out-of-the-box and anybody can
use it.

Thanks for your response. We may not always agree on the
details, but the exchange of ideas is always enlightening.