Re: Debuging by value
From: Jason (mite51_at_hotmail.com)
Date: 10/01/04
- Next message: CJ Taylor: "Re: Decompiler.NET reverse engineers your CLS compliant code"
- Previous message: Daniel O'Connell [C# MVP]: "Re: XML Parsing in C#, Finding null string"
- In reply to: Arjang: "Re: Debuging by value"
- Next in thread: Jason: "Re: Debuging by value"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 30 Sep 2004 21:01:37 -0700
You are correct, sort of. By that I mean that if I were not using an
accessor it would be a problem of inadequate design. In this case however I
am using a class and property accessor that is very frequently used. The
problem is I want to know when a specific instance of a classes specific
value has changed, which is the real power of debugging by value (another
big one is catching memory leaks ). Also the problem is that the property in
question is a sealed microsoft class ( GraphicsPath ) and I have no way of
putting a break point exactly where I want it, tho I do have accessors to
access those accessors.
Jason
"Arjang" <nospam@me.com> wrote in message
news:e3Ju0a2pEHA.192@tk2msftngp13.phx.gbl...
> Please excue my ignorance, but if the changing points
> of data are well defined ( e.g. using OOP's properties or just set and get
> methods) why would there be a need to this type of debugging?
> This type of problem belongs to users of Global Variables.
> Please correct me if I am wrong
>
> "Bob Grommes" <bob@bobgrommes.com> wrote in message
> news:OwhYvS2pEHA.708@tk2msftngp13.phx.gbl...
> > Jason,
> >
> > You've touched on one of my few gripes about C#.
> >
> > Inexplicably, C# does not support data breakpoints. I was astounded
that
> > such an incredibly useful capability is absent in C# when it's been
> > supported by other Microsoft debuggers for years (FoxPro, for instance).
> >
> > Actually the debugger seems rather lame in evaluating expressions
> > generally. Frequently, perfectly valid expressions (often easy ones,
such
> > as someString.Length > 0) are rejected by the debugger. This needs
> > fixing.
> >
> > In the meantime you just have to kludge this sort of thing into your
code:
> >
> > #if DEBUG
> > if (Debugger.IsAttached == true && someCondition == true) {
> > Debugger.Break();
> > }
> > #endif
> >
> > --Bob
> >
> > "Jason" <Jason@mobiform.com> wrote in message
> > news:eNMMyM1pEHA.516@TK2MSFTNGP09.phx.gbl...
> >> In the c++ debugger I could give it a memory address of some data and
it
> >> would break when that data changed. It is very helpful when you have a
> >> single value change of a large amount of code and you just want to know
> >> what/where/why its changing. I tried to hook it up like I in C++,
opening
> >> up
> >> the new break point window, going to the data tab and supplying a
> >> pointer...
> >> just for fun I put in the var name ( since there are no pointers in
c# )
> >> hit
> >> ok and I got the message.
> >>
> >> "C# does not support Data Breakpoints"
> >>
> >> Is there some other way of achieving the same task? Like I said it is
> >> immensely helpful in some debugging situations, usually the worst
> >> situations.
> >>
> >>
> >
> >
>
>
- Next message: CJ Taylor: "Re: Decompiler.NET reverse engineers your CLS compliant code"
- Previous message: Daniel O'Connell [C# MVP]: "Re: XML Parsing in C#, Finding null string"
- In reply to: Arjang: "Re: Debuging by value"
- Next in thread: Jason: "Re: Debuging by value"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
