Subject | Re: [IBO] Large Blob Insertion |
---|---|
Author | Nello Sestini |
Post date | 2001-04-04T13:16Z |
Brian/Geoff
control passing it a pointer to the callback function StreamSave
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.
-ns
> The Windows API RichEdit control supports streaming via a callbackThe VCL wrapper sends an EM_STREAMOUT message to the underlying windows
> 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).
control passing it a pointer to the callback function StreamSave
> The problem is that the size of the final data is not known untilI can't find anything either. Not even a place where MS documents
> 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.)
>
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 theI suppose that's what this amounts to.
> 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.
-ns