home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / mswindo / programm / misc / 1097 < prev    next >
Encoding:
Text File  |  1992-07-30  |  3.1 KB  |  75 lines

  1. Newsgroups: comp.os.ms-windows.programmer.misc
  2. Path: sparky!uunet!caen!sdd.hp.com!apollo.hp.com!netnews
  3. From: nelson_p@apollo.hp.com (Peter Nelson)
  4. Subject: Re: Is it really this bad, or is it just me
  5. Sender: usenet@apollo.hp.com (Usenet News)
  6. Message-ID: <Bs7KA6.2DC@apollo.hp.com>
  7. Date: Thu, 30 Jul 1992 15:27:41 GMT
  8. References: <1992Jul28.090409.1@cortex> <1992Jul28.134522.11108@usenet.ins.cwru.edu> <1992Jul29.155112.7877@microsoft.com>
  9. Nntp-Posting-Host: c.ch.apollo.hp.com
  10. Organization: Hewlett-Packard Corporation, Chelmsford, MA
  11. Lines: 62
  12.  
  13. In article <1992Jul29.155112.7877@microsoft.com> gregde@microsoft.com (Greg Demichillie) writes:
  14. >In article <1992Jul28.134522.11108@usenet.ins.cwru.edu> turnbull@ces.cwru.edu (John Turnbull) writes:
  15. >>In article <1992Jul28.090409.1@cortex> mboucher@cortex.prospect.com (Mike Boucher) writes:
  16. >>>
  17. >>>I've been having some screwy scroll bar problems as well, and Microsoft's
  18. >>>Codeview does the same thing with multiple messages from one click.  
  19. >>
  20. >>    I think you'll find the problem is that windows never gets a mouse
  21. >>up event, so it thinks you're holding down the mouse on the scroll down. I.e.
  22. >>pressing the mouse button generates the linedown, and you then break, so 
  23. >>windows never see you releasing the mouse button.
  24. >>
  25. >
  26. >This is exactly what happens.  The context switch into the debugger happens
  27. >after the mouse down and so the mouse up event is given to the debugger.
  28. >
  29. >This happens with every Windows debugger I've seen (including Codeview,
  30. >TDW and Multiscope.)  The only work around I'm aware is to use
  31. >OutputDebugString to print lots of messages in your mouse tracking
  32. >code.  Using debuggers to step through mouse handling code just isn't
  33. >my idea of fun. 
  34.  
  35.  
  36.   OK, so what CAN you debug with a Windows debugger?   For instance, 
  37.   it is clear that I can't set a breakpoint in the message handler
  38.   for the scrolling messages.   But my WM_VSCROLL handler eventually
  39.   makes calls which invalidate the rectangle, resulting in a WM_PAINT 
  40.   message.  WM_PAINT is ordinarily a low-priority message but it
  41.   can be given higher-priority or still happen quite quickly. 
  42.  
  43.   I've noticed if I'm debugging scrolling code that even if I 
  44.   set my breakpoint in my WM_PAINT message handler I still some-
  45.   times get "extra" WM_PAINT messages for a single click on
  46.   the "up" or"down" buttons on the scrollbar  -- although the 
  47.   problem is not nearly as bad as with WM_VSCROLL.   
  48.  
  49.   I mean a GUI is a mouse-event driven environment, so it would
  50.   seem that this would make LOTS of things hard to debug!   Is
  51.   this true?
  52.  
  53.   Is there a systematic way for me to know when this is a problem?
  54.   As a beginner Windows programmer I expect to make lots of problems
  55.   for myself but I don't want to have to try to guess when it's 
  56.   something *I'm* doing wrong and when it's someing *it* is doing
  57.   wrong.
  58.  
  59.   I don't have this problem debugging graphics apps with the Apollo 
  60.   debugger "dde" on Domain Workstations (Unix) here at work.  Granted
  61.   this is a "real" OS, not a toy one, but still, it doesn't seem like
  62.   it should be that hard a problem for Microsoft or Borland to fix.
  63.         
  64.  
  65. ---peter
  66.  
  67.  
  68.  
  69.  
  70.  
  71.   
  72.  
  73.  
  74.  
  75.