It's one I tend to use a lot as it's a nice platform independent way
scheduling processing in the next cycle round the message loop. The
problem is not whether or not the parameter should be PtrInt or PtrUint,
it is currently PtrInt and changing it means a lot of work for any
application that uses it.
If this were the only instance then maybe the work could be justified -
but PtrInt is used in about a dozen other places in the Forms module
alone and throughout the LCL and FCL. For example:
TDataLink.DataEvent(Event: TDataEvent; Info: Ptrint) in the DB Module.
I can understand the argument that says it was a bad idea in the first
place - but all the work and instability to get rid of it.... "Let
sleeping PtrInt's lie" to paraphrase an old saying.
On 18/03/15 15:29, Graeme Geldenhuys wrote:
On 2015-03-18 15:23, Tony Whyman wrote:
PtrInt is used in that very useful method TApplication.QueueAsync
Call.
Though I never used the QueueAsync() call myself, but looking at the
declaration, shouldn't that data type be PtrUInt anyway? As far as I
understand Data points to data in memory, which will always be an
positive (unsigned) value, not so? Or does Mattias's example apply here
too.
Regards,
- Graeme -
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
