| Subject | Re: [IBO] Large Blob Insertion |
|---|---|
| Author | Geoff Worboys |
| Post date | 2001-04-04T11:47:53Z |
Brian,
The good news is that I have a pretty good idea what is happening.
The bad news is that I dont really know what to do about it.
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 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.)
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 am not sure of the best solution. Looking at the code for
TBlobStream I expect the VCL would have similar problems in this
situation (but I have not tested).
The existing TIB_BlobStream works efficiently for the usual (known
length) objects. I would seem a pity to introduce over allocation
compensations for this particular problem instance.
I am guessing that your best short term solution is to stop using
TwwDBRichEdit and revert to TwwRichEdit (the non data-aware version).
Setup appropriate event handlers to load/save the contents from/to the
data field yourself. In this way you can preallocate your own stream
and take control over how this is written to the blob field.
Geoff Worboys
Telesis Computing
> IB_ReallocMem(nil,0,4095)I have some good news and some bad news :-)
> TIB_BlobStream.Write(???,4095)
> TIBOBlobStream.Write(???,4095)
> TwwCustomRichEdit.WndProc(???)
> TwwDBRichEdit.UpdateData(???)
> Project1
The good news is that I have a pretty good idea what is happening.
The bad news is that I dont really know what to do about it.
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 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.)
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 am not sure of the best solution. Looking at the code for
TBlobStream I expect the VCL would have similar problems in this
situation (but I have not tested).
The existing TIB_BlobStream works efficiently for the usual (known
length) objects. I would seem a pity to introduce over allocation
compensations for this particular problem instance.
I am guessing that your best short term solution is to stop using
TwwDBRichEdit and revert to TwwRichEdit (the non data-aware version).
Setup appropriate event handlers to load/save the contents from/to the
data field yourself. In this way you can preallocate your own stream
and take control over how this is written to the blob field.
Geoff Worboys
Telesis Computing