Re: UNDO

["Robert Holmgren" holmgren@xxxxxxxx]

** Reply to message from Harry Binswanger  on
Sat, 12 Jul 2008 18:33:45 -0400


> If you try to delete a read-only file

There are lots of reasons for "Access Denied" -- not just that.

> I think my "access denied" error is coming from XyWrite

Now wait a minute: you're not sure where "Access Denied" is
coming from? It isn't a XyWrite error, displaying on the
XyWrite PRompt line?? (Error # 217 or 365, spelt exactly this
way: "Access denied."?) Instead, it's a Windows error,
displayed in a Windows message box?? You have to click "OK" or
something to make that box disappear? Where exactly does this
error appear, and what does it say, including the Window Title.

UNDO.CTL appearing and disappearing is normal behavior: XyWrite
creates the file, UnDo.exe deletes it. The two programs are
_communicating_ with each other, Editor.exe==>UnDo.exe. Here,
XyWrite is passing the current filename to UnDo.exe.

> If I hold down the shift key, when the 10 seconds hit my
> keyboard is thrown into some inoperative state

Then don't use ScrollLock! Use one of those three other Numpad
keys I mentioned yesterday (6A, 6B, 6D). Unless you have a full
105-key keyboard, those three keys are basically too hard to
manipulate for most users, so they're "extra". XyWrite will
recognize them, even if you don't even know how to keystroke
them manually. That makes them ideal, actually. Put $T in
EVERY TABLE! You're using yesterday's U2 frames, right?

> in the inoperative state, I do not get the XPL code that
> you get when instituting TS

You removed func TS from key #70 -- you changed key #70 to
something else (func $T). So you're not going to see TS
behavior any more.

You don't have any XyWrite background programs running, right?
Are you SURE Tame is OFF?

> No backup files ever show up.

Try this: Kill UnDo.exe if running (KUD). Change REG
variable to "UnDoKeys=K" and SAve REG. Command
UNDO.INT. Command
"VA/NV @707" -- the PRompt line should display your
UnDoDepth value from REG (I think you were using 100 -- 100 is a
ridiculous number for test purposes, use 5 or 10 instead -- if
you have to wait for 100 backups to build up before you can
learn how UNDO and REDO recycle files, you'll have a mighty long
wait...).

Now, create in the current window a small dummy file -- give it
a name, e.g. NE DUMMY.TMP. Write a few lines of text.
Manually command on CMline: "$T". That should do the
first part only of the $K procedure (since $K calls $T first).
UnDo.exe will NOT be running, so it will not be accessing any
files. UNDO.INT will have wiped out everything in subdir
C:\XY\UD -- so you'll be "clean".

Now look in directory C:\XY\UD. Two files should be present,
DUMMY.BAK and UNDO.CTL. If you open UNDO.CTL, it should just
say "DUMMY" (now close UNDO.CTL!). If you open DUMMY.BAK, it
should be a copy of whatever was in your current window, whether
you SAved DUMMY.TMP or not. Close DUMMY.BAK -- just close these
two files, don't erase them! Note the file length of DUMMY.BAK.

If that is all correct, then command this manually:
 dos/nv/x/z /c kmd/c start /min C:\XY\UnDo.exe K 100
That's , NOT !!

Now look again in directory C:\XY\UD. One file only should be
present, DUMMY.001 (which is DUMMY.BAK renamed as DUMMY.001 --
same file length as DUMMY.BAK had).

If you do NOT get these results, then issue KUD and
UNDO.INT again manually, and start debugging frame $T.
Here's how:

Make a copy of the frame and put it ABOVE the original $T frame.
So now you've got two $T frames, one above the other.
LOADHELP. Now we'll modify the FIRST version only --
leave the (second) original untouched so you can restore it
later.

Clear the CMline and hit carriage return. That should generate
Error #11, "There is no command on command line." So error 11
becomes your standard reference for the current error state --
as long as no new error occurs,  will continue to report
error 11. Now, instead of debugging with , let's use
something that yields actual value:
>. Keep moving that code
through $T, top to bottom. If the error value changes from
"11", it tells us something. I get no new errors: VA$ER is
still 11 at the end of $T.

Now, look: when you did this the last time (with ), you
got a false result: you put your debug code  right after
the statement
 {240}"[">...
and then you got "Access Denied". But IS02 (current filename)
was NOT an [UNTITLED] file, so that whole  clause
was SKIPPED, and all you really got was "Access Denied" at the
END of the frame, or somewhere else within the frame, but NOT at
that point. Clearly, there is nothing wrong with the statement
"If IS02 contains [" -- that is NOT the source of your problem.
You need to examine frame $T carefully, and put your debug code
at the end of nested  clauses, not in the bloody
middle of them unless you are 100% SURE that you are actually
travelling through the  clause. Now, if you can't
figure out how the nesting works, then DeFine the whole frame
$T, CoPy it to an [UNTITLED] window, command IFEI, then
hit your "Y" key, to see a structured listing of the frame. 

Follow these instructions carefully. Let me know.

R.

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