@@key aliases cause new prompt?

[vefatica]

An alias like @@key=`activate "..."` causes a new prompt to show ... use it several times and the console fills up with unused prompts. Is there a way to suppress the new prompt? If not, perhaps there will be in V12.

 

[rconn]

> An alias like @@key=`activate "..."` causes a new prompt to show ...
> use it several times and the console fills up with unused prompts. Is
> there a way to suppress the new prompt? If not, perhaps there will be
> in V12.

WAD, and there's no way to suppress it (nor will there be in v12).

Rex Conn
JP Software

 

[vefatica]

On Fri, 21 May 2010 20:56:50 -0400, rconn <> wrote:

|---Quote---
|> An alias like @@key=`activate "..."` causes a new prompt to show ...
|> use it several times and the console fills up with unused prompts. Is
|> there a way to suppress the new prompt? If not, perhaps there will be
|> in V12.
|---End Quote---
|WAD, and there's no way to suppress it (nor will there be in v12).

What if a plugin keyhandler used Command(), during command line entry, to
execute something like ACTIVATE ... would that cause a new prompt, or mess up
the current command line?
--
- Vince

 

[rconn]

> What if a plugin keyhandler used Command(), during command line entry,
> to execute something like ACTIVATE ... would that cause a new prompt, or
> mess up the current command line?

No new prompt, provided you pass 0 as the second arg to Command(). If you
use the same buffer as the original command line entry, it will definitely
destroy the current command line. If you copy the original buffer to a new
one and use that for Command(), then the only thing you'll mess up is the
batch debugger.

Rex Conn
JP Software

 

[vefatica]

On Fri, 21 May 2010 21:57:58 -0400, rconn <> wrote:

|---Quote---
|> What if a plugin keyhandler used Command(), during command line entry,
|> to execute something like ACTIVATE ... would that cause a new prompt, or
|> mess up the current command line?
|---End Quote---
|No new prompt, provided you pass 0 as the second arg to Command(). If you
|use the same buffer as the original command line entry, it will definitely
|destroy the current command line. If you copy the original buffer to a new
|one and use that for Command(), then the only thing you'll mess up is the
|batch debugger.

I tried it like this and **did** get a new prompt.

if ( lpKeyInfo->nKey == F7 )
{
WCHAR szCmd[32] = L"ACTIVATE \"V - *\" 2> NUL";
Command(szCmd, 0);
return 0;
}
--
- Vince

 

[Charles Dye]

What if a plugin keyhandler used Command(), during command line entry, to execute something like ACTIVATE ... would that cause a new prompt, or mess up the current command line?

If you'll forgive an ignorant newbie question: What's the advantage of using Command() instead of Activate_Cmd() ?

 

[vefatica]

On Fri, 21 May 2010 22:55:35 -0400, Charles Dye <> wrote:

|---Quote (Originally by vefatica)---
|What if a plugin keyhandler used Command(), during command line entry, to execute something like ACTIVATE ... would that cause a new prompt, or mess up the current command line?
|---End Quote---
|If you'll forgive an ignorant newbie question: What's the advantage of using Command() instead of Activate_Cmd() ?

None. I didn't even think of it.

--
- Vince

 

[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.
--
- Vince

 

[Charles Dye]

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!)

 

[vefatica]

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.
|---End Quote---
|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
the command).

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
TakeCmd.h).
--
- Vince

 

[rconn]

> Rex, ACTIVATE could use a /q(uiet) option.

What good would that do? ACTIVATE doesn't display any text.

Rex Conn
JP Software

 

[vefatica]

On Sat, 22 May 2010 18:35:33 -0400, rconn <> wrote:

|---Quote---
|> Rex, ACTIVATE could use a /q(uiet) option.
|---End Quote---
|What good would that do? ACTIVATE doesn't display any text.

I meant an option to suppress error messages.
--
- Vince

 

[rconn]

> |---Quote---
> |> Rex, ACTIVATE could use a /q(uiet) option.
> |---End Quote---
> |What good would that do? ACTIVATE doesn't display any text.
>
> I meant an option to suppress error messages.

/Q never suppresses error messages -- I don't think it'd be a good idea to
introduce a /Q option to ACTIVATE that worked differently than the /Q in
every other command!

Rex Conn
JP Software

 

[vefatica]

On Sat, 22 May 2010 21:07:49 -0400, rconn <> wrote:

|---Quote---
|> |---Quote---
|> |> Rex, ACTIVATE could use a /q(uiet) option.
|> |---End Quote---
|> |What good would that do? ACTIVATE doesn't display any text.
|>
|> I meant an option to suppress error messages.
|---End Quote---
|/Q never suppresses error messages -- I don't think it'd be a good idea to
|introduce a /Q option to ACTIVATE that worked differently than the /Q in
|every other command!

Do **any** commands have an option to suppress error messages? If so, that's
what I had in mind for ACTIVATE.
--
- Vince

 

[Steve Fabian]

| /Q never suppresses error messages -- I don't think it'd be a good
| idea to introduce a /Q option to ACTIVATE that worked differently
| than the /Q in every other command!

I agree. A /E or /Ne would be a better choice, matching other commands. But
even those only suppress warnings, e.g., the file to be deleted did not
exist and thus the desired end result was achieved without deletion. If DEL
cannot delete a file (e.g. a DLL that is in use) the error message still
appears. Likewise if ACTIVATE cannot find the process to be activated it
responds with a "window title not found" message. I can conceive of
situations when one wants to suppress this REAL error message (and others,
such as the above failure to delete), currently supported only by
redirecting STDERR to NUL. A "strong no message" would be useful, via e.g.
another suboption for /N.
--
Steve

 

[rconn]

> Do **any** commands have an option to suppress error messages? If so,
> that's what I had in mind for ACTIVATE.

No command has an option to suppress fatal errors (which are the only kinds
displayed by ACTIVATE).

Rex Conn
JP Software

 

[rconn]

> I can conceive of situations when one wants to suppress this REAL
> error message (and others, such as the above failure to delete),
> currently supported only by redirecting STDERR to NUL.

I can't conceive of any case where suppressing fatal errors is a good idea.
(And if I had a nickel for every "bug" report filed by somebody who forgot
they were suppressing errors ...)

Rex Conn
JP Software