Subject Re: [IBO] Large Blob Insertion
Author Nello Sestini

> The Windows API RichEdit control supports streaming via a callback
> mechanism. Since both the VCL and the IP RichEdit controls use this
> WinAPI richedit, they also use this callback mechanism for streaming.
> So when UpdateData is called above, it sends a message to the control
> which then issues a series of callbacks to a defined function (see
> StreamSave in the comctrls.pas VCL unit).

The VCL wrapper sends an EM_STREAMOUT message to the underlying windows
control passing it a pointer to the callback function StreamSave

> The problem is that the size of the final data is not known until
> after it has been converted. So the API control simply converts a
> small amount at a time and sends that small amount with each
> callback - apparently 4095 bytes.
> I cannot find anyway of telling the control to change its buffer size.
> (That does not mean it doesnt exist, only that I cant find it.)

I can't find anything either. Not even a place where MS documents
the 4095 or whatever it is.

But this isn't really so bad.

The problem isn't that these chunks are small - the problem is that
the small chunk size gets used as the reallocate delta by the stream.

And I think the VCL does provide a convenient hook for getting in between
the windows control interface and the stream. Via a TConversion.

The callback function passes the data it gets from the control
to the stream like this:

if StreamInfo^.Converter <> nil then
pcb := StreamInfo^.Converter.ConvertWriteStream(StreamInfo^.Stream,
PChar(pbBuff), cb);

and you CAN provide your own converter object - it's set via the
DefaultConverter property. A TConverter is just a pair of functions
to convert from stream to buffer and from buffer to stream.

In this custom converter you could allocate a LARGER buffer and
"buffer the buffers" passing larger chunks on to the stream.

> IMO the ideal solution would have been for the VCL to assemble the
> result itself (since it is rather a special situation) and then pass
> of the total result on the destination stream. But they do not do
> that - I guess it does not matter if it was just being streamed to
> file.

I suppose that's what this amounts to.