Hello, fpc-developer list.
As Events (i.e callbacks at the time being) are syntactically done as
properties, could it be possible that property attributes on the long
run could help implementing thread Events (i.e. a class fires an
event not as a callback (usually using a the main thread, but
Couldn't you check the ID in your after construction event and throw an
exception if it's not set ?
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Michael Schnell wrote:
programmed like that using a thread it defines) but uses a thread the
program that sets the handler property defines ? Here the programmer
does not need to write code that passes the parameters to the thread:
the RTL does all this dirty stuff, helping less advanced
It is a run-time error but what I am looking for is an compile-time
error. It is not sensible(for me) to raise an exception because of bad
implementation. Thanks for you idea ;)
Amir
Michael Schnell wrote:
Couldn't you check the ID in your after construction event and throw
an exception if
Hi all,
after we had that quite heated discussion in core, I decided to take
matters into my own hand and come up with some useful proposal. But now
I am looking at fpc2.2.0 sources for SysUtils and feel quite desperate.
The thing is that I don't know if those are actual bugs, design
Are you sure this would make things easier? Code in the handler needs
to be thread safe. Starting a thread is very easy, with TThread?
If you use common resources of course you do need to take create to do
it in a thread save way.
But if you want to off-load some kind of work to one or
