gettingstarted
[Top] [All Lists]

Re: ARGH!

To: Getting Started <gettingstarted at lists dot realsoftware dot com>
Subject: Re: ARGH!
From: "Chip G." <n1mie at myeastern dot com>
Date: Tue, 30 Aug 2005 12:04:36 -0400
Delivered-to: gettingstarted at lists dot realsoftware dot com
References: <BF39B67C dot 18AF2%sean at rulessoftware dot com> <A9FC3F83-1DEF-44AE-B628-52BEE937A1D3 at myeastern dot com> <a06200707bf3a1c2ef2f8 at [10 dot 0 dot 1 dot 4]> <53695C84-BED8-418B-8CA5-3F418041AEA6 at myeastern dot com> <a0620070dbf3a2eba4b9c at [10 dot 0 dot 1 dot 4]>
On Aug 30, 2005, at 11:43, Joseph J. Strout wrote:

I'm not sure what to suggest, except the obvious things: if it's not painting correctly, try a breakpoint in Paint; if it doesn't respond properly to clicks, try a breakpoint in MouseDown or Action; and so on.

The problem, as you might guess from the other thread (pardon the pun), is on quitting the program. And since I don't have any quit code I don't have anywhere to put a breakpoint. So why is quit different than clicking on the sole window's close button? And where do I put a breakpoint to check?

But note that trying to use the debugger on UI issues (especially the Paint event) can sometimes cause the problem to squirm around, as deactivating your app to bring the debugger forward triggers other events (Activate, Deactivate, Paint, etc.). So this may itself change the behavior. In such cases, the best approach is to either use logging instead (e.g. System.DebugPrint), or run your app on another machine via remote debugging.

No idea how to do that ... I'll have to look into that. Covered well in LR or UG?


-- Chip


_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

<Prev in Thread] Current Thread [Next in Thread>