1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

@@key aliases cause new prompt?

Discussion in 'Support' started by vefatica, May 20, 2010.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    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.
     
  2. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    WAD, and there's no way to suppress it (nor will there be in v12).

    Rex Conn
    JP Software
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    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
     
  4. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    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
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    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
     
  6. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,312
    Likes Received:
    39
    If you'll forgive an ignorant newbie question: What's the advantage of using Command() instead of Activate_Cmd() ?
     
  7. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    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
     
  8. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    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
     
  9. Charles Dye

    Charles Dye Super Moderator
    Staff Member

    Joined:
    May 20, 2008
    Messages:
    3,312
    Likes Received:
    39
    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!)
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    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
     
  11. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    What good would that do? ACTIVATE doesn't display any text.

    Rex Conn
    JP Software
     
  12. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    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
     
  13. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    /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
     
  14. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    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
     
  15. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    | /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
     
  16. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    No command has an option to suppress fatal errors (which are the only kinds
    displayed by ACTIVATE).

    Rex Conn
    JP Software
     
  17. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    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
     

Share This Page