Debug.Print in VB

[WhoIsThat]

Is there an easy way to send Debug.Print in VB6 to a text file? I have this code from somewhere else and there are debug.print all over the place. I am trying to avoid creating another class that does this job, since it is all over the places (some 60+ classes).

Any help is appreciated. Thank you.

 

[tkdkid]

Well, you could always just use ctrl-a to select all the text in the debug window and then copy/paste it into notepad.

 

[VBboy]

I don't know if you still want your answer.. I was just going through all the VB questions.

Do a "Search and Replace" on your code and replace "Debug.Print" with say "DebugPrint". Then, simply implement DebugPrint as a function which will send your output to file instead.

Using Debug.Print directly is generally a bad practice (as you now know ).
Instead, implement a function like I suggested, and then you can add new types
of debug printing, such as to screen. Then you will need to change your code
just once.

 

[calpha]

Originally posted by: VBboy
I don't know if you still want your answer.. I was just going through all the VB questions.

Do a "Search and Replace" on your code and replace "Debug.Print" with say "DebugPrint". Then, simply implement DebugPrint as a function which will send your output to file instead.

Using Debug.Print directly is generally a bad practice (as you now know ).
Instead, implement a function like I suggested, and then you can add new types
of debug printing, such as to screen. Then you will need to change your code
just once.

Just curious....but why do you consider debug.print a bad practice? A compiled .EXE removes all debug.prints and debug.asserts.

And to the original post. VBBoy's method is by far easier.

However.....you could accomplish the same thing with an Add-In ....and other then being something different to write.....using the general function like vbboy said would be better. Besides the add-in would require "interaction", wouldn't run in the .exe......and the function wouldn't.

I just started writing add-ins a year ago. I still don't know how CodeSmart made their new window w/i the ide......

 

[VBboy]

Originally posted by: calpha

Originally posted by: VBboy
I don't know if you still want your answer.. I was just going through all the VB questions.

Do a "Search and Replace" on your code and replace "Debug.Print" with say "DebugPrint". Then, simply implement DebugPrint as a function which will send your output to file instead.

Using Debug.Print directly is generally a bad practice (as you now know ).
Instead, implement a function like I suggested, and then you can add new types
of debug printing, such as to screen. Then you will need to change your code
just once.

Just curious....but why do you consider debug.print a bad practice? A compiled .EXE removes all debug.prints and debug.asserts.

And to the original post. VBBoy's method is by far easier.

However.....you could accomplish the same thing with an Add-In ....and other then being something different to write.....using the general function like vbboy said would be better. Besides the add-in would require "interaction", wouldn't run in the .exe......and the function wouldn't.

I just started writing add-ins a year ago. I still don't know how CodeSmart made their new window w/i the ide......

CodeSmart ROCKS, baby! By far the best IDE enhancement tool on the market.

Debug.print is not good because sometimes you need to redirect all your debugging to a file, or just turn it off. This is why I recommend writing the most basic DebugPrint function. In its most basic form, it will simply do Debug.Print. However, if you decide to turn debugging off using a global flag, or to redirect output to a file, or to a separate window instead, you have once central point to do it from. This is what functions are for . I do the same thing for my debugging "cout <<" in C++. Then I have one place to turn it all on, off, or to change it behavior.

 

[calpha]

Actually, I love debug.print and debug.assert.......

but i do have a function that I use for a Call-Stack Trace (very simple...nothing w/ the physical call-stack)...and I do the same thing......I can agree to differ....but you're point is valid.....alhtough I still wouldn't call it bad practice.

C++/Java on the other hand. Hands down, you're right....btw. That's the only way I know how to debug java is have the var to turn off and on for my trace statements.....

 

[VBboy]

Well, ok, Debug.Print is not a bad thing to do per se'

But I write large apps (10+ files in the project, a hundred pages long or so), and using Debug.Print is quick and dirty for me. Let's say you need your customer to send you a bug report. By having your debug feature dump it all to the file, you allow the user to send you a detailed report with little effort.

But is smaller apps, sure, it's Debug.Print all the way.

 

[calpha]

A-Ha. Now you've caught on to the key!

All my apps have a stack error trace built in......the error trace is always saved, but only written when an error occurs, and it goes to a flat file.

Public mySub()
const subName = "mysub"

on error goto errorLog:

<line numbers>:
errorLog:
logError subName, err.description, erl, err.number

Line numbers added thanks to codesmart......sub headers, and error handler added thanks to me and my own add-in.

Having the stack trace + error numbers is a huge huge bonus. I've been doing that for a year (since I found code smart)....and I love it.

In the IDE.....I use debug.print mostly for quick status messages, and don't use it at all in error handlers.

 

[VBboy]

calpha, is you company hiring talented young Visual Basic programmers, by any chance? I am somewhat unemployed at the moment.

 

[calpha]

Nope.
I'm in the unemployed line too.

And I'm even in RTP, a tech GOD area....alll kinds of companies, and I can't buy an interview.

 

[VBboy]

Originally posted by: calpha
Nope.
I'm in the unemployed line too.

And I'm even in RTP, a tech GOD area....alll kinds of companies, and I can't buy an interview.

Are you good-looking? May want to try a different industry

 

[calpha]

Originally posted by: VBboy

Originally posted by: calpha
Nope.
I'm in the unemployed line too.

And I'm even in RTP, a tech GOD area....alll kinds of companies, and I can't buy an interview.

Are you good-looking? May want to try a different industry

I'm a part of the Norht American Nerd and Geek contingent and have been my whole life.
How many good looking Nerds have you met?

I did think about whoring myself out to pay the bills, but my wife nixed that idea. She said she didnt' want me to get my feelings hurt

 

[Descartes]

Originally posted by: VBboy
Well, ok, Debug.Print is not a bad thing to do per se'

But I write large apps (10+ files in the project, a hundred pages long or so), and using Debug.Print is quick and dirty for me. Let's say you need your customer to send you a bug report. By having your debug feature dump it all to the file, you allow the user to send you a detailed report with little effort.

But is smaller apps, sure, it's Debug.Print all the way.

Please don't tell me you are saying that you have only 10 files in a project that results in code > 100 printed pages long?

 

[VBboy]

Originally posted by: Descartes

Originally posted by: VBboy
Well, ok, Debug.Print is not a bad thing to do per se'

But I write large apps (10+ files in the project, a hundred pages long or so), and using Debug.Print is quick and dirty for me. Let's say you need your customer to send you a bug report. By having your debug feature dump it all to the file, you allow the user to send you a detailed report with little effort.

But is smaller apps, sure, it's Debug.Print all the way.

Please don't tell me you are saying that you have only 10 files in a project that results in code > 100 printed pages long?

Ok, let's see. One of my larger home-brewed projects: process manager (TaskSwitcher TM).

Code stats:

Time in development: 2 months part-time.
Number of files: 6 forms, 8 modules, 3 "related" files (ToDo, Revision History, Pr0n.txt <- just kidding)
Printed size: 80 pages or so.

About 20% of my code is comments.