Debugging problems with WITH statement in Delphi 2006

Question

Possible duplicate:
What happened to Delphi s

I have code for debugging problems that uses the WITH clause in BDS 2006. The debugger will not show the values ​​of variables in a class or record. Am I doing something wrong or is there a mistake in BDS 2006?

type TNumber = class Num: Integer; end; implementation {$R *.dfm} var MyNumber: TNumber; procedure TForm2.FormCreate(Sender: TObject); begin MyNumber := TNumber.Create; MyNumber.Num := 10; /// MyNumber.Num Can be seen with debugger with MyNumber do begin Num := Num +1 ; /// Num is not seen by the debugger MyNumber.Num := Num +1 ; /// MyNumber.Num is seen but Num is not seen by the debugger end; end; 

EDIT:

Of course, you can use the full name of the variable. But everything becomes very dirty if you have a complex structure with more than one level.

Answer 1

With considered by many of those language features that fall into the category of "just because you have it doesn't mean you should use it." There are very few cases where I would give him a home room. I found one or two cases when it is used, it is necessary when using extremely complex multilevel structures, where the compiler does not do what you would expect, without it and it is easier to turn it on, but for 10 years of Delphi coding, I think it could be to count on the fingers of one hand.

The examples usually use quite a lot, because the code certainly looks cleaner, but in practice the effect on the service turns out whether the variable is simple or part of the structure when viewing code that you did not write or didn’t find used during the period. easily outweighs this. Known debugger issues in every version of Delphi I have ever used is clincher.

Answer 2

The debugger cannot establish a connection between the variable shown in the source code that you want to check and the associated-statement when you hover over the variable. You will need to examine the values ​​in the debug-watch window and specify the full variable there, for example. MyNumber.Num.

Answer 3

There are known problems with debugging with instruction c. This is one of the reasons I delete them when I see them. In my opinion, you should never improve coding speed due to maintainability.

The general construct that I see a lot (and learned to hate) is:

 with TMyObject.Create do try Method1(blah, blah, blah); Method2(blah, blah, blah); finally Free; end; 

You can even add to a statement with several constructs:

 with A, B, C, D do // Aargh! 

But then again, sometimes there are valid uses for the with statement if you can replace:

 ABCDEMethod1; ABCDEMethod2; ABCDEMethod3; ABCDEMethod4; ABCDEMethod5; ABCDEMethod6; 

FROM

 with ABCDE do begin Method1; Method2; Method3; Method4; Method5; Method6; end; 

Although using ABCDE bit dubious, it tends to be a "delphi mode." But now, with class helpers, we can have the right solution:

 TAHelper = class helper for TA public procedure Method1; endl procedure TAHelper.Method1; begin // You can (should) add sanity checks here. BCDEMethod1; end; 

So now you can use:

 A.Method1; 

Which is much better in my opinion.

Answer 4

The c operator is syntactic. NutraSweet: It is very similar to syntactic sugar, but leaves a bad finish and is actually harmful in the long run. Better not to use it.

Answer 5

I use C..do rarely and usually do it

 var Sc : TE_Type; begin Sc := ABCDE; sc.Method1; sc.Method2; sc.Method3; sc.Method4; sc.Method5; sc.Method6; end; 

Of course, a decent name Sc will not hurt. And I think this is clearer than with .do , and the debugger is much better. Therefore, I really like the "shortcut" variables.

Answer 6

“C” is ambiguous and may cause more problems than it solves. Think just not using it.

Castalia contains refactoring that helps remove them.

Answer 7

I am fully convinced that the scary sentence “c” was included in such a way that book authors should not have all these ugly TWinComponent lines in their code example. In real life, outside of code snippets and textbooks, there is almost no reason to use "c."

The main reason is because it interrupts the debugger. It would be very impractical for the debugger to evaluate all the sentences when searching for the value of a variable, so this is not an error, but simply unsupported in all delphi debuggers that I know of. If you are like me, you’re stuck supporting hundreds of thousands of lines from a programmer who basically copied everything from a textbook, he is debugging a living hell.

Bottom line, DO NOT USE C-CLASSES ... EVER!

Answer 8

C is not a bad practice. The only bad thing is that you cannot easily debug these lines, but if you use it carefully, there is no problem. This may not be a good practice for juniors, but if you know where to use it, that's fine.

Allows EMBA to improve it in any way to avoid common negotiation.