Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

KEYSTACK and caps lock

May
3,515
5
I noticed for the first time that a KEYSTACK command, issued when the caps
lock status was ON, sent an all-capital text to the selected window, though
the command text was lower case. Is this an artifact of my own system (quite
possible, observed only with a specific keyboard), or is it WAD? If the
latter, it ought to be documented. Regardless, my easy fix is to add a
"KEYBD /C0" command to each place I use KEYSTACK in a case-sensitive
environment.
--
Steve
 
I noticed for the first time that a KEYSTACK command, issued when the caps
lock status was ON, sent an all-capital text to the selected window, though
the command text was lower case. Is this an artifact of my own system (quite
possible, observed only with a specific keyboard), or is it WAD? If the
latter, it ought to be documented. Regardless, my easy fix is to add a
"KEYBD /C0" command to each place I use KEYSTACK in a case-sensitive
environment.
--
Steve


Same behavior observed here. (v.12.11 64-bit)
.
 
mikea wrote:
| Quote:
| Originally Posted by rconn
| Normal Windows (not TCC) behavior.
|
| Strange. There's no way to force the issue?

I agree. When KEYSTACK is used to send a specific character string to a
process, case may be significant. Shouldn't TCC automatically turn caps lock
off?
--
Steve
 
> I agree. When KEYSTACK is used to send a specific character string
> to a process, case may be significant. Shouldn't TCC automatically
> turn caps lock off?

It *could* -- if you can guarantee that no Windows user will ever have more
than one process running at a time, and that TCC is always the foreground
process and in control of the keyboard.

Otherwise, it would be a REALLY bad idea!

Rex Conn
JP Software
 
> ---Quote---
> > I agree. When KEYSTACK is used to send a specific character string
> > to a process, case may be significant. Shouldn't TCC automatically
> > turn caps lock off?
> ---End Quote---
> It *could* -- if you can guarantee that no Windows user will ever have
more

> than one process running at a time, and that TCC is always the foreground
> process and in control of the keyboard.
>
> Otherwise, it would be a REALLY bad idea!

Oh, and that nobody will ever run more than one instance of TCC at a time
...

Rex Conn
JP Software
 
rconn wrote:
| Oh, and that nobody will ever run more than one instance of TCC at a
| time ...

Were it almost any other command I'd agree, but as is, an inadvertantly
undesirable CAPS LOCK status could mangle the text to be delivered, which -
depending on the program running in the target window - could cause data
loss. A simple solution could be a new option for the KEYSTACK command:
force exact delivery.

I have a total of 42 occurrences of KEYSTACK, not hard to fix the
case-sensitive ones to force "keybd/c0" BEFORE issuing KEY7STACK.
--
Steve
 
> Were it almost any other command I'd agree, but as is, an inadvertantly
> undesirable CAPS LOCK status could mangle the text to be delivered, which
-

> depending on the program running in the target window - could cause data
> loss. A simple solution could be a new option for the KEYSTACK command:
> force exact delivery.

There is no way I'm going to change something that could break every other
Windows program in existence.

TCC does not own the keyboard (nor does any single process). It belongs to
Windows, and you'd better think very, very carefully about something that
will affect millions of programs. (And the story gets much, much worse when
dealing with non-US English keyboards.)

You can of course always force caps lock state whenever you want to send
something through KEYSTACK, or write your own plugin.

The fact that you managed to use it for 15+ years without noticing the
normal Windows behavior is probably the best argument for leaving it alone!

Rex Conn
JP Software
 
I certainly think that a batch file that wants to send a small 'a' to
something should be able to do that, and using keybd /c0 appears to be that
way.

I agree with Rex that the caps lock state should not be changed without me
explicitely asking for it. Of couse, I never use the blasted thing on
purpose.

On Fri, Jul 22, 2011 at 09:15, rconn <> wrote:


> ---Quote---
> > Were it almost any other command I'd agree, but as is, an inadvertantly
> > undesirable CAPS LOCK status could mangle the text to be delivered, which
> ---End Quote---
> -
>
>
> ---Quote---
> > depending on the program running in the target window - could cause data
> > loss. A simple solution could be a new option for the KEYSTACK command:
> > force exact delivery.
> ---End Quote---
> There is no way I'm going to change something that could break every other
> Windows program in existence.
>
> TCC does not own the keyboard (nor does any single process). It belongs to
> Windows, and you'd better think very, very carefully about something that
> will affect millions of programs. (And the story gets much, much worse
> when
> dealing with non-US English keyboards.)
>
> You can of course always force caps lock state whenever you want to send
> something through KEYSTACK, or write your own plugin.
>
> The fact that you managed to use it for 15+ years without noticing the
> normal Windows behavior is probably the best argument for leaving it alone!
>
> Rex Conn
> JP Software
>
>
>
>
>



--
Jim Cook
2011 Monday: 4/4, 6/6, 8/8, 10/10, 12/12 and 5/9, 9/5, 7/11, 11/7.
Next year they're Tuesday.
 

Similar threads

Back
Top