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

Re: Tame



** Reply to message from "Martin J. Osborne"  on
Mon, 02 Dec 2002 10:22:12 -0500


> One can see that Tame hasn't *completely* eliminated the
> problem by holding down the "cursor down" key for a while, until the
> displayed file starts to scroll up the screen.

General observation:

Windowed DOS boxes inherently lag behind the action. For example, I just ran a
simple XPL program that copied 174 files from one directory to another. Each
copy operation puts a PRompt stating the filename that got copied; when
finished, the program says "Done". In a DOS box, what I actually see is this:
the first 4 or 5 filenames flash by, and then the PRompt "Done" appears,
meaning the whole program has completed -- in under *one second*! In short,
DOS boxes are translating what would normally be displayed VGA, and that is
very difficult. The box just can't keep up.

> I don't know how to go back to
> non-xywrite.reg, and without being able to go
> back and forth it's hard to tell if there is any difference.

Delete the Xywrite (or EDITOR.EXE?) key under Tame (HKLM\SOFTWARE\Tame). Wanna
alter responsiveness? Grab the Tame tech documentation, then play with the
Registry "Settings", at this key.

Your discovery of the interaction with NI is quite important, I think, and also
makes sense. NI masks the key from the operating system, so that you don't
inadvertently trigger a system response if, say, some key combination that you
use in XyWrite would ordinarily trigger an OpSys function -- Ctrl-C, for
example. NI doesn't altogether work under modern OpSyses -- some keystrokes
still leak through, Ctrl-Esc for example (thank god!).

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