home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / os / os2 / advocacy / 8416 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  4.0 KB
  1. Path: sparky!uunet!know!mips2!news.bbn.com!usc!sdd.hp.com!swrinde!gatech!prism!emperor!henshaw
  2. From: henshaw@emperor.gatech.edu (Andy Henshaw)
  3. Newsgroups: comp.os.os2.advocacy
  4. Subject: keystroke programming in OS/2 and NT
  5. Message-ID: <74588@hydra.gatech.EDU>
  6. Date: 12 Nov 92 18:15:20 GMT
  7. Sender: news@prism.gatech.EDU
  8. Lines: 78
  9. Originator: henshaw@emperor
  10.  
  11. Maybe this should be added to Brian Sturgill's "OS/2 vs NT" list:
  12.  
  13. In the December issue of the "Microsoft Systems Journal" there is
  14. an article by Jeffrey Richter titled "Simulating Keyboard Input
  15. Between Programs Requires a (Key)Stroke of Genius."  In the
  16. article, Richter describes how a naive attempt to send keystrokes
  17. between applications by posting WM_CHAR messages would not be
  18. sufficient.  He then goes on to describe a couple of workable
  19. methods - one using the PostVirtualKeyEvent function supplied
  20. with Windows for Pens and another that uses Journal Playback hooks.
  21. The Journal Playback hook is the one he seems to prefer and he
  22. describes this method in detail.
  23.  
  24. This is where it starts getting interesting.
  25.  
  26. There is a sidebar describing "Keystroke processing in Windows NT."
  27. It describes how the PostMessage is better under NT because of
  28. separate, expandable input queues.  But it explains that this
  29. is still not a good solution because of GetFocus () problems.
  30.  
  31. Then, the option of using PostVirtualKeyEvent () is dismissed because
  32. the Pen Windows technology hasn't been ported to NT generally because
  33. Microsoft doesn't yet see the need for pen input on NT class machines.
  34. And his version of PostVirtualKeyEvent (written for those without
  35. access to Pen Windows) won't work because of the use of assembly language
  36. and that the keyboard drivers for NT are completely different than those
  37. for 16-bit Windows.
  38.  
  39. The final option (JournalPlayback) also won't work if NT is running
  40. strict security because the hook is a system-wide hook and NT won't
  41. allow it.
  42.  
  43. The whole sidebar discusses the problem without recommending a solution
  44. for NT, although I would imagine that there is one.  
  45.  
  46.  
  47. Really interesting stuff here !!!
  48.  
  49. The end of the article I will just quote from:
  50.  
  51.  "...Seems pretty complex doesn't it?  Wouldn't it be great if there
  52.   were  some way to simplify all of this?  Maybe a way to cut down
  53.   on the number of keystroke-related window messages?  If you're
  54.   wondering about this, you're not alone.  Microsoft realized long
  55.   ago that the keystroke processing was far more complex than it
  56.   had to be and fixed it.  The fix is in an operating system called
  57.   OS/2 {rtm}.
  58.     In OS/2 Presentation Manager {rtm} (PM), there is only one
  59.   keystroke message, WM_CHAR.  There are no WM_(SYS)KEYUP, 
  60.   WM_(SYS)KEYDOWN, or WM_(SYS)DEADCHAR messages.  Every message
  61.   has two parameters associated with it just like Windows, but in
  62.   PM both means, of course, that every message in PM can have 16
  63.   bits more of information associated with it.
  64.     Every time a PM window procedure receives a WM_CHAR message,
  65.   the procedure has access to the scan code, virtual-key code, and
  66.   ASCII key code corresponding to the pressed/released key.  Because
  67.   PM converts the virtual-key code to the ASCII code equivalent,
  68.   there is no need for a function like TranslateMessage.  To make
  69.   things even easier, the last 16 bits of WM_CHAR's first parameter
  70.   contains a more useful set of flags as compared to the lParam in
  71.   Windows keystroke messages.  Personally, I think that the PM
  72.   approach to keystroke message processing is superior.  
  73.   Unfortunately, even though the Win32{tm} API uses 32-bit parameters
  74.   for all its messages, Microsoft must still stick to the original
  75.                         ------------------------------------------        
  76.   paradigm used in Windows.  If Microsoft were to incorporate the
  77.   ------------------------
  78.   PM paradigm into Windows, all Windows-based applications that 
  79.   performed keystroke processing would break.  Oh well!"
  80.  
  81. (underline mine)
  82. {rtm}  registered trademark
  83. {tm}   trademark
  84.  
  85. Andrew Henshaw
  86. School of Electrical Engineering
  87. Georgia Institute of Technology
  88. henshaw@cerl.gatech.edu
  89.