On Sat, 22 May 2010 12:25:18 -0400, Charles Dye <> wrote:
|---Quote (Originally by vefatica)---
|On Fri, 21 May 2010 22:55:35 -0400, Charles Dye <> wrote:
||If you'll forgive an ignorant newbie question: What's the advantage of using Command() instead of Activate_Cmd() ?
|Now that I think of it (and having tried it) ... you can't put the "2> NUL" in
|ACTIVATE's arguments. Rex, ACTIVATE could use a /q(uiet) option.
|I haven't tried it myself, but I imagine it wouldn't be difficult to do your own redirection via DuplicateHandle(). (Just be sure to save the original stderr handle, and put it back when you're done!)
Actually, Command() worked OK (not causing a new prompt) when I added
lpKeyInfo->nKey = 0;
before returning. This actually leaves the command-line-in-progress untouched
so it can further edited and executed.
I'm experimenting with the file viewer "V". I wrote a user tool for V which
gives foreground to V's parent and assigned the tool to F7. With my F7 routine
(previously mentioned, added to a keyhandler already in my 4CONSOLE plugin) I
can switch seamlessly between V and the console, leaving command lines intact
(perhaps if I wanted to copy something from the viewed file and paste it into
I like this kind of key mapping, in which some action happens invisibly
regardless of the position in the current command line (unlike keystroke
aliases). But implementing it in a way in which the user could specify
key/command combinations would be tedious; I'd need a routine for turning
user-specified key names into TCC's internal key codes (see the end of