Why not cleaner debugging?

Posts   
 
    
Posts: 6
Joined: 21-May-2008
# Posted on: 08-Jun-2008 22:01:48   

Currently when you watch an entity in the debugger a generated class, there are lots of seldom used members cluttering the display such as AlreadyFetched<variousnames>.

Couldn't this be made much cleaner by adding a derived class somewhere that contained these members, so that looking at the debug view for the entity becomes very clean and simple?

That way if I have a table with 3 columns I mostly see just 3 properties, and if I need to see all the plumbing I can just click on +base in the debugger.

regards, LTG

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 09-Jun-2008 10:16:13   

The members won't go away as they're public properties of the class. We can't remove them as they're already released as part of the interface.

I pressume you're mainly interested in the values of the fields ?

Frans Bouma | Lead developer LLBLGen Pro
Posts: 34
Joined: 08-Nov-2007
# Posted on: 09-Jun-2008 15:37:40   

I remember reading in Debugging .Net 2.0 application there are attributes that you decorate the properties so they are effectively hidden in the quick view / watch windows, of course you can see them explicitly if typed. I dont have the book at hand today but if google proves pointless I'll look it out tonight.

You can apply these to the templates.

Posts: 6
Joined: 21-May-2008
# Posted on: 09-Jun-2008 19:43:50   

**>>I pressume you're mainly interested in the values of the fields ? ** Well user values and user methods. 90% of the time people will not need the lower level LLBLGen properties/methods.

>>The members won't go away as they're public properties of the class. Oh yes they will simple_smile

Consider a class generated called CategoriesEntity.

If I were LLBLGen I could have simply named this class CategoriesEntityBase, and then generated a derived class like this:

class CategoriesEntity : CategoriesEntityBase { public CategoriesEntity() {}

    public int CategoryName  // plus other user data and user methods
    {
       get { return base.CategoryName; }
    }
}

Now an instance of this class could be created like this: var cleanEntity = new CategoriesEntity();

Then when viewing cleanEntity in the debugger you will see only this beautiful sight: cleanEntity +base CategoryName

So this is one way it could be done with no interface or client or performance implications.

I think the other poster is correct that it can also be done via decorations, but I haven't researched the syntax of that approach.

Regards, LTG