Plugin keyhandler observation/question

[vefatica]

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?

 

[Steve Fabian]

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

 

[vefatica]

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

 

[Steve Fabian]

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

 

[vefatica]

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

 

[rconn]

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

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

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

 

[vefatica]

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.

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.

 

[rconn]

> ---Quote (Originally by rconn)---
> 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.
> ---End Quote---
> OK, thanks.
>
> What about AddToHistory() from within a keyhandler? It didn't seem to
> work.

Works fine here. (TCC calls it on some keystrokes, like ^K.)

 

[rconn]

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

It's a bug in an RTL function -- which means no quick fix.

Rex Conn
JP Software

 

[vefatica]

Regarding Prontf/Sprintf with the likes of %3.3f ...

It's a bug in an RTL function -- which means no quick fix.

Rex Conn
JP Software

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

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

 

[vefatica]

Sprintf(szOffset, L"%s%3.3f", fOffset >= 0 ? L"+" : L"", fOffset + 0.0005);

Oops! My rounding scheme doesn't work correctly on negative values.

 

[rconn]

> ---Quote (Originally by rconn)---
> It's a bug in an RTL function -- which means no quick fix.
>
> ---End Quote---
> 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);
> ---------

_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

 

[vefatica]

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

 

[vefatica]

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.

	// 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

 

[rconn]

> 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?

Right. I agree. Now tell Microsoft, because it's there code that's
returning szOffset[0] == 0.

> 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?
> --

Yes.

Rex Conn
JP Software

 

[vefatica]

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