-> the problem i put the code bellow in a sub and for somereason it
-> cannot write the ansi stuff to a file while in a sub. I could take
-> the stuff away and it would work. So what is a beter way to write the
-> file in a beter way then below? barbwall$ = "barbwall.txt"
-> OPEN barbwall$ FOR APPEND AS #1
-> PRINT #1, "[0m[1m  [34mBarber:[0m"
-> PRINT #1, "[1m  Hey everyone, the barbershop is now open![0m"
-> PRINT #1, "[1m  [34mold Woman:[0m"
-> PRINT #1, "[1m  Great!  Long as you do not turn my head into a
-> mop![0m" PRINT #1, "[1m  [34mFat Man:[0m"
-> PRINT #1, "[1m  Haha... You too?[0m"
-> PRINT #1, "[1m  [34mOld Woman:[0m"
-> PRINT #1, "[1m  Yes my boy.[0m"
-> PRINT #1, "[1m  [34mBarber:[0m"
-> PRINT #1, "[1m  I have my good day and my bad days![0m"
etc., etc...
Well, various people have pointed out that you can't APPEND to a file
unless it already exists. But I doubt that that is your problem.
Another possible glitch may come from the fact that you have commas and
colons in some of the strings you are putting on disk. If the file is
*read* by using INPUT #1 commands, these characters will be seen as
string delimiters, which will probably cause whatever is after the first
delimiter in each line to be lost. So, for example, the ":[0m" that
terminates each line wouldn't be read properly. This may well be causing
your problem. The fix is to put quotation marks (CHR$(34)) around the
strings, e.g.:
PRINT #1, CHR$(34); "[1m  Yes, my boy.[0m"; CHR$(34)
Of course, you could say, for example, Q$ = CHR$(34) somewhere at the
start of your program, then just use Q$ on each line.
The WRITE # command, which various people have suggested you use, is
supposed to put quotation marks around the strings automatically. I
don't see why it shouldn't work. It's worth a try!
Since you are writing the same ANSI stuff over and over again, you could
define characters to mean it, and use them in your program instead to
make it a bit shorter. But this wouldn't be related to your present
problem.
Just possibly, your ANSI codes may include characters that interact
horribly with the DOS (like the CHR$(26)es that we discussed in another
thread here recently). If this is so, you'll have to replace the codes
with something else, and put something into the program the *reads* the
files to interpret the modified codes properly.
Good luck!
                            dow
--- PCBoard (R) v15.3 (OS/2) 5
---------------