home *** CD-ROM | disk | FTP | other *** search
- Newsgroups: comp.os.ms-windows.programmer.misc
- Path: sparky!uunet!caen!sdd.hp.com!apollo.hp.com!netnews
- From: nelson_p@apollo.hp.com (Peter Nelson)
- Subject: Re: Is it really this bad, or is it just me
- Sender: usenet@apollo.hp.com (Usenet News)
- Message-ID: <Bs7KA6.2DC@apollo.hp.com>
- Date: Thu, 30 Jul 1992 15:27:41 GMT
- References: <1992Jul28.090409.1@cortex> <1992Jul28.134522.11108@usenet.ins.cwru.edu> <1992Jul29.155112.7877@microsoft.com>
- Nntp-Posting-Host: c.ch.apollo.hp.com
- Organization: Hewlett-Packard Corporation, Chelmsford, MA
- Lines: 62
-
- In article <1992Jul29.155112.7877@microsoft.com> gregde@microsoft.com (Greg Demichillie) writes:
- >In article <1992Jul28.134522.11108@usenet.ins.cwru.edu> turnbull@ces.cwru.edu (John Turnbull) writes:
- >>In article <1992Jul28.090409.1@cortex> mboucher@cortex.prospect.com (Mike Boucher) writes:
- >>>
- >>>I've been having some screwy scroll bar problems as well, and Microsoft's
- >>>Codeview does the same thing with multiple messages from one click.
- >>
- >> I think you'll find the problem is that windows never gets a mouse
- >>up event, so it thinks you're holding down the mouse on the scroll down. I.e.
- >>pressing the mouse button generates the linedown, and you then break, so
- >>windows never see you releasing the mouse button.
- >>
- >
- >This is exactly what happens. The context switch into the debugger happens
- >after the mouse down and so the mouse up event is given to the debugger.
- >
- >This happens with every Windows debugger I've seen (including Codeview,
- >TDW and Multiscope.) The only work around I'm aware is to use
- >OutputDebugString to print lots of messages in your mouse tracking
- >code. Using debuggers to step through mouse handling code just isn't
- >my idea of fun.
-
-
- OK, so what CAN you debug with a Windows debugger? For instance,
- it is clear that I can't set a breakpoint in the message handler
- for the scrolling messages. But my WM_VSCROLL handler eventually
- makes calls which invalidate the rectangle, resulting in a WM_PAINT
- message. WM_PAINT is ordinarily a low-priority message but it
- can be given higher-priority or still happen quite quickly.
-
- I've noticed if I'm debugging scrolling code that even if I
- set my breakpoint in my WM_PAINT message handler I still some-
- times get "extra" WM_PAINT messages for a single click on
- the "up" or"down" buttons on the scrollbar -- although the
- problem is not nearly as bad as with WM_VSCROLL.
-
- I mean a GUI is a mouse-event driven environment, so it would
- seem that this would make LOTS of things hard to debug! Is
- this true?
-
- Is there a systematic way for me to know when this is a problem?
- As a beginner Windows programmer I expect to make lots of problems
- for myself but I don't want to have to try to guess when it's
- something *I'm* doing wrong and when it's someing *it* is doing
- wrong.
-
- I don't have this problem debugging graphics apps with the Apollo
- debugger "dde" on Domain Workstations (Unix) here at work. Granted
- this is a "real" OS, not a toy one, but still, it doesn't seem like
- it should be that hard a problem for Microsoft or Borland to fix.
-
-
- ---peter
-
-
-
-
-
-
-
-
-
-