Virtual Developer Workshop: Containerized Development with Docker

Debugging GUI applications for me mostly consists of printing out debug statements in the form of a dialog box with some text. While this technique was helpful for small to medium size apps I find writing large apps with a dialog box popping up after every other statement is counterproductive. With this in mind, I set out to find a better method for displaying debug statements during runtime. Enter C#.

C# solves three problems I faced when designing the useful and scalable debugging system. These problems exist either in Java, C/C++, or both (my main programming languages).

  1. Not having very much meta-information (e.g. line number, method name, etc.)
  2. Having to add and remove debug statements whenever the debug focus shifts
  3. Having the debug statements compiled into the program affecting performance

Ok, discussing the solution for these problems in order we'll start with number one. Basically a few classes from the System.Reflection and System.Diagnostics namespaces solve this problem. Using the System.Diagnostics.StackFrame class the call stack can be explored and stack details such as what is on the stack level above the current one, what line is a function being called from, etc. And with the System.Reflection classes the names of functions, namespaces, variable types, etc., can be ascertained. Applying all this to the problem at hand here's some code that retrieves the file name, line number, and method name of the function that called it.

// create the stack frame for the function that 
// called this function
StackFrame sf = new StackFrame( 1, true );

// save the method name
string methodName = sf.GetMethod().ToString();

// save the file name
string fileName = sf.GetFileName();

// save the line number
int lineNumber = sf.GetFileLineNumber();

Moving right along to problem number two let's discuss how to selectively debug different sections of a program during runtime. Number two ties in with number one in that information from number one will help us filter debug statements from being displayed. For this example we'll filter by namespace. So say that you have fifteen namespaces in your program and right now you only want to display debug statements from one all you would have to do is tell the debug class only allow that one namespace to display debug statements. Simple enough. Here's some code.

// create the namespaces hashtable
  namespaces = new Hashtable();
  // get the assembly of this class
  Assembly a = Assembly.GetAssembly( new Debug().GetType() );

  // now cycle through each type and gather up all the namespaces
  foreach( Type type in a.GetTypes() )
    // check if the namespace is already in our table
    if( ! namespaces.Contains( type.Namespace ) )
      namespaces.Add( type.Namespace, true );

The above code will create a Hashtable object containing all the namespaces in the same assembly as the Debug class of which this code is a part. Of course, this is only half of the solution so here is the actual filtering code.

// only proceed if the namespace in question is being debugged

 if( (bool) namespaces[ method.DeclaringType.Namespace ] )

   // this is where the debug statement display code would be

Ok, so far so good. With the problems number one and two knocked out that leaves us with the obstacle of removing those darn debug statements when the final release is to be made without actually having to manually comment out or delete each one. This is where those handy little things called attributes come in to play. Assuming you have knowledge of how attributes work in C# I'll cut to the chase and introduce the ConditionalAttribute which is part of the aforementioned System.Diagnostics namespace. So here's some showing how to use the ConditionalAttribute class.

  public void Debug( string msg )
    // this is where the debug statement 
    // display code would be

What this will do is when this program is compiled it will check if 'DEBUG' was #defined and if it was then the call to this function will be remain, however if 'DEBUG' is not #defined all calls to this function not will be compiled leaving us with no performance hit.

Now, some of you are probably saying that you could solve some of the problems above in C/C++ and Java. I will note that neither language solves all of them. For example in C/C++ you can #define and #ifdef much like you can use ConditionalAttribute class and C# defines. But getting useful meta-information in C/C++ is limited. And in Java getting meta-information is possible but as far as I know all the code is always compiled (i.e. there's no Conditional type functionality). Thankfully there is C# which does solve (gracefully I might add) all the problems I mentioned above and quite a few more.

To demonstrate these techniques I wrote a small windows application along with this article. The Debug class can be plugged into your own projects. So enjoy and happy coding.

About the author

Mike Borromeo is a college of engineering student at the University of Michigan (AA). He has experience in C/C++, Java, C#, PHP, VBScript, JavaScript, MSSQL, and HTML. He can be reached at MikeD227@hotmail.com. The ideas and code for this article were developed as part of the Gnutella client project Phosl (http://www.phosl.com).


Download source - 10 Kb


  • Debugging help...

    Posted by keefers on 06/26/2005 10:51pm

    I understand that these questions do not go with the above article but I am in need for help so... Hi, my name is Keith Proctor and I am have a debugging problem that I am hoping you can help me with. I have an application that uses clipping rects in a .NET 2003 application. The problem is that the clipping region is growing but I can't determine who is doing it. The application generally calls an internal SetClip() function so I have been able to validate that this particular problem is that nobody is calling the internal SetClip() function. It appears that somebody is calling the OS's function for clipping directly. Clipping is called 20-30 times per second so this is a difficult problem as a print statements would generate so many statements that the results are difficult to look at, and hasn't helped so far. Every time I try to debug this problem it appears that I generate 2-3 pages of output that doesn't help. I can install a break point close to where the problem is but there is still a lot of places that it could be happening. It is even possible that a system call to TrackPopupMenu() could be the cause. I've tried tracking the DC's Box and Rect before and after TrackPopupMenu(). The Rect is good before but not after the call to TrackPopupMenu(). I don't know if somebody has installed a callback that is called by the system or if TrackPopupMenu() has a problem. I suppose the last detail is the hardest to take. The problem seems to have occurred during the development process as this code and everything directly touching it hasn't changed. Although it appears like TrackPopupMenu() is a possible cause, it doesn't seem likely, since the code nearby hasn't changed. Is there some system functionality, that could help, that I'm unaware of? The guy who would normally track down these graphic defects is now on vacation for several weeks in Australia and we are trying to ship before his return. ___Any___ help or clues would be appreciated. Temporary, newbie graphics guy, Thanks, Keith Proctor Home of keefers castle www.keeferscastle.net

  • You must have javascript enabled in order to post comments.

Leave a Comment
  • Your email address will not be published. All fields are required.

Most Popular Programming Stories

More for Developers

RSS Feeds

Thanks for your registration, follow us on our social networks to keep up-to-date