Anyone know how to add a "Debug window" in own app

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi, guys

we all using the VS.net IDE's debug window, such as "Watch window", "Auto
window". but anyone know is any way or API provided for us to include a debug
window in our own app?

looking forward the replied, thanks guys
 
BillyLiu007 said:
Hi, guys

we all using the VS.net IDE's debug window, such as "Watch window",
"Auto window". but anyone know is any way or API provided for us to
include a debug window in our own app?

looking forward the replied, thanks guys
Click to expand...

There's no simple answer.

If you use the System.Diagnostics.Debug class (I advise people not to
use Trace) then the default trace listener will send the data to the
output debug stream. This writes data to a memory mapped file and its
fairly simple to write code (using platform invoke) to read data from
that. Its probably better to write your own trace listener class and use
this to write the received data to a text box on a form.

Another thing that I have done in the past is to write a TextWriter
class and used an instance of this as the Console.Out object, so that
all Console.Write and WriteLine output goes to my TextWriter. I then
write the data to a text box on a form.

Richard
 
cody said:
Why not? Are there disadvantages?
Click to expand...

Because TRACE is defined in Release builds by VS.NET. The default trace
listener will generate trace messages that write to the
OutputDebugStream. This writes the data to a memory mapped file
protected by two events. The code that reads output debug strings
controls whether the writing process can write the strings by setting
these events. If the reading process says the writing process cannot
write, then the thread in the writing process is *blocked*. (There is a
timeout, IIRC it is a second). The point is that a process reading the
output debug stream controls whether writer threads in *all* processes
on your machine can be blocked.

My opinion is that as the developer of the code I don't want some other
process to affect my application's performance. Yes, you can use the
config file to remove the default trace listener, but how do you know
that the people who use your code won't alter the config file? (Deleting
the config file will enable the default trace listener.)

Also the default trace listener implements Assert as a modal dialog, so
if you've got any Trace.Asserts in your code, these will work in Release
mode. This means that when your application dies just before it goes you
give your customer a nice dialog saying that you thought it might die,
and here's the reason why! Not particularly good PR, especially since it
appears as if you are using your customers to do your QA. And a modal
dialog blocks the thread, so the process will not die immediately, which
can be a real pain if the process is a service running under a
non-interactive account because you won't see the dialog! (Years ago I
was bitten by this - I used a library written by Oracle in a service and
this library would ocassionally put up a modal dialog indicating that I
had called code that should be there, but they hadn't written yet, and
this would block my service thread!)

Also, call me a secretive if you like, but I really don't want my
customers to see my debug information. <g>

Richard
 
Very interesting, yes this sounds reasonable. But if somebody wants to log
debug messages in a release build using Trace.WriteLine or Console.WriteLine
is the only way?
 
cody said:
Very interesting, yes this sounds reasonable. But if somebody wants
to log debug messages in a release build using Trace.WriteLine or
Console.WriteLine is the only way?
Click to expand...

This is an argument I have had many times. It's my opinion that you
shouldn't trace messages in Release mode. After all, you should have
done all of your debugging in your testing cycle. However, some people
do insist on adding traces to their Release mode because they like their
customers to take part in debugging their code <g>.

If you *really* insist on adding trace messages then the most important
thing to do is add the following to the entry point of the process:

Trace.Listeners.Remove("default")

This will ensure that the DefaultTraceListener that the runtime insists
on giving you for free is not there. After you dio this it means that by
default you do not trace any messages. If you choose to include your
customers in your 'debugging session' then you can ask them to trace
messages by adding the appropriate settings to the config file.

Richard
 
Back
Top