What now???

[GEOSoft]

The original string that I used for the actual text was along the lines of

"Line 1" &@LF &"Next Line" &@LF &"Ad Infinitum"

It seemed to work fine in anything that I tried it in until someone mentioned a problem with it in Windows Notepad (which I don't use). Sure enough there was no LF being sent instead thay were replaced by solid block characters and it was just one continuous string. I replaced all of the @LF with chr(10) and that did not help. I tried chr(13) and had the same result.

Since the ClipPut string is the same as the string used for a large message box I will probably use StringReplace to replace the @LF when it is being placed on the clipboard but what should the replacement string be?

[GEOSoft]

I could have sworn I tried that one too, but I guess not because it works. Thanks Larry. Any idea why it only affected Windows Notepad and nothing else?

[CyberSlug]

I could have sworn I tried that one too, but I guess not because it works.  Thanks Larry.  Any idea why it only affected Windows Notepad and nothing else?

Windows notepad expects both @CR (carriage return) and @LF (line feed) to signal line breaks, since this is the DOS/Windows standard*.

Try to read a UNIX text file (@LF-only standard) or a Macintosh text file (@CR-only standard) with Notepad, and you'll you get text all run together. Almost every other program in existance is smart enough to compensate for the lack of @CR (or @LF) in order to display a file correctly.

*If you've ever used a typewriter, you will understand why Windows uses this two-character standard--even it if does slightly increase file size.