Hello Ara (as in the constellation? )



 AG> I am new in C programming



Psychiatric help is my advice 



 AG> This program work with space... eg 123 123 123 123 ENTER.

 AG> However when I press TAB key system transmit the picture of tab

 AG> key on screen between the numbers and not space.

 AG> When I check the file which program make "DDAY.DAT" there are

 AG> spaces between number.



Since I tend to reply real late, you've probably already worked

out, or been told, that you're stuck in the



 AG> while (ch != '\r' && ch != '\n')

 AG> {

 AG>  cprintf("%c", ch);

 AG>  fputc(ch, stream);

 AG>  ch = getch();

 AG> }



loop, which is entered after you hit the first key. You stay there

until return is hit. This loop does no checking for anything except

\r and \n, so tabs (and anything else, try a function key or two,

very pretty) get echoed.



But since I was here, I thought I'd mention that with BC++3.1 you

have several debugging programs that will help you find problems

like this easily. There is one built into the IDE, check the docs.

There are also several stand-alone debuggers, which run faster than

the IDE one, and have more nifty features, but you normally need to

leave the IDE to use them, so they are a bit slower to get into.



I used a debugger to find your problem, being too lazy/tired to

read the C code. I just had to put one breakpoint on the switch

statement below:



 AG> if( kbhit() ){

 AG>      ch = getch();

 AG> switch( ch ) {

 AG>         case 27:             //Esc

 AG>             Quit();



When I ran the program, the debugger stopped the program at the

switch statement as soon as I hit the first key. I told the

debugger to continue running the program, and lo and behold I could

type in lots of keys without the debugger interrupting. This meant

that the "switch" statement was not being executed again, so the

program had to be in a loop further down. The "while" loop stood

out as a suspect.



Extra unsolicited suggestions:



1. (I have BC++v3.0 and 4.0; I don't know what refinements went into

v3.1, so I'm talking about the 3.0 programs here.) If you have a

386sx or better, look for the debugger called TD386. The 3.0

version of TD386 I have is a bit irritating, because (a) it

requires a special tsr to be loaded from config.sys, and (b) it

won't work under 386 memory managers like Qemm386, so I have to

keep a different pair of config.sys/autoexec.bat files to use

it. But

when your programs get nasty and start crashing your pc, TD386 can

use the 386 protected mode to resist such crashes, where the normal

TD and the IDE debugger can't.



2. The line



 AG> #include    



isn't needed, at least in the program you gave us, because your

program is always in text mode. Graphics.h is used when the screen

is switched to one of its graphics modes.



3. You've used // comments instead of /* comments */. No C++

compiler will ever complain about this, but the program you wrote

is pure C, with no C++ features in it at all. It's a good idea to

get the differences between C and C++ *very* clear in your mind, and

one way of reinforcing the difference is to use /* C style comments

*/ when your programs contain only C code. It sounds like

"political correctness", but from personal experience, it does

help. And it will stop C programmers from beating you on the head

when you show them your C programs here .



BTW, your commenting was fairly good, but there was zero commenting

inside the main loop. If you'd written comments at each of the

looping or iffing statements and their exit points, you may have

seen your problem sooner.



4. The digital clock was cute... but it didn't update every second.

Try to get your program to do things outside the keyboard-wait

loop, instead of sitting waiting for a key hit. That way, updating

the clock will be easy.



Cheers



--- PPoint 1.88