John Brown wrote:
I don't pretend the situation is always black and white nor do I profess to
a have complete understanding of all the issues since I don't work on
debuggers for a living. I'm sure you (probably) don't either.
You don't need to work on debuggers for a living to understand the
difference between the debugger showing you static information and
having to run code to evaluate something.
You are asking it to do the latter, and so it should be obvious that the
result is going to reflect the _current_ state, not some state in recent
history (such as when you interrupted the process with the debugger).
I just didn't
start programming yesterday however. I've been in the coding trenches longer
than most and I know the situation isn't always cut-and-dry.
How long you've "been in the trenches" is irrelevant. I do note that
many people, when they run out of factual things on which to base their
arguments, resort to that sort of comment though. They are essentially
saying "I have more experience than you, so you should just believe me".
In my own experience, those people are usually wrong about both parts of
that claim, though I admit that every once in a great while someone
comes along who can at least make claim to the first.
There are costs
to pay sometimes and they may be prohibitively expensive. This is a deep
area after all. What I'm expecting here however is completely legitimate and
correct even if someone demonstrates that it's too (intrinsically) expensive
to provide.
I don't know how you are defining "completely legitimate", but by my
definition what you want is definitely _not_ "completely legitimate".
It's not that what you are asking for is simply "too expensive to
provide". It is, but that phrase doesn't really convey the
impracticality of what you think is the correct behavior.
You are looking at just one property. But for the debugger to behave in
a consistent way, if the debugger is going to give you what you want, it
must evaluate _EVERY_ possible function call and cache the results of
that. Even if you want to limit the behavior to properties (not
logical, IMHO, but hey...let's give you the benefit of the doubt), the
debugger would still need to evaluate _EVERY_ possible property of
_EVERY_ class instantiated, along with _EVERY_ static property of every
class that is referenced in the application.
It is absurd to think that that's somehow a desirable thing to have the
debugger do in the general case. Even ignoring for the moment the
riskiness of calling code arbitrarily every time the debugger interrupts
the process, the number of function calls required to do that, and the
amount of memory required to store all of the results, is not only
"expensive", it's simply prohibitive.
And before you start typing trying to debate the above, you need to
consider what a property really is: it's just a method that returns a
value. The value could come from anywhere; it's not necessarily just a
matter of retrieving something that's already in memory, doing so could
at the very least require allocation of an arbitrarily large data
structure, as well as the execution of code with any number of
undesirable side-effects (yes, properties should IMHO be free of
side-effects but there is no guarantee that they are)
And addressing manually specific cases such as yours is trivial, without
changing the way debuggers work today.
That argument I can accept. What I don't accept is someone
telling me I'm being unjustified and that this has more to do with me "not
liking what's happening".
I wrote that because it seems to me that anyone who stopped to think
about the implications of what they are demanding would quickly realize
how impossible the demand is. That leaves me with the conclusion that
you must NOT have thought about the implications and thus are basing
your demands simply on what you want, rather than what can actually be done.
Expecting a debugger to return this type of
information is not only justified, it's what anyone would naturally and
reasonably expect.
No, it's not "what anyone would naturally and reasonably expect". A
simple Google search would reveal to you a relative lack of complaints
similar to you (as in, practically none), in spite of the relatively
large number of people writing Windows code.
Can you point to a single commonly used debugger that supports the
behavior you are expecting?
The irony is that after many years of programming in the
C++ world I don't recall ever having the types of debugging problems that
seem to be commonplace in the .NET world (including very serious issues
trying to debug threads in a form-based application but that's another
story).
For you to feel that this is a serious debugging problem, and in
particular that it's somehow unique to .NET, suggests to me that you do
not in fact have very much experience writing GUI code, especially under
Windows (though this exact issue does exist on other platforms).
And frankly, these issues aren't really even all that unique to a GUI.
On a text-only platform, you run into the same sort of thing, if your
code happens to change or query the state of the output device and the
same output device is used both for program output and debugging. They
are perhaps a bit more pronounced on a GUI, but they are not unique to a
GUI, and they are _certainly_ not unique to .NET (one extremely common
example is trying to debug a redraw event handler -- WM_PAINT, OnPaint,
whatever -- where the mere act of having the debugger interrupt the code
in the redraw handler causes the invalidation of the thing being
redrawn, forcing another redraw event immediately after finishing the
current one).
Let me be clear: this is not a .NET problem. You would have the same
issue if you were writing native Win32 code and calling
GetActiveWindow() or GetFocus() (which are the equivalents of the
ActiveForm property).
Pete
