On Saturday, January 06, 2001, 11:09:50 PM, Andrey wrote:
ML I'm not sure about this. As Thomas said, different scan codes
ML are sent to the system when the NumLock status is changed.
I'm afraid you're incorrect here. The down state of an Alt key just
changes the way the keyboard handler
On Saturday, January 06, 2001, 10:54:07 PM, Andrey wrote:
Partially - it depends on OS used. In DOS we are limited to 256
characters. In Windows we can use all those characters that a
particular font supports. For example, Alt+0149 != Alt+149 - try
it yourself and you'll feel the difference.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Ming-Li,
On 07 January 2001 at 05:32:13 -0800 (which was 13:32 where I
live) Ming-Li wrote and made these points:
I'm afraid you're incorrect here. The down state of an Alt key just
changes the way the keyboard handler interprets the actual
Hallo Andrey,
On Sun, 7 Jan 2001 09:54:07 +0300 GMT (07/01/2001, 14:54 +0800 GMT),
Andrey G. Sergeev (AKA Andris) wrote:
AGSAA Partially - it depends on OS used. In DOS we are limited to 256
AGSAA characters. In Windows we can use all those characters that a particular
AGSAA font supports. For
Hello!
Friday, January 05, 2001, 9:13:13 AM, Thomas Fernandez [EMAIL PROTECTED] wrote:
AGSAA It seems to be impossible to enter characters using their ANSI
AGSAA codes via Alt+NumPad in TB message editor when the NumPad acts
AGSAA as a cursor control keys :-(.
TF I wouldn't know about ANSI
Hello!
Friday, January 05, 2001, 6:15:32 PM, Ming-Li [EMAIL PROTECTED] wrote:
It seems to be impossible to enter characters using their ANSI
codes via Alt+NumPad in TB message editor when the NumPad acts as
a cursor control keys :-(.
The correct behaviour is to ignore the NumPad status.
Hello!
Friday, January 05, 2001, 7:03:02 PM, Tim Musson [EMAIL PROTECTED] wrote:
lost
TF I say it's not a bug in TB.
TM Agreed, it seems to be application dependent. M$ NotePad gets a t with
TM NumLock on and off.
Disagreed, it seems to be an UI inconsistence - like an absent New
Message
Hey Thomas,
Friday, January 05, 2001, 1:13:13 AM, you wrote:
AGSAA The correct behaviour is to ignore the NumPad status.
TF Is that so? I have never heard this. I think if you want to inoput
TF ASCII codes via AtlNumPad, you have to make sure the NumLock light is
TF on. It has always been this
On Thursday, January 04, 2001, 8:49:17 PM, Andrey wrote:
It seems to be impossible to enter characters using their ANSI
codes via Alt+NumPad in TB message editor when the NumPad acts as
a cursor control keys :-(.
The correct behaviour is to ignore the NumPad status.
I'm not sure about
Hallo Tim,
On Fri, 5 Jan 2001 08:26:11 -0500 GMT (05/01/2001, 21:26 +0800 GMT),
Tim Musson wrote:
TM Alt+116 = t regardless of the NumLock status for
TM Win2k/NT/98/95/m$-dos6/5/3/dr-dos7 on ThinkPad/Dell workstation, and
TM Compaq servers.
Not for Word 97 under Win98. I just tried it. Returns
Hey Thomas,
Friday, January 05, 2001, 10:30:25 AM, you wrote:
TM Alt+116 = t regardless of the NumLock status for
TM Win2k/NT/98/95/m$-dos6/5/3/dr-dos7 on ThinkPad/Dell workstation, and
TM Compaq servers.
TF Not for Word 97 under Win98. I just tried it. Returns t when NumLock
TF is TRUE and
Hello!
It seems to be impossible to enter characters using their ANSI codes via
Alt+NumPad in TB message editor when the NumPad acts as a cursor control
keys :-(.
For example, you can try to enter char - it's code is 0149. You have
to hold down one of Alt keys while entering 0149 on the
12 matches
Mail list logo
