On Tue, 1 Sep 2020 20:31:57 +0200 (CEST), Michael Van Canneyt via
fpc-pascal
wrote:
>Yes, but you can only override a virtual constructor. The TThread
>constructor is not virtual.
I am doing the setup in a different way so I don't have to use Create.
My new FpSerialPort works fine now with the
On Tue, 1 Sep 2020, Bo Berglund via fpc-pascal wrote:
On Tue, 1 Sep 2020 14:21:44 +0200 (CEST), Michael Van Canneyt via
fpc-pascal
wrote:
You must still set the default value in the constructor.
Note that the thread itself has no idea what is the baudrate in use so
it cannot calculate
On Tue, 1 Sep 2020 14:21:44 +0200 (CEST), Michael Van Canneyt via
fpc-pascal
wrote:
>You must still set the default value in the constructor.
>
>>
>> Note that the thread itself has no idea what is the baudrate in use so
>> it cannot calculate the proper value at the start of Execute...
>> And
On Tue, 1 Sep 2020, Bo Berglund via fpc-pascal wrote:
On Tue, 01 Sep 2020 10:22:08 +0200, Bo Berglund via fpc-pascal
wrote:
Maybe I could tie the timeout to the actual baud used? Slower speeds
use longer timeout etc? Timeout could be set to the time it takes to
transfer the number of bytes
Ooops, wrong url, I just learn know that property could belong to a
global block... ;-)
For classes:
https://www.freepascal.org/docs-html/ref/refsu33.html#x86-1080006.7.1
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
Le 01/09/2020 à 10:49, Bo Berglund via fpc-pascal a écrit :
Is there no way to declare a property to have a default non-zero
value?
I'm not sure but I think the syntax is for this something like
property ReadPacketSize: integer read FPacketSize write FPacketSize default 10;
Reference:
On Tue, 01 Sep 2020 10:22:08 +0200, Bo Berglund via fpc-pascal
wrote:
>Maybe I could tie the timeout to the actual baud used? Slower speeds
>use longer timeout etc? Timeout could be set to the time it takes to
>transfer the number of bytes to read?
>
>And both arguments could be made properties
On Mon, 31 Aug 2020 12:01:33 +0200, Bo Berglund via fpc-pascal
wrote:
>Thanks, I was worried about reading more data than specified.
>Now I can let the loop in Execute read say 10 bytes or so with timeout
>ane process these, then loop back after firing off the event.
Just a follow-up for
On Mon, 31 Aug 2020 11:15:10 +0200 (CEST), Michael Van Canneyt via
fpc-pascal
wrote:
>
>
>On Mon, 31 Aug 2020, Bo Berglund via fpc-pascal wrote:
>
>> On Fri, 21 Aug 2020 21:03:31 +0200, Bo Berglund via fpc-pascal
>> wrote:
>>
>> But when doing this I have run into a problem, how can I check
On Mon, 31 Aug 2020, Bo Berglund via fpc-pascal wrote:
On Fri, 21 Aug 2020 21:03:31 +0200, Bo Berglund via fpc-pascal
wrote:
Instead I need to add a thread for reading data so I can have an event
driven reception of data. It would read available data and fire off a
NotifyEvent to handle
On 31 Aug 2020 at 9:38, Bo Berglund via fpc-pascal wrote:
> On Fri, 21 Aug 2020 21:03:31 +0200, Bo Berglund via fpc-pascal
> wrote:
>
> >Instead I need to add a thread for reading data so I can have an event
> >driven reception of data. It would read available data and fire off a
>
On Fri, 21 Aug 2020 21:03:31 +0200, Bo Berglund via fpc-pascal
wrote:
>Instead I need to add a thread for reading data so I can have an event
>driven reception of data. It would read available data and fire off a
>NotifyEvent to handle the incoming data in the main application.
I have now
On Fri, 21 Aug 2020 20:06:04 +0200, Christo Crause via fpc-pascal
wrote:
>In my limited experience the FPC serial unit is a bit more low level than
>the components such as synaser etc. There is a bit more of a learning
>curve and one needs to decide whether to go blocking or not and how to
On Fri, Aug 21, 2020 at 12:05 PM Bo Berglund via fpc-pascal <
fpc-pascal@lists.freepascal.org> wrote:
> So hence my question:
> Is there something bad about serial (built-in to fpc) that makes it
> unsuitable for use?
>
In my limited experience the FPC serial unit is a bit more low level than
On Fri, 21 Aug 2020, Bo Berglund via fpc-pascal wrote:
What is the advantage of using synaser over serial in a simple non-gui
program running in the console in Linux?
I have been struggling making LazSerial work in a console app and been
adviced to instead use synaser (which is what
What is the advantage of using synaser over serial in a simple non-gui
program running in the console in Linux?
I have been struggling making LazSerial work in a console app and been
adviced to instead use synaser (which is what lazserial is built on).
A few months back it seemingly started to
16 matches
Mail list logo
