STRPRINT or EMAIL formatting oddly

[Controls Guy]

I have the following in a FOR loop, building a table to email.

It works in general, but some lines seem to have extraneous carriage returns for some bizarre reason, as shown in the second screenshot, even though all the  lines are built by the same STRPRINT box.   

Any ideas?

[Controls Guy]

It would also be nice if one of the Fmtxxx() functions had a mode for implied decimal.  That would have been useful here for example.

[plcnut]

It would 'appear' to be a text wrap issue. Have you tried to view the data in a dataview that is set to view as Hex? This way you could confirm their is an actual CRLF.

[Controls Guy]

Well, it would seem to be, but the only place I'm putting one in, is at the very end.  There might be one embedded in the string value, but the extraneous break isn't in the part of the line that comes from the string value.  ??

[ADC Product Engineer]

IIRC, it has something to do with not having a proper termination in the string (<CR><LF>).  The buffer fills and then at 72 characters (I think) it forces the <CR> <LF>.

This is from memory, so Franji1 or BobO may come in and correct me as to the particulars on it.

[Controls Guy]

Well then, I'm really confused, because there WAS an 0D0A at the end of the previous line (hence the carriage return) way less than 72 characters previous, plus all the other lines make it farther than the broken ones do, with no problem.  Guess I have to look at the actual hex contents of Report0.

[ADC Product Engineer]

As a follow up, I was mostly correct in my previous post.  (It only took me a half hour of email digging to find the relevant information.)

If you are sending email, SMTP servers require a 0D0A every 80 characters or one will be forced into the string.

[Controls Guy]

OK, I'm getting confuseder by the minute.  

ADC PE, you seem to be almost right.  The prebuilt string does have CRLF's where expected, about every 39 characters or so, according to a Data View in DMD.  I checked and the first extra CR in the email is indeed exactly 80 characters from the beginning of the message (though the second one is 180 chars after??), so you'd think maybe the EMAIL box is failing to send them and SMTP server is inserting an extra......BUT, it's only the 80th character IF YOU COUNT the <CR>'s and <LF>'s that are supposed to be there, plus the previous lines break where intended!  So I know the server's getting the intended 0D0A's, so that hypothesis doesn't work.

So then I thought maybe it's a bug in that specific SMTP server (inbox.com), so I tried another email server (vfemail.net), and the received email had extra breaks in exactly the same positions.  Can't be a bug in TWO servers, can it?

So then I thought maybe it's in my email client (Thunderbird), and it's just rendering that way on screen, but I looked at the message on the server using Cox's webmail client, and the extraneous breaks are already in by that point.

At this point, don't know what to do, other than put the mirroring switch on and verify what Do-More's sending, byte by byte.

Thoughts?

[Controls Guy]

BobO figured this out for me.  My MHR strings had ASCII NULLs (0x00's) in them, which broke the character counter, so if I replace the NULLs with spaces, all should be good.

Thanks, BobO!   

[ADC Product Engineer]

Do-more is the culprit.  It is strictly adhering to the SMTP spec which states that every 80 characters, there must be a CR/LF.

Good to know about the null's.  I hadn't thought of that, but it makes sense.

[Controls Guy]

Well, it really had nothing to do with CRLF frequency, or only indirectly.  There were plenty of CRLF's present that no additional ones were needed.  The central issue is that NULL's break the character counting, and that can be worked around.

[BobO]

The line break code uses standard C string handling to look for CR/LF. It hits a NULL and concludes that there is none, then grabs 78 characters, looks for white space at the end, adds CR/LF, and spits out the line...which now has 2 line breaks and a bunch of illegal NULLs.

Do-more could be a bit more graceful about it, but the NULLs are not permitted in the email. I will look at adding some warnings...and maybe converting illegal characters to something else.

[Controls Guy]

For me at least, either or both of those (run time warning or replacement) would be fine.  If you do real-time replacement, you probably want to announce it somehow, or else someday, somehow, the replacement will bite someone in some mystifying way that's hard to diagnose.

Thank you again for figuring out what was going on here.  It really had me baffled. 

[BobO]

For me at least, either or both of those (run time warning or replacement) would be fine.  If you do real-time replacement, you probably want to announce it somehow, or else someday, somehow, the replacement will bite someone in some mystifying way that's hard to diagnose.

Thank you again for figuring out what was going on here.  It really had me baffled. 

If we did replace, we would certainly warn also. I am inclined to just warn.

[Controls Guy]

I think just warning would be fine.