[Date Prev][Date Next][Subject Prev][Subject Next][ Date Index][ Subject Index]

Re: UNDO



Robert wrote:
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."?)
Yes, that's what it is, and has been all along. My thinking was confused:
XyWrite can't act as a conduit for Windows errors--those show up in Windows
dialog boxes. This is a XyWrite error message (and usually a beep).
UNDO.CTL appearing and disappearing is normal behavior

Oh. Thanks. That clears that suspect.
> 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!

Yes, I've switched to 6A.
them manually. That makes them ideal, actually. Put $T in
EVERY TABLE! You're using yesterday's U2 frames, right?

I'll put the frames (which adds a prompt "okay" to undo.int) at the end.
You don't have any XyWrite background programs running, right?
Hmmm. You mean something that would be in memory and capturing keystrokes?
I can't recall any such.
Are you SURE Tame is OFF?

Yes.
> 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

Yep. It's 20.
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".

"Access denied"
Now look in directory C:\XY\UD. Two files should be present,
DUMMY.BAK and UNDO.CTL.

Only UNDO.CTL exists
 If you open UNDO.CTL,
it should just
say "DUMMY"

It does
 (now close UNDO.CTL!). If you open DUMMY.BAK,
There's no such file. No DUMMY.* in the current director (c:xy) nor the
c:\xy\undo directory.

So I will stop here, pending resolution.

--Harry
 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
-----------------------------


Harry Binswanger
hb@xxxxxxxx