Re: Possible bug when entering characters using Alt+NumPad
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 interprets the actual scan codes. Could you tell me what this is? The (keyboard) BIOS? The OS (Windows)? Or the application? I'm afraid you're not making sense to me. If the keyboard scan codes have been interpreted by someone else before the application (TB) gets them, then TB wouldn't know otherwise, does it? If TB does get to interpret the keyboard events as they come, then it should be up to TB to decide what to do. Now, of course, you may argue TB is doing it the wrong way (not according to standard/custom). But I can see no standard/custom here, for I've found either way (ignoring or not ignoring NUmLock status) implemented by various applications. ML It's up to the receiving end (the application, I assume) to ML decide what to do with it. But _any_ application must conform to the common standards (at least to an environment (OS) standards or a common practice). Please tell me then where I can find this standard. ML And I know people who prefer using the NumPad as direction keys ML to the actual direction keys (out of habits). Yes, but this is not related to my problem, isn't it? :-) Why not? I mean there're people who prefer the NumLock status not to be ignored. The want Alt+Numpad 2 to be Alt+Down Arrow when NumLock is off. And I find it to be reasonable. -- Best regards, Ming-Li The Bat! 1.49 | Win2k SP1 -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re: Possible bug when entering characters using Alt+NumPad
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. Sorry, couldn't tell. I tried several times (in Notepad, another editor, Word, Windows Run dialog, ...etc.), and could find no difference at all between the two. They all show a round dot to me. TF And when the NumPad is not NumLock'ed, it is not a NumPad, it TF is a cursor control pad. Different signals are sent to the CPU, TF so you will see different results. Yes, you're quite right but please don't forget the Alt hold down. It changes the way the OS interprets the scan codes of these keys - it means: store the NumPad input in a special buffer and simulate entering a character according to the decimal ANSI code received. So you mean the OS (Windows) would buffer all the keyboard actions during the time Alt is down and send the result after the whole event (after Alt is up)? Is this documented somewhere (online sources preferred, please)? AFAIK, key codes continue to be sent to the application during the time Alt is down, and it's up to the application to interpret the result, including whether to disregard the NumLock status or not. By application I mean the last program down the chain that can get the keyboard events (including the status of various modifier/special keys) and get to interpret them. AGSAA The correct behaviour is to ignore the NumPad status. Again, please tell me where it's documented. Thanks. -- Best regards, Ming-Li The Bat! 1.49 | Win2k SP1 -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
DEAD HORSE (was Re: Possible bug when entering characters using Alt+NumPad)
-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 scan codes. ML ML Could you tell me what this is? The (keyboard) BIOS? The OS ML (Windows)? Or the application? It's the BIOS. ML Please tell me then where I can find this standard. There isn't one - only a general "norm" to which some, but not all, adhere and it all depends on the BIOS at root. Can we please take this discussion off-list (that's an official instruction, not a request). It may seem to be TB related, but it's not. It's about BIOS, OS and Application interactions and varies from system to system. Anyway - there's no further to take this on-list, so the horse just died :-). - -- Cheers -- .\\arck D. Pearlstone -- Moderator TBUDL / TBBETA [ PGP Key ID: 0x929DCDA0 | www: http://www.silverstones.com ] [Any opinions are my own and not those of RIT labs ] TB! v1.49 S/N 14F4B4B2 on Windows NT 5.0 Build 2195 Service Pack 1 -BEGIN PGP SIGNATURE- Version: PGP 6.5.8 Secured Comment: PGP Sealed for freshness iQA/AwUBOlh1XjnkJKuSnc2gEQJ2lQCfVZ1j+Y5LS+2E15SOxGK107kY+XcAoJ5t 7uEcODExaOpqijRMBbxjqmYd =INlW -END PGP SIGNATURE- -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re: Possible bug when entering characters using Alt+NumPad
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 example, Alt+0149 != Alt+149 - try it yourself and AGSAA you'll feel the difference. A dot here in both cases - maybe a non-printable character in my encoding but a russian character in your. I have always left out preceding zeros when entering codes via Atl-NumPad. AGSAA Again, please remember that we're holding Alt down. AGSAA I suggest trying to enter character (Alt+0149) in the Start - Run AGSAA window which is a part of Windows unlike all the applications discussed AGSAA here. You'll always get the correct input regardless of the NumPad AGSAA status. The status of the NumLock keys changes the code the keys on the NumPad produce. So it is a matter of definition what code they should produce when the Atl key is held down while NumLock of FALSE: the same as with NumLock, or not? We have seen that the different applications answer this question differently, and Ritlabs chose the same way as MS when they developed Word. I don't think this is a big, even though MS chose to use the other definition when they devleoped other applications. -- Cheers, Thomas. The severity of the itch is inversely proportional to the ability to reach it. Message reply created with The Bat! 1.49 under Chinese Windows 98 4.10 Build 1998 using an Intel Celeron 366Mhz, 128MB RAM -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re: Possible bug when entering characters using Alt+NumPad
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 codes, but I usually use the NumPad for TF ASCII codes. Maybe they are the same. 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. TF And when the NumPad is not NumLock'ed, it is not a NumPad, it is a TF cursor control pad. Different signals are sent to the CPU, so you will TF see different results. Yes, you're quite right but please don't forget the Alt hold down. It changes the way the OS interprets the scan codes of these keys - it means: store the NumPad input in a special buffer and simulate entering a character according to the decimal ANSI code received. 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 way, and wouldn't understand why TF alt+uparrow on the NumPad should have the same meaning as alt-8 on TF the NumPad. Again, please remember that we're holding Alt down. I suggest trying to enter character (Alt+0149) in the Start - Run window which is a part of Windows unlike all the applications discussed here. You'll always get the correct input regardless of the NumPad status. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.msk.ru/ -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re: Possible bug when entering characters using Alt+NumPad
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. ML I'm not sure about this. As Thomas said, different scan codes are ML 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 interprets the actual scan codes. ML It's up to the receiving end (the application, I assume) to decide ML what to do with it. But _any_ application must conform to the common standards (at least to an environment (OS) standards or a common practice). ML While you may want TB to ignore the NumLock status, others may like ML it not to. Well and again, there are some standards (CUA and Win32 for example) that _every_ application should meet. No M$ish "improvements" to the protocols here. OT: do you like the "Microsoft TCP/IP Protocol"? ;-) ML Have you ever seen keyboards without the normal direction keys ML (arrows and Home, End, PgUp, PgDn)? I do. I too, as a user/developer/system administrator/decision maker. ML And I know people who prefer using the NumPad as direction keys to ML the actual direction keys (out of habits). Yes, but this is not related to my problem, isn't it? :-) -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.msk.ru/ -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re: Possible bug when entering characters using Alt+NumPad
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 toolbar button in the Folder View window while the Ctrl+N mentioned under Message menu. However, it's a small problem - there are more important ones to be resolved :-). A message to the [EMAIL PROTECTED] will be sent soon. Perhaps I'll try to add this item to the unofficial wishlist also. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.msk.ru/ -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re[2]: Possible bug when entering characters using Alt+NumPad
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 way, and wouldn't understand why TF alt+uparrow on the NumPad should have the same meaning as alt-8 on TF the NumPad. I don't know why, but my different PC's / OS's seem to ignore the NumLock key when combining with the Alt key for ASCII chars. Alt+116 = t regardless of the NumLock status for Win2k/NT/98/95/m$-dos6/5/3/dr-dos7 on ThinkPad/Dell workstation, and Compaq servers. -- [EMAIL PROTECTED] The Bat! v1.48f Windows NT 5.0.2195 (Service Pack 1) -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re: Possible bug when entering characters using Alt+NumPad
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 this. As Thomas said, different scan codes are sent to the system when the NumLock status is changed. It's up to the receiving end (the application, I assume) to decide what to do with it. While you may want TB to ignore the NumLock status, others may like it not to. Have you ever seen keyboards without the normal direction keys (arrows and Home, End, PgUp, PgDn)? I do. And I know people who prefer using the NumPad as direction keys to the actual direction keys (out of habits). -- Best regards, Ming-Li The Bat! 1.49 Beta/2 | Win2k SP1 -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re: Possible bug when entering characters using Alt+NumPad
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 t when NumLock is TRUE and nothing when NumLock is FALSE. You are right under MS-DOS 7, though. I find this inconsistent, but there it is. I have no access to other OS's right now, with my laptop (running DR-DOS 6) having been on the fritz for a while (like 2 years, but one day, I will fix it). I say it's not a bug in TB. -- Cheers, Thomas. -Why be difficult when with a bit of effort you can be impossible? Message reply created with The Bat! 1.49 Beta/1 under Chinese Windows 98 4.10 Build 1998 using an Intel Celeron 366Mhz, 128MB RAM -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Re[2]: Possible bug when entering characters using Alt+NumPad
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 nothing when NumLock is FALSE. Ah... I did not try it in anything but a command prompt... I checked another app (TextPad - wonderful text editor btw, wish TB's editor worked like www.TextPad.com) and with NumLock off, I do not get the "t"... TF I say it's not a bug in TB. Agreed, it seems to be application dependent. M$ NotePad gets a t with NumLock on and off. -- [EMAIL PROTECTED] The Bat! v1.48f Windows NT 5.0.2195 (Service Pack 1) -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
Possible bug when entering characters using Alt+NumPad
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 NumPad. If Num Lock indicator is lit everything seems to be OK, but if your NumPad is in cursor control mode, you'll probably have an "Add A File (MIME/Base64)" window popping out after pressing [9] (or the last key in the sequence). As far as i understand it's TB (but not only TB) failure - just check the technique described above in the Notepad, WordPad and Agent. However, MS Word and Netscape Communicator failed also :-). The correct behaviour is to ignore the NumPad status. -- Yours sincerely, Andrey G. Sergeev (AKA Andris) http://www.andris.msk.ru/ -- -- View the TBUDL archive at http://tbudl.thebat.dutaint.com To send a message to the list moderation team double click here: mailto:[EMAIL PROTECTED] To Unsubscribe from TBUDL, double click here and send the message: mailto:[EMAIL PROTECTED] -- You are subscribed as : archive@jab.org
