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

Plugin keyhandler observation/question

Discussion in 'Plugins' started by vefatica, Oct 30, 2009.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    If the user executes a command by pressing {Enter} while the command is selected in the command history window, a plugin keystroke handler doesn't see the {Enter}.

    Similarly if the user uses {Up}/{Down} to get to a command in the command history and executes it with {Enter}, a plugin keyhandler doesn't see the {Enter}.

    I imagine in the first case, the command history window's window process eats the keystroke. It's not so easy to guess what's happening in the second case.

    In any event, that makes it difficult for a plugin keystroke handler to know when a user is executing a command from the command line.

    Any suggestions?
     
  2. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    vefatica wrote:
    | If the user executes a command by pressing {Enter} while the command
    | is selected in the command history window, a plugin keystroke
    | handler doesn't see the {Enter}.
    |
    | Similarly if the user uses {Up}/{Down} to get to a command in the
    | command history and executes it with {Enter}, a plugin keyhandler
    | doesn't see the {Enter}.
    |
    | I imagine in the first case, the command history window's window
    | process eats the keystroke. It's not so easy to guess what's
    | happening in the second case.
    |
    | In any event, that makes it difficult for a plugin keystroke handler
    | to know when a user is executing a command from the command line.

    If you want to know whether a command is executed from a batch file or from
    the command line, use _BATCH, which is 0 only in the latter instance. But I
    think you are looking from something much deeper...
    --
    Steve
     
  3. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    On Fri, 30 Oct 2009 15:07:04 -0500, Steve Fábián <> wrote:

    |vefatica wrote:
    || If the user executes a command by pressing {Enter} while the command
    || is selected in the command history window, a plugin keystroke
    || handler doesn't see the {Enter}.
    ||
    || Similarly if the user uses {Up}/{Down} to get to a command in the
    || command history and executes it with {Enter}, a plugin keyhandler
    || doesn't see the {Enter}.
    ||
    || I imagine in the first case, the command history window's window
    || process eats the keystroke. It's not so easy to guess what's
    || happening in the second case.
    ||
    || In any event, that makes it difficult for a plugin keystroke handler
    || to know when a user is executing a command from the command line.
    |
    |If you want to know whether a command is executed from a batch file or from
    |the command line, use _BATCH, which is 0 only in the latter instance. But I
    |think you are looking from something much deeper...

    I only want to know when it's executed at the command line. As it is, a plugin
    keyhandler doesn't always see the {Enter} which causes the command to be
    executed. (A keyhandler wouldn't be invoked by a batch file executing a
    command.)
    --
    - Vince
     
  4. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    vefatica wrote:
    | I only want to know when it's executed at the command line. As it
    | is, a plugin keyhandler doesn't always see the {Enter} which causes
    | the command to be executed. (A keyhandler wouldn't be invoked by a
    | batch file executing a command.)

    Intercept PRE_EXEC? Are you looking for the "start command execution" event?
    Rex may need to create a new feature...
    --
    Steve
     
  5. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    On Fri, 30 Oct 2009 15:28:11 -0500, Steve Fábián <> wrote:

    |vefatica wrote:
    || I only want to know when it's executed at the command line. As it
    || is, a plugin keyhandler doesn't always see the {Enter} which causes
    || the command to be executed. (A keyhandler wouldn't be invoked by a
    || batch file executing a command.)
    |
    |Intercept PRE_EXEC? Are you looking for the "start command execution" event?
    |Rex may need to create a new feature...

    Normally a plugin keyhandler sees the {Enter} that kicks off command execution.
    But in the two cases mentioned, it doesn't. Anyway I have abandoned the
    keyhandler approach, at least temporarily, because it was getting too far from
    KISS (as you said). I also discovered that AddToHistory() didn't work from
    inside a keyhandler (why, Rex?) and if DO commands at the command line are
    anything like FOR commands (I suppose they are) the user is going to want to
    recall them (to get them right).

    So I'm back to the CDO approach I started with. I have incorporated
    GetTempPath() in the temporary batfile name. I just don't like having to
    backtick the tail of the [C]DO command.
    --
    - Vince
     
  6. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    In the second case, the line editor is in a loop waiting to see if the next
    keystroke is another up/down key. If it's not, it jumps to the routine to
    insert the character. So in this case the only key a keyhandler will see is
    the first up/down key.


    No; there isn't any provision for doing that. (Key handlers are intended
    for key substitution, not intercepting commands.) I really *don't* want
    plugins to be intercepting commands before the parser can process them;
    that's a support nightmare.

    Rex Conn
    JP Software
     
  7. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    OK, thanks.

    What about AddToHistory() from within a keyhandler? It didn't seem to work.

    And please have a look at Printf (Sprintf too) with %3.3f and doubles very near zero.
     
  8. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    Works fine here. (TCC calls it on some keystrokes, like ^K.)
     
  9. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    It's a bug in an RTL function -- which means no quick fix.

    Rex Conn
    JP Software
     
  10. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    Regarding Prontf/Sprintf with the likes of %3.3f ...

    What function? In your experience, can I count on **at least** the length I specify (since the easy fix is to write it to a string and truncate it)?

    Code:
    Sprintf(szOffset, L"%s%3.3f", fOffset >= 0 ? L"+" : L"", fOffset + 0.0005);
    szOffset[6] = 0;
    Printf(L"Estimated local time offset: %s seconds\r\n\r\n", szOffset);
    
     
  11. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    Code:
    Sprintf(szOffset, L"%s%3.3f", fOffset >= 0 ? L"+" : L"", fOffset + 0.0005);
    Oops! My rounding scheme doesn't work correctly on negative values.
     
  12. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    _fcvt_s(). The function behaves oddly (i.e., undocumented) when you pass it
    an argument smaller than the maximum precision. For example, passing 0.0001
    with a %3.3f argument returns an empty string, with a decimal offset of 4.

    I've made some changes for build 32 to work around the problem. But in the
    meantime, if you want to pass small arguments, use a larger max precision
    and then truncate that -- your code above won't work, since szOffset[0] is
    0.

    Rex Conn
    JP Software
     
  13. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    On Mon, 02 Nov 2009 11:28:54 -0600, rconn <> wrote:

    |> Code:
    |> ---------
    |> Sprintf(szOffset, L"%s%3.3f", fOffset >= 0 ? L"+" : L"", fOffset +
    |> 0.0005);
    |> szOffset[6] = 0;
    |> Printf(L"Estimated local time offset: %s seconds\r\n\r\n", szOffset);
    |> ---------
    |---End Quote---
    |_fcvt_s(). The function behaves oddly (i.e., undocumented) when you pass it
    |an argument smaller than the maximum precision. For example, passing 0.0001
    |with a %3.3f argument returns an empty string, with a decimal offset of 4.
    |
    |I've made some changes for build 32 to work around the problem. But in the
    |meantime, if you want to pass small arguments, use a larger max precision
    |and then truncate that -- your code above won't work, since szOffset[0] is
    |0.

    Why is szOffset[0] == 0? It should be '+' (if fOffset >= 0) or the '-' provided
    by Sprintf() (if fOffset < 0) (%3.3f having been catenated onto the empty
    szOffset) ... right?

    In the NTP protocol, fractions of a second are represented by 4 bytes (basically
    a DWORD); it's considered the numerator of a fraction whose demoninator is
    0x100000000 (DWORD_MAX + 1). To handle the extreme case (1/(DWORD_MAX + 1)) (0.000000000232) should I ask for 10 digit precision?
    --
    - Vince
     
  14. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    On Mon, 02 Nov 2009 11:28:54 -0600, rconn <> wrote:

    |_fcvt_s(). The function behaves oddly (i.e., undocumented) when you pass it
    |an argument smaller than the maximum precision. For example, passing 0.0001
    |with a %3.3f argument returns an empty string, with a decimal offset of 4.

    When I try that, with count = 3, I get an empty string with the decimal at -3.


    Code:
    	// VC9 static lib
    	double x = 0.0001;
    	INT dp, sign;
    	WCHAR szF[16];
    	CHAR aszF[16];
    	_fcvt_s(aszF, 16, x, 3, &dp, &sign);
    	ASCIIToUnicode(aszF, szF, 16);
    	Printf(L"**%s** %d %d\r\n", szF, dp, sign);
    
    	//**** -3 0
    Never having used _fcvt_s, that does seem peculiar, but correct. The string
    starts with the first significant digit; there are none among the first 3
    digits, thus an empty string. The decimal point at -3 would suggest "0.000").
    --
    - Vince
     
  15. rconn

    rconn Administrator
    Staff Member

    Joined:
    May 14, 2008
    Messages:
    9,870
    Likes Received:
    83
    Right. I agree. Now tell Microsoft, because it's there code that's
    returning szOffset[0] == 0.


    Yes.

    Rex Conn
    JP Software
     
  16. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,972
    Likes Received:
    30
    On Mon, 02 Nov 2009 17:52:37 -0600, rconn <> wrote:

    |---Quote---
    |> Why is szOffset[0] == 0? It should be '+' (if fOffset >= 0) or the '-'
    |> provided by Sprintf() (if fOffset < 0) (%3.3f having been catenated
    |> onto the empty szOffset) ... right?
    |---End Quote---
    |Right. I agree. Now tell Microsoft, because it's there code that's
    |returning szOffset[0] == 0.

    I don't get it. Are you talking about _fcvt_s now? That just puts a bunch of
    digits into the buffer, the significant ones that fall within the specified
    precicion (no decimal point, no sign). It tells you elsewhere where the decimal
    point goes and whether there's a minus sign. I'd expect an empty string if the
    absolute value of the double supplied is than 10^(-precision).
    --
    - Vince
     

Share This Page