IdTCPServer - WriteLn method - Embedded #13

[BigBrotherCoder]

Hello all -
This is my first post here so I apologize if this has been covered... I have a program that uses an Indy TCP Server to receive a message and then must send a response that has an embedded carriage return. In short, the response must look like:
#11<stuff>#13<more_stuff>#13<more_stuff>#13#28

I originally wrote the program using Indy 9 components but found quite a few issues with I9 so tore the code apart and will use I10 now... Ironically, a simple writeln(big_string) worked perfectly with I9 but with I10 writeLn seems to interpret the first #13 as the EOL and sends nothing after that. So - how can I send what I need to send *with* the embedded control characters?

Thanks in advance -

 

[lespaul]

Just to be sure, you're actually using code more like this, right?

big_string := Chr(11) + 'Stuff ' + Chr(13) + 'More_stuff' + Chr(13);

Leslie

In an open world there's no need for windows and gates

http://www.ubuntu.com

 

[BigBrotherCoder]

No, I was using 'stuff' + #13 + 'stuff' + #13 + #28. Is this not the equivalent?

 

[roo0047]

char(13) is equivalent to #13
chr(13) is not valid

Roo
Delphi Rules!

 

[BigBrotherCoder]

that's what I thought... The question, then, remains -
How do I send a string with embedded formatting characters down the socket? WriteLn seems to not work with special characters - I can only assume I need to use something else...

 

[Griffyn]

It's not that WriteLn doesn't send special characters, it's the ReadLn you're using on the other side that's interpreting the characters you're sending. #13 is the signal to ReadLn to stop reading.

So, use Write and Read perhaps.

 

[BigBrotherCoder]

The system on the other end is not "my" system... As such I have no control over how it will interpret what I send... I *do* know that it will stop "reading" at the #28. The problem is that I actually tried using the .socket.write() method and had near identical results - nothing after the first #13 was sent - as verified at the other end... Or - am I doing something wrong *shrug*

 

[roo0047]

Have you tried substituting the CR [#13] with LF [#10]. Just a shot in the dark, but something to try...
I remember having this problem once, but too many beers ago.

Roo
Delphi Rules!

 

[BigBrotherCoder]

Thanks all for the answers... Turns out that Griff was right - the writeLn method was fine with the embedded #13's... I was morphing from one object type too early and losing the subsequent parts in the morph before I was sending it... In plain English - there was only one line left to send - so that's all that was being sent. Moved the morph (typecast) down below some send logic - and boom. All is well. Darned OO

Thanks again.

 

[lespaul]

I use Chr all the time...from the Delphi6 help

[tt]Unit
System

Category
character manipulation routines

function Chr(X: Byte): Char;

Description
Chr returns the character with the ordinal value (ASCII value) of the byte-type expression, X.[/tt]

Chr(10) = new line
Chr(11) = vertical tab
Chr(13) = carriage return

Leslie

 

[roo0047]

Leslie - Son of a gun, I stand corrected. Tested in D7E and it worked, however when I searched ..\Delphi7\Source\Rtl\Sys\System.pas, it's not there!?! In fact, not in any of the RTL. Hidden perhaps? They must have added it at some point for the benefit of Basic converts.

I think I'll stick with char (one less function call), besides, I'm old school.

Roo
Delphi Rules!

 

[lespaul]

and the only thing I could find on char wasn't as easy to understand as chr!!

[tt]char
Remarks

The keyword char identifies a data item that has 8 bits. To the MIDL compiler, a char is unsigned by default and is synonymous with unsigned char.
In this version of Microsoft RPC, the character translation tables that convert between ASCII and EBCDIC are built into the run-time libraries and cannot be changed by the user.
The char type is one of the base types of the interface definition language (IDL). The char type can appear as a type specifier in const declarations, typedef declarations, general declarations, and function declarators (as a function-return-type specifier and a parameter-type specifier). For the context in which type specifiers appear, see IDL.

DCE IDL compilers do not accept the keyword signed applied to char types. Therefore, this feature is not available when you use the MIDL compiler /osf switch.[/tt]

Les

 

[roo0047]

If any one person knew all there was to know about Delphi, their head would explode.