> The phrase "controls designed for normal printable text" is,
> I'll bet, nowhere to be found in IBO's self description.
> (I'll buy you lunch one day if I'm wrong).

You'd be looking in the wrong place. You need to read the Windows API
reference. Most of Windows text display facilities are designed to
operate with printable text - that is text that is valid within a
given font and character set. Characters not matched are generally
given some strange sort of block representation or as a blank -
neither of which is very useful.

> My thinking is IBO should never trim users data and I recall
> you appreciate IBO's trimming because you deal a lot in
> "printable text data".

And when the data is binary (or dubious) then I translate to hex or
b64 so that accurate and consistent manipulation and display is
possible.

There are many other potential problems with trying to manage binary
data as text (which is what you are doing when trying to display via
typical windows text functions). An obvious problem are NULLs - since
most of the Windows API expects text to be null terminated. But
additional problems can be had with other special characters - such as
CR or LF - depending on the control type and API features used.

> By setting the Query properties for the Column in question
> to Trimming=NONE my problem is solved.

That is good news - and needs to be there if you intend to store the
information as binary data in the database. I am presuming that you
are using either a Blob or a var/char with OCTAL character set in the
database (dont try to store binary data in a normal var/char field).

> Thanks again Geoff. I am still getting used to
> these idiosyncrasies in IBO.

Everything takes time and IBO is big! :-)

Geoff Worboys
Telesis Computing