home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / mswindo / programm / misc / 3612 < prev    next >
Encoding:
Text File  |  1992-11-23  |  1.8 KB  |  42 lines
  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!rpi!utcsri!geac!torag!robohack!feline!king
  3. From: king@feline.uucp (KingLeon)
  4. Subject: Suppressing WM_LBUTTONDOWN message when reactivating a window? 
  5. Message-ID: <1992Nov22.072400.6523@feline.uucp>
  6. Sender:  Leon King
  7. Organization: Humber College Technology Dept.
  8. References: <none>
  9. Date: Sun, 22 Nov 1992 07:24:00 GMT
  10. Lines: 30
  11.  
  12. Language: Borland C++
  13. Problem:  Suppressing a WM_LBUTTONDOWN message when reactivating a window.
  14.  
  15. I do have an inelegant solution to this problem involving two flags.
  16. This is what I am doing:
  17.  
  18.    My main window has some buttons and list boxes.  When the window is
  19.    activated by clicking on one of these then the selected items would
  20.    change.  So I set a flag when the window is activated and the next
  21.    LBUTTONDOWN is ignored.  Of course the window may be activated in
  22.    other ways (selecting the nonclient area) or switching from the
  23.    task manager, so I reset the flag so that the next LBUTTONDOWN is not
  24.    ignored.  I have another flag which I set when creating the app so
  25.    that the first LBUTTONDOWN will not be ignored.  The flags belong
  26.    to a Window's extra memory words.
  27.  
  28.    What I'm trying to do is emulate proper Windows user interface behaviour.
  29.    For example, clicking on a cell in an inactive spreadsheet will activate
  30.    the spreadsheet, but not select the clicked on cell.  (Clicking again
  31.    will do this.)  Ibid for a word processor, etc.  Clicking outside a
  32.    menu to make it go away should probably not cause a selection (but it
  33.    does do so in other apps that I investigated.)
  34.  
  35.    My approach is kinda kludgy, may be dependent on message order (and
  36.    would therefore probably not translate well to NT or other systems.)
  37.    I may also be missing cases.
  38.   
  39.    Is there a better way to handle this?
  40.  
  41.                                  
  42.