I just saw Dino's post on his wish list for ASP.Net tracing and saw he wanted the tracing window in a popup window. This is something we wanted for our web apps as well, so here is how I tackled the problem. I know its not perfect and the output is still put out to the main page, but the reason why I had to come up with this scheme was because in our web apps we are using absolute positioning. When we did this our content was placed over the top of the trace div.
Here is the code.....
============== Parent ASPX Page =================
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" >
<HTML>
<HEAD>
<TITLE>Parent Page</TITLE>
<SCRIPT>
function SetupTraceWindow()
{
var div = GetTraceDiv();
if(div==null) return;
win = window.open("Trace.htm","Trace");
if(win==null) windown.status="The trace window was blocked. Please make sure popup blockers are off.";
}
// Called by the child window to get the html of the trace output and also hides the trace output on the parent page.
function GetTraceHTML()
{
var div = GetTraceDiv();
if(div==null) return "";
var html = div.outerHTML;
div.style.display="none";
return html;
}
// Returns the div that is created by the ASP.Net trace function
function GetTraceDiv()
{
var div = document.getElementById('__asptrace');
return div;
}
</SCRIPT>
</HEAD>
<BODY ms_positioning="GridLayout" onload="SetupTraceWindow();">
<FORM id="Form1" method="post" runat="server">
This is the parent page.
</FORM>
</BODY>
</HTML>
======================= Trace.htm =======================
<!DOCTYPE html public "-//w3c//dtd html 4.0 transitional//en">
<HTML>
<HEAD>
<TITLE>ASP.Net Trace Output Popup</TITLE>
<SCRIPT language="javascript">
function SetupTrace()
{
var html = opener.GetTraceHTML();
document.writeln(html);
opener.focus();
}
</SCRIPT>
</HEAD>
<BODY onload="SetupTrace()">
<DIV id="myTrace"></DIV>
</BODY>
</HTML>
Clarke Scott just posted about some free tools that could be found at http://devcenter.infragistics.com/. While I was there I noticed an article about JavaScript debugging and decided to see if there was anything new there. (A direct link to the article is http://devcenter.infragistics.com/Articles/ArticleTemplate.Aspx?ArticleID=2183 I have never seen this technique for debugging JavaScript before and it will be a true time saver for me to help debug all the JavaScript we do in our apps. If you are looking for a way to debug JavaScript you need to check this article out. While the IE script debugger has always been available it has never worked well enough for me as I had numerous problems with it and it also did not debug JavaScript include files. This technique does just that.
*EDIT*
Here is a snipped from the article as a reference. I did this just in case they ever take down the article.
ASP.NET has many advantages over classic ASP in the area of debugging. You can now easily debug your server-side code using the full power of a modern debugger such as Visual Studio .NET. This, along with the introduction of server controls and a postback architecture, has simplified Web-based development. But what about the other half of a Web application, the client-side script?
Although server controls and postbacks have reduced the need for Web developers to interact with JavaScript in an ASP.NET application, many developers are learning that they cannot forget about client-side scripting altogether.
Developers creating Web pages designed to display even a moderate amount of data know the cost of posting back to the server. Using JavaScript to perform simple tasks minimizes the number of roundtrips to the server, potentially avoiding unnecessary queries to the database and reducing the number of times the ViewState is pushed over the wire.
Besides reducing the amount of network traffic, the use of client-side JavaScript enables ASP.NET developers to provide a richer and more interactive experience to the end-user. By moving appropriate functionality from the server to the client you provide the user with instant responsiveness and feedback without the latency implicit in a postback. Balancing functionality between both the client and the server helps reduce some of the load on the Web server, which in turn yields better server response times.
A substantial roadblock to using JavaScript, though, is that it can be difficult to write and debug.
First, IntelliSense for JavaScript is limited at best, which leads to errors in the initial coding stage. Because JavaScript is case-sensitive, the lack of IntelliSense can be aggravating - particularly for developers turning to ASP.NET from a case-insensitive language like Visual Basic.
Also, when a browser's JavaScript error message provides a line number to look at, it often doesn't match the line numbers indicated in the code. The line number will get you in the right area, but after that, it often becomes a guessing game.
Furthermore, if you try putting a breakpoint in the JavaScript in your ASPX, you'll find that when running the project, control will not stop on it and, at best, you may get the not-so-helpful message, "Breakpoint will not be hit, symbols have not been loaded for this document."
Tap into HTML
With Internet Explorer 6 and VS .NET, Microsoft has provided a way to tap into the HTML and JavaScript that Internet Explorer is running, thereby closing the loop in the debugging cycle. By closing this hole developers can now debug their entire application in a single IDE - from client-side script to server-side code, and possibly right through to the database.
Unfortunately for most developers, this won't work without some basic set up. To verify that Internet Explorer is set up correctly, open Internet Explorer, choose Tools | Internet Options. Click the Advanced tab and find Disable script debugging about halfway down the list. Make sure there is no check in the box next to this option. Click OK and close Internet Explorer. The browser is now ready to work with Visual Studio .NET to debug your application.
To begin exploring the basic functions of the debugger, start a new WebForms project and run it without adding any controls or code. When the empty project loads in Internet Explorer, return to Visual Studio and open the Running Documents window by selecting Debug | Windows | Running Documents from the Debug menu.
The Running Documents window will appear docked on the right edge of the IDE. The name of the page, "WebForm1.aspx", will appear in the window. Double-click the page and the HTML rendered to the browser when the ASPX page was evaluated by the server will be shown in a code window on the left.
The code provided by the Running Documents window is where a developer can set breakpoints and step through the code, just like in server-side code.
Debug Startup Code
Unfortunately, the technique described above breaks down when you try to debug code that executes on start up, such as from a server-side Page.RegisterStartUpScriptBlock method in the page load event. Because the JavaScript code runs as the page loads, you have no opportunity to return to the IDE to set a breakpoint.
Debugging startup script code requires a different method for debugging. There are three ways to debug startup script. First, start your project with F10. Pressing F10 will load your default startup page in the browser and immediately put you in break mode on the first line of JavaScript. You can then set another breakpoint elsewhere in your code, or you can step through line by line until you reach the line of interest.
Next, run the page, let the error occur, then set the breakpoint and hit F5. This method comes in handy when you receive an unexpected error. After the page has loaded in your browser and you get an error or incorrect behavior, open the appropriate Running Documents window and place a breakpoint where you would have wanted execution to stop. Return to the browser and hit F5. Visual Studio .NET will recognize that this is the same page you loaded before and will keep your breakpoint in place. When execution reaches the breakpoint, control will return to the IDE.
Finally, use the debugger keyword. The debugger keyword works just like a breakpoint. When the JavaScript interpreter reaches this keyword, it halts execution and returns control to the IDE.
Debugging startup script is a little more difficult than debugging script behind a button click or a validation routine because it is hard to insert a breakpoint at the right place. Starting the page with F10 or using the debugger keyword can help break into the code. From that point, a developer can find the errors in his logic using the same powerful tools he is accustomed to using with server-side code.
Visual Studio .NET provides the same powerful and flexible tools for debugging your client-side code as it does for server-side code. Get the most out of Visual Studio .NET by using the techniques described here to close the loop and debug your entire ASP.NET application in one IDE.