>Ok, tonight I will gin up a simple GUI with a RICHEDIT2 text window
with a limit of say 1K and see what happens when I reach 1K then
try to add more to it. Either it just wont accept more text or
will bonk with an error sound or crash with an "Out of Memory"
error notice. Im predicting one of the first two.

Ah-ha! Now you are a test pilot! A top gun!
>
>The real problem: a few users who run my IM program
(which incidentally defines no limit to the RICHEDIT2 text
size) are reporting the "Out of Memory" error box (with a
subsequent crash) after running the program 24/7 for days and
allowing the text in the IM window to simply continue growing. I
am presuming the out of memory error occurs when they finally
exhaust physical memory? Fortunately it does not effect the
operating system.

This is exactly the situation my suggestion would avoid. In
some routine run periodically (in an loop or event routine),
just check the .Length of the RICHEDIT2 and if too big, just
erase or save to file via append (for archiving) the "older"
text. Then this problem (insufficient ram) will never occur.

>Currently Im advising my users to save the IM content (if they
>wish a copy of it) and clear the IM screen every few days.
>When they do this, the problem seems to go away.

Well, you can automate that as above. Use .SelText to get the
first half of the buffer and then open your archive file and
append it, then close the file (not to leave archive files open
-- think, what if power failure?). I suppose you might have a
configurable option: Save text to archive file (else erase
older text to keep RICHEDIT2 content size at reasonable level).

In no case should the option of crash and/or "insufficient
memory" error be allowed to occur ... ever. Users will just
think, "Oh, this is sloppy and not robust", they will not think,
"Oh, I was advised this could happen".

ROBUST Software: 1) we begin with HB -- very robust. 2) every
conceivable error condition is checked for and handled by your
program code. The latter point is especially critical in
real-time apps, and even more so, for network apps, such as
yours. One never can assume the remote host is doing "what it
is supposed or expected to do".

Therefore, most app development follows the two steps above:
first, roughly, just get it to work and run. Second, add
error-checking for each tiny step of the processing and code to
handle errors when found.

Cheers, Jim