home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / os / mswindo / programm / misc / 5220 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  1.3 KB
  1. Path: sparky!uunet!olivea!gossip.pyramid.com!pyramid!infmx!infmuc!christb
  2. From: christb@infmuc (Christian Barmala)
  3. Newsgroups: comp.os.ms-windows.programmer.misc
  4. Subject: Aborting Eventprocessing
  5. Message-ID: <1993Jan21.095835.2494@informix.com>
  6. Date: 21 Jan 93 09:58:35 GMT
  7. Sender: news@informix.com (Usenet News)
  8. Organization: Informix Software, Inc.
  9. Lines: 19
  10. X-Newsreader: Tin 1.1 PL3
  11.  
  12. The processing of messages that cause the screen to be repainted may take
  13. a long time. During that time other messages may arrive, that make the
  14. current repainting of the screen worthless, because they change the screen
  15. and need again a repaint. Such messages may be iconizing, closing or resizing
  16. the window, typing in text by keyborad or drawing graphics by mouse, ...
  17.  
  18. Therefore it seems reasonable to abort processing of WM_PAINT as soon
  19. as such messages arrive and to process these messages.
  20.  
  21. In C this seems to me easy. There is probably a function like
  22. "look_for_event_but_don't_get_it()". If it returns such an event,
  23. I close all device contexts, that I opened during WM_PAINT, I invalidate
  24. the part of the window, that has not yet been repainted (in case of doubt
  25. the whole window) and then I return premature from the function that
  26. processes WM_PAINT. Am I right?
  27.  
  28. How can the same be acomplished in Visual Basic?
  29.  
  30. Regards, Christian Barmala
  31.