>Hello Tore, thanks for the reply.
>
>>Not a fix to your problem as such, but a warning. Avoid general fields AT ALL >COST, they have always been a PITA, and are extremely difficult to deal with in >the real life! Store the docomunts as separate files. Store the file name, with >or wothout the path, in the table.
>
>Normally I would agree with you, but in this case I am preparing a numer of RTF strings to output on a .frx-based report. These RTF strings (5 of them) are stored in text fields in SQL-server back-end tables, and I would have liked to output them individually, but they are of variable length and general-field regions do not stretch on a report. So the most efficient solution I have hit-upon (so far) is to combine them into a single RTF-string and output them in a single general report object which stretches to the bottom of the page. (If you could suggest a more efficient way I would be grateful but this is the easiest way I have come-across so far).
>
>Merging the RTF strings into a single string appears to be ok when converted and viewed as an RTF file, but when imported into the general field, it loses nearly everything. Weird!
>
>
>Regards,
>Alan

Can't you simply use normal memo fields in stead of general fields? As I guess you know, general fields are "mapped" to their respective activeX controls, so in order to use general fields you also must make sure that the "mapped" control is installed and registered. That's why I wrote that general fields are a PITA. General fields sounded like a good idea when they were introduced many years ago, but experience has shown that they create more trouble than they fix.