Writeln alternative for GUI applications?

[Ikke]

Hi everybody,

Back in the days when I was programming in Pascal, I'd often use writeln to
display debug information - basically just to know what the program was
doing at that moment.

Recently I've started developing in Delphi, but when I tried to add a
writeln statement, I got an error (I/O error 105 IIRC).

Is there a way to output debug information to some sort of console? Perhaps
to the messages list in Turbo Delphi?

Coming from a Java background, I was used to using Log4J for larger
projects. I've already found a Log4Delphi project, but I'd like to steer
clear of that for a while, since my applications are extremely simple at
the moment.

All thoughts or suggestions are highly appreciated!

Ikke

[Marco van de Voort]

On 2007-05-04, Ikke <ik...@hier.be> wrote:
> Back in the days when I was programming in Pascal, I'd often use writeln to
> display debug information - basically just to know what the program was
> doing at that moment.
>
> Recently I've started developing in Delphi, but when I tried to add a
> writeln statement, I got an error (I/O error 105 IIRC).
>
> Is there a way to output debug information to some sort of console? Perhaps
> to the messages list in Turbo Delphi?

Afaik "GUI" Windows programs are simply programs that don't open a console.

So either use window opening calls from a console application (IOW setup for
event driven running), or try to initialise a console from a previously GUI
program.

I'm not 100% sure, but afaik both are possible.

[David Kerber]

In article <Xns9926C9EE69...@195.130.132.70>, ik...@hier.be
says...

VB uses "debug.print" as an equivalent, which prints to the immediate
window when running in the IDE. Maybe Delphi has an equivalent?

--
Remove the ns_ from if replying by e-mail (but keep posts in the
newsgroups if possible).

[Ikke]

David Kerber <ns_dkerber@ns_WarrenRogersAssociates.com> wrote in
news:MPG.20a55b733...@news.conversent.net:

<snip>

> VB uses "debug.print" as an equivalent, which prints to the immediate
> window when running in the IDE. Maybe Delphi has an equivalent?

I hope so - it's that equivalent I'm looking for :)

Ikke

[Ikke]

Marco van de Voort <mar...@stack.nl> wrote in
news:slrnf3n401....@snail.stack.nl:

<snip>

> Afaik "GUI" Windows programs are simply programs that don't open a
> console.

True. But some languages, when you start your Windows Application from a
console, still show the console output in said console.

If you start your application by double-clicking on it's icon, the
console output remains hidden.

> So either use window opening calls from a console application (IOW
> setup for event driven running), or try to initialise a console from a
> previously GUI program.

Via groups.google.com I already found a bit of a workaround: add a memo
field to the form, and log to that. It messes up the GUI, alas...

> I'm not 100% sure, but afaik both are possible.

I'm really only looking for something like 'writeln' - anything that's
more complex than that, should be discarded as a viable solution.

If there is none, the simplest solution could be logging to a file and
simply tailing it's contents. That way, I can still see what the software
is doing in realtime.

Thanks,

Ikke

[Dale....@sas.com]

Finally! A topic on which I can say something useful!

I use the OutputDebugString function to write out debugging info. When running the program under the Delphi IDE, the lines show up in the Events window. For when I'm running it outside of the IDE, I use the DbgView program from sysinternals.com to capture and display them.
--
Dale

[Marco van de Voort]

On 2007-05-04, Ikke <ik...@hier.be> wrote:

>> So either use window opening calls from a console application (IOW
>> setup for event driven running), or try to initialise a console from a
>> previously GUI program.
>
> Via groups.google.com I already found a bit of a workaround: add a memo
> field to the form, and log to that. It messes up the GUI, alas...

That's very dangerous, specially with server apps, since a memo retains all
lines which can cause problems.

> I'm really only looking for something like 'writeln' - anything that's
> more complex than that, should be discarded as a viable solution.

Simply write to a logfile then. writeln(f,'x'); and a global open and close.

> If there is none, the simplest solution could be logging to a file and
> simply tailing it's contents. That way, I can still see what the software
> is doing in realtime.

Yes and no, only if you flush aftere each write.

[Paul E. Schoen]

<Dale....@sas.com> wrote in message
news:fq7n33pj5lui22atd...@4ax.com...

I wish I knew about that function a while ago. I added a separate Debug
form with a Memo, and at critical points in the program I wrote a line of
information which told me what procedure I was entering or exiting, as well
as a time stamp with 0.1 second accuracy. That was helpful in debugging my
serial interface application, which had to send strings or characters to
the serial port, wait for some time, and then read back from the input
buffer. I was able to see where sometimes my timeout loops went for quite a
few iterations, while at other times the expected event happened just about
immediately.

My debug window remains hidden, but I have a menu item to view it. When the
program closes, it is written to an <application>.dbg text file.

Paul

[Ikke]

Marco van de Voort <mar...@stack.nl> wrote in

news:slrnf3na57....@snail.stack.nl:

