Tech Tip: What is my DevForce Application doing? Use the TraceViewer to Find Out!

Level 100 DevForce Express

   Level 100 
DevForce Express
November 2, 2006
There is a lot of interest in Part 2 of my essay on "Grid Designer Dangers". It's coming. We want to do the topic justice, and we want to reflect the improved grid designing capabilities of our new 3.3.0.1 release. We'll publish Part 2 in a week or two at the most.
�          I added an external configuration file but it doesn't seem to be having any effect on the application. Is the app using the new file or the old, embedded file?
�          My application was running fine. Then I added a grid which I filled with a few hundred items and suddenly it's balky and slow. What happened?
�          I've instrumented my code with messages that I am writing to the DevForce debug log. I know I can see the log in a browser. But I always have to refresh it. Can I watch the log change as the events happen? 
You may know already that DevForce publishes many routine messages to your application's DebugLog. The standard messages concern configuration file discovery, assembly discovery, and every attempt to access the database. You can supplement the DevForce messages with custom messages of your own.
The DebugLog itself is an XML file that resides in your executable directory by default.

I can double-click the log to view it in a browser which will render it in reasonable fashion, thanks to its companion CSS and XSL files. That's great for a post-mortem but a little hard to use if you want to watch log updates as they happen.

I Need the DevForce TraceViewer
The TraceViewer is a DevForce mini-application that gives me a live view of the debug log. I can launch the TraceViewer within my application and see each message as it is posted to the log. 
Here's a snapshot of the TraceViewer showing custom messages from my application login.

Here is a message showing that the application found the DevForce configuration file, IdeaBlade.ibconfig, in the AppHelper assembly after looking first in the executable directory and then inside the executing assembly.

The record of database access attempts is essential for understanding performance problems, especially in grids. Here we see the fetch of all Employees.

Later we see the DevForce persistence layer fetch the Orders of a single Employee.

If the command is too long to view in the grid, we can double-click the message cell and see the message in a dialog.

Using TraceViewer Information to Resolve Problems
Suppose our application displays a grid with hundreds of Employees. Each grid row includes a digest of an employee's orders - the number of orders, the customers, the total dollar values, etc.
If we code the grid in a naive way, with no attention to performance, we will see a flurry of entries in the TraceViewer. Every time the user scrolls from one employee grid line to the next, we see a new flurry. The messages will really fly if the user clicks a column header to sort the grid.
We scroll back through the messages and see the problem. DevForce is making a lot of little trips to the database. There is a trip for each employee's orders. There's another trip for each employee order's customer. There's another trip for each employee order's item details. No wonder the application is a dog.
There was nothing wrong with our original naive implementation per se. Our first goal should be to make the application work using the simplest approach necessary. We accomplished that goal. We were not going to anticipate a performance problem before we had a performance problem.
Now that we have performance problem, the TraceViewer helps us identify it quickly so we can fix it.
Fortunately, the fix is easy: we add spans to the query so that DevForce makes a single request to fetch all of the employee, order, customer, and item detail data that we know we're going to display in the grid. Problem solved.

Note: 
Span queries are a topic for another Tech Tip. You can read about them in our Developers' Guide.

Add the TraceViewer to Your Program 
It's incredibly easy to do.
1.       In your start-up project, add a reference to IdeaBlade.UI.WinForms.PlatformControls. 
2.       Open your start-up class (typically Program.cs or Program.vb). 
3.       Find the static Main method (Shared Main in VB). 
4.       Make some room just below any calls to the Application class (e.g., Application.EnableVisualStyles()). 
5.       Add the following code to show the TraceViewer. 
// C#:
IdeaBlade.UI.WinForms.PlatformControls.TraceViewerForm traceForm;
traceForm = new IdeaBlade.UI.WinForms.PlatformControls.TraceViewerForm();
traceForm.Show();
' VB.NET:
Dim traceForm As _
   New IdeaBlade.UI.WinForms.PlatformControls.TraceViewerForm()
traceForm.Show()
That is all there is to it. Next time you launch your application, the TraceViewer will appear, followed shortly thereafter by your application's main window. You can toggle between the two windows at will.

Why Don't I Just Use SQL Profiler?
Use SQL Profiler by all means. It's a fantastic tool for monitoring database activity dynamically in much the same was as you use the TraceViewer.
 You still want to launch the TraceViewer for a number of reasons, including:  

Your application launches the TraceViewer for you; you have to remember to launch the SQL Profiler. 
The SQL Profiler only tells you about database activity; the TraceViewer captures other application activity in addition to database activity. 
You can customize the messages in the TraceViewer so you can see what part of your application results in a specific database request. 

Conclusion

 The TraceViewer is a critical development tool that's easy to run. I add the TraceViewer to my application within the first five minutes of coding. It's a great habit to get into; make it one of yours.

Notes:
�          The TraceViewer runs in the same process as your application. You can run it in a separate process if you prefer. It takes a tiny bit more work; see the Developers' Guide for more information. 
�          You can close the TraceViewer without shutting down your application. 
�          I don't want my customer to see the TraceViewer. I wrap those launch lines in compiler debug directives so the TraceViewer never shows in release mode. 
�          N-tier deployment results in a slightly different approach to logging. The Developers' Guide can tell you more. 