Hello all,
I'm looking for a sample program in C to print out lines not to the
standard MS Dos Box but into a different control e.g. text control.
Has C the possibility to do printouts to a control instead of using the
MS Dos Box? And what control can I use for this purpose when I need to
have the most similar look to the MS Dos Box?
OFF TOPIC!!!
Every help is greatly appreciated.
Thanks in advance.
With kind regards,
Tiziana
But since you asked so nicely...
First off, I'm assuming you're talking about using something like
printf() to print to a Windows "control" rather than the actual function
found in the winapi (or equivalent) for printing to the control. To
do the latter, check your Windows API package documentation...
However, to do the former, sure, I do it all the time, but as
usual exactly how you code this depends on what you really
want and what you're starting off with...
Here's the basic trick though: you have to selectively
re-define "printf()" to "print" to the control as if it
were the "console" (what you're calling a "DOS Box", or
equivalently, an "xterm" in Unix). Here's how I do it,
but again, your mileage may vary:
#ifdef __WINGUI__
#include <vcl.h>
#pragma hdrstop
#include <p_output.h>
#define printf gui_printf
#endif
Now this assumes a couple of things. First, I'm using
a particular development package (so "vcl.h" may be
something else for you, or you are using the "winapi" package
available bone-stock free from Microsoft on their website, which
may be the best idea of all, frankly). Second, this
is clearly "dual-use" code; I can conditionally compile
it as either Windows GUI application or as a "console"
(or "xterm") command-line interface application.
So if I compile the thing as a Windows GUI application,
the pre-processor turns all occurences of printf() into
gui_printf(), which is declared in "p_output.h" and defined
in a file called "p_output.c" which is linked into your
program.
gui_printf() is declared with the exact same "signature"
as "printf()", and defined as follows:
int gui_printf(char *format,...) {
unsigned print_length;
p_line_buffer[0]=NUL;
va_list ap;
va_start(ap,format);
vsprintf(p_line_buffer,format,ap);
va_end(ap);
print_length=(int)strlen(p_line_buffer);
print_line_buffer();
return print_length;
}
Note that the trick here is the use of the "vsprintf()"
function to handle all the functionality of "printf()" without
the nasty consequence of actually sending the output to
the "console". Instead, the formatted output is "printed"
to a buffer, and then the buffer is "printed" to the
Windows control by the "print_line_buffer()" function.
Now this is where you have to figure out where you're
coming from and where you "want to go today". What "control"
do you "print" to? Well, it's been a while since I looked
directly at the winapi package, but I think it's called
the "memo" control. In any event, it's the one Microsoft
uses in "Notepad" for displaying and editing relatively
small (36K limit) text-only files (my development package
supplies a "visual component" class called "TMemo" that
I use for this purpose, so unless you use the same package
the calls and configuration of this "object" won't make
too much sense).
But you'll probably want to implement some type of "scrolling"
functionality to allow you to freely and asynchronously "print"
to the control in the same way that "printf()" prints to
the "console". One thing is for sure: if you use the "memo" control,
your program will blow up to smithereens if you exceed the 36K text
limit, so unless you are sure you won't exceed that amount of
text, you'll have to "scroll out" old text from the "memo" control
buffer in order to "scroll in" new text.
This actually can be implemented by creating a "console buffer"
that ties into the calls to the "memo" control (or whatever it's called),
but I think you'll always wind up with (I've wound up with) some
fairly small "flickering" when scrolling large amounts of text because
the control was not designed to scroll asynchronous amounts of
text in the first place, just display a discrete single block of text.
For me, it's OK, but I think to get rid of that artifact
completely, you would have to go back to scratch and
work with rudimentary calls like "WM_PAINT" or whatever
and build your own console "work-alike"...