> On 2007-05-04, Ikke <ik...@hier.be> wrote:
>>> So either use window opening calls from a console application (IOW
>>> setup for event driven running), or try to initialise a console from
>>> a previously GUI program.
>>
>> Via groups.google.com I already found a bit of a workaround: add a
>> memo field to the form, and log to that. It messes up the GUI,
>> alas...
>
> That's very dangerous, specially with server apps, since a memo
> retains all lines which can cause problems.

Point taken. It's only for debug purposes, of course - production code
would no longer have this stuff inside.

>> I'm really only looking for something like 'writeln' - anything
>> that's more complex than that, should be discarded as a viable
>> solution.
>
> Simply write to a logfile then. writeln(f,'x'); and a global open and
> close.

Good suggestion - thanks!

>> If there is none, the simplest solution could be logging to a file
>> and simply tailing it's contents. That way, I can still see what the
>> software is doing in realtime.
>
> Yes and no, only if you flush aftere each write.

Thanks,

Ikke

[Ikke]

Dale....@sas.com wrote in
news:fq7n33pj5lui22atd...@4ax.com:

<snip>

> Finally! A topic on which I can say something useful!
>
> I use the OutputDebugString function to write out debugging info. When
> running the program under the Delphi IDE, the lines show up in the
> Events window. For when I'm running it outside of the IDE, I use the
> DbgView program from sysinternals.com to capture and display them.

Dale, I sure am glad you said something, because that was exactly what I
was looking for!

Thanks!

Ikke

[Rob Kennedy]

You can write to the console with Writeln, but only once your program
has a console. Call AllocConsole for that.

You can write to Delphi's debug log with OutputDebugString.

You can write to a log file with whatever library tool you wish.

You can display a message with ShowMessage.

--
Rob

[Jamie]

If you really want a console window, you still can use the Writeln,
Write etc,like you did before how ever, you i think you'll find it not
as it was in DOS and also, you must remember to use the FreeConsole
before you exit you program other wise, unexpected results happen..

AllocConsole will give you a console window, it will have your title
on it etc...
You can use the Writeln and other things related to console windows
that are default as pascal IO..

BUt use FreeConsole somewhere before your app terminates.

--
"I'm never wrong, once i thought i was, but was mistaken"
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

[Rob Kennedy]

Jamie wrote:
> If you really want a console window, you still can use the Writeln,
> Write etc,like you did before how ever, you i think you'll find it not
> as it was in DOS and also, you must remember to use the FreeConsole
> before you exit you program other wise, unexpected results happen..

Unexpected results? Like what?

--
Rob

[Jamie]

Rob Kennedy wrote:

Like IDE crashes when test running your app from
the IDE and not properly freeing the console you
made when your app exited.

[Nicholas Sherlock]

Jamie wrote:
> Rob Kennedy wrote:
>
>> Jamie wrote:
>>
>>> If you really want a console window, you still can use the Writeln,
>>> Write etc,like you did before how ever, you i think you'll find it not
>>> as it was in DOS and also, you must remember to use the FreeConsole
>>> before you exit you program other wise, unexpected results happen..
>>
>>
>> Unexpected results? Like what?
>>
> Like IDE crashes when test running your app from
> the IDE and not properly freeing the console you
> made when your app exited.

That's an IDE bug. Get a reproducible test case and post it to QC.

Cheers,
Nicholas Sherlock

[John Dough]

On Sat, 05 May 2007 13:28:38 +1200, Nicholas Sherlock
<N.she...@gmail.com> wrote:

>That's an IDE bug. Get a reproducible test case and post it to QC.

Why port it to QC?
It's not like it's ever going to get fixed.
There are countless bugs still present in Delphi 2007 that were
initially reported in Delphi 5 or 6.

[Rob Kennedy]

John Dough wrote:
> On Sat, 05 May 2007 13:28:38 +1200, Nicholas Sherlock
> <N.she...@gmail.com> wrote:
>
>> That's an IDE bug. Get a reproducible test case and post it to QC.
>
> Why port it to QC?

Why not?

> It's not like it's ever going to get fixed.
> There are countless bugs still present in Delphi 2007 that were
> initially reported in Delphi 5 or 6.

But there are countable bugs there *are* fixed. So how can you say that
the bug will never get fixed?

QC is for more than reporting bugs to CodeGear. It's also for
documenting bugs. Post a bug to QC, and now people can find that bug to
confirm that whatever they're observing is the same as whatever you
already observed. Collective memory. Maybe you've found a workaround.
Post it to QC so others can benefit from your solution.

--
Rob

[Joe Smith]

You could assign the string to an edit box and call processmessages or
what I frequently do is create a text file and a routine "snap" which
does a writeln to the text tile and calls "flush" so that if my
program crashes I don't lose the last few lines of output in the
buffer.

Neither is pretty but both work.

[Jamie]

Well, Using a "AllocConsole" works just fine for console debugging.
I don' do it all the time but when starting a large project i'll
start a Console window in the main start up just to use for debugging
and use a compiler define to compile the code in.
When the project is ready for a release test.. I simply change one
global const and build all to remove the console code...