On 09/08/2017 04:34 AM, Bo Berglund wrote:
Next I unchecked the checkbox before doing the long transfer, and
lo-and-behold(!) now there are no losses anymore!
So the action of writing text to the listbox in the LogHex function
was actually causing the application to lose incoming serial data!
On Fri, 08 Sep 2017 14:54:33 +0200, Bo Berglund
wrote:
>But how?
Never mind this...
I found the wiki article:
http://wiki.freepascal.org/Multithreaded_Application_Tutorial
--
Bo Berglund
Developer in Sweden
___
fpc-pascal maillist - fpc-pascal@list
El 08/09/2017 a las 10:34, Bo Berglund escribió:
for i := 0 to l-1 do
begin
sLine := sLine + IntToHex(Buf[i],2);
end;
lbxLog.Items.Add(sTime + ' ' + sLine);
lbxLog.ItemIndex := lbxLog.Items.Count-1;
Hello,
This is a big "NO, NO!" for quite large buffers, that code can take
On Fri, 8 Sep 2017 13:06:16 +0100, el es
wrote:
>
>I would decouple the log display from the serial handling routines -
>by delegating the serial task to a thread, only display of log is handled in
>the main thread (this is true whether your application is cli-only or gui -
>have the tasks that
On 08/09/17 09:34, Bo Berglund wrote:
> 6) Then I rebuilt my application, but I have no idea if this actually
> caused any buffer change. I know too little about the inner workings
> of the Lazarus/FPC system...
>
> So it might still use the tiny 2K buffer???
>
>
I would decouple the log displ
On Thu, 07 Sep 2017 13:48:27 +0200, Bo Berglund
wrote:
>I think I will have to create a bogus image file where I have a
>regular pattern of bytes so I can see when the hickups occur in the
>log. In a normal memory file most of the data is zero, so there are
>long stretches of zero bytes sent. The
