🚀 go-pugleaf

Nick,

Your suggestion for the queue is fine for not holding up the thread. I 
had already considered this but then you would need something like a 
timer checking the queue for events. I need to know about events quickly 
and having a timer checking every millisecond or so doesn't seem to be 
the most elegant way of doing it.

This is why I would like an example of using PostMessage() within a 
class, if that is indeed a way of doing it. i.e.

Event
   |
PostMessage()

(main thread in message loop)
   |
call "Event Dispatcher"
   |
call users event handler.

Regards,
Peter.


Nick B. Cassos wrote:
> On Tue, 27 May 2003 15:06:17 +1000, Peter Stefanos
> <peterATpennywiseDOTcomDOTau> wrote:
> 
> 
>>...
>>I have read a few postings about using PostMessage() (no pun intended) 
>>but I do not know how to implement it without putting the message 
>>handler method and message map in the users form class manually.
>>Any ideas? Is this the best way to do this? Is there a simpler way?
>>...
> 
> 
> You can implement your own queue. A simple TStringList may be enough,
> using the Objects property to hold event types, for example, and the
> Strings property to hold information. For less simple structures you
> could use a TList or better a TThreadList.
> 
> Protect your "queue" with a TCriticalSection (if it is not the
> TThreadList) and offer the user some functions to handle it (e.g.
> PopEvent())
> 
> No need to use PostMessage or Synchronize(), and your thread can keep
> working. You may also offer a maximum number of Events that the queue
> may hold, before your thread goes for sleep, etc.
>