Re: CLIP and OOM and WInword

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Si Wright  on Sun, 22 Jan 2006 00:09:53 -0800 (PST)

> We can STET the CLIP situation if you want. Now I'd actually be more interested
> in SA/RTF . At the moment, it says DONE but I don't see an .RTF file.

No -- let's get to the bottom of this, we're close. I can just about guarantee
that AWAITFILE is the problem -- there's no other loop in the code after
CLIP.EXE is called to perform the Paste. And lucky for me, both AWAITFILE and
SA/RTF are Carl's frames! I've had problems with AWAITFILE hanging in the
past, but I never had a problem with it using Clip, and AWAITFILE is the
fastest way to go. The problem is this: AWAITFILE's job is to wait for a
filename to appear in the directory; if it doesn't find it, it pauses for 1
second, loops around and looks again -- keeps looping for up to (default) 30
seconds (duration adjustable at runtime) until the file shows up; then
AWAITFILE exits, thereby tossing you back into the parent program (here, frame
CLIPW*) which continues execution. It's a simple idea, and it usually works
just fine; but occasionally (and aggravated if so-called "lazy writes" are
enabled, which I think XP enables by default) Windows opens the file in the
directory -- it appears in the DIR listing -- but the file is still being
written to when AWAITFILE detects its presence. In other words, the file isn't
yet closed by the program that is writing the file (here, CLIP.EXE). So
AWAITFILE exits, ClipW* tries to call the file, gets a file system sharing
error, and hangs.

I identified this problem years ago, and I wrote a fix for it called AWAITREN.
AWAITREN works more or less the same way AWAITFILE works (it just adopts Carl's
code entire), but after the file is written it RENames the file. This exploits
a peculiarity of DOS: a file may show up in a DIR listing even while it is
being written, but DOS simply will not allow that file to be RENamed until the
file system handle to the file is closed, i.e. until it is completely written.
So AWAITREN, instead of looking for the file in the directory, tries to REName
the file; if DOS won't let it do that yet, it loops until it can. Its an
ironclad fix, for this particular problem anyway. Unfortunately, it takes more
time, probably measured in nanoseconds, but occasionally amounting to a second
or so (performing an additional loop -- although this loop would probably be
required anyway, were AWAITFILE doing its job *properly*). And it requires
another filename and different manipulations. But let's try it, this may be
the heart of your problem. And if you have this problem, so perhaps will other
users.

I've posted this to XyWWWeb in a new XYWEB119.ZIP. DL the package, unZIP U2
(and INF) into your XyWrite dir, and *relaunch* XyWrite. Lemme know... if it
doesn't work, I'll switch back to the old method.

And BTW, Jon, make sure you change your Copy key assignment ALSO (not just your
Paste key) to specify which operation to perform -- for Copy, it should be:
 nn=NOJM2,.,c,l,i,p,w,c,Q2
unless it is in the ALT table, in which case it should be:
 nn=NIJM2,.,c,l,i,p,w,c,Q2
(NI instead of NO). In other words, for best & most reliable results you
should be using two separate keys! One for Paste, another for Copy, and
potentially a third for "cut" a.k.a. Replace, nn=NOJM2,.,c,l,i,p,w,r,Q2 .
Inter alia, you can't copy a CMline with just the all-purpose single-key
assignment "c,l,i,p,w", and you also don't need to be as particular about
whether DeFined blocks are active or not. And you can mimic the Windows keys
Ctrl-C|V|X. Etc. etc.

-----------------------------
Robert Holmgren
holmgren@xxxxxxxx
-----------------------------