Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/19/2014 12:53 AM, Hans-Peter Diettrich wrote: This queue may be unusable for LCL messages (dunno). It _is_ used for the said purpose, simply because the TThread class is provided by the fpc RTL (not the LCL) and here it can't do other but feed the Queue in the RTL. And this obviously works just fine (at least with Windows and Linux GTK2, I did not decently other GUI enabled Widget Types). - Queue in the Linux GUI based LCL that is fed by events (such as Key or Mouse) generated by the WidgetSet it _attaches_ to (this defines is the attach word that I mentioned) - Queue in the Windows OS the LCL in a Windows based Widget type attaches to (instead of implementing it's own event queue) IMO these queues are equivalent, only the implementor (Windows/LCL) is different. Regarding the normal GUI events you are right. But in Windows this queue can be used for other stuff, too, such as sending messages directly to Windows control elements and doing inter-Process (instead internal thread-to-Mainthread) signaling. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/18/2014 05:52 PM, Joao Morais wrote: I missed the async part, sorry. What about reuse App.QueueAsyncCall with interface? Combining the Interface idea with asynchronous signaling in fact is a nice idea. The real issue is that in many cases you need to queue not only the call but the parameters for the call as well. Here we have: - TThread.Queue only calls the call (but of course this is the procedure address and the self of the instance you use in the argument when calling TThread.Queue - Application.QeueAsyncCall additionally takes a pointer as a parameter that is queued and when scheduled given to the signaled procedure called in the main thread But obviously it can be necessary to queue more information than just a pointer. I did a testing program using TThread.Queue. I defined a TData class that contains the data and a procedure with no parameter. When placing the event, in the worker Thread do: - create an instance of the TData class, just storing the reference in a local variable Data: TData; Data := TData.Create; (Data funnily is long forgotten when the call in fact is scheduled in the main thread) - Fill Data with the data to be worked on in the main thread - do Queue(Data.QueuedCall); Now some time later the call is scheduled in the main thread and QueuedCall starts running. - You can correctly access all data in this instance of the TData class. Any other work in the WorkerThread would have created a new independent instance of same - After doing what needs to be done you just do free; as the last line of the QueuedCall procedure. Here the current instance it works on is freed. This does not (seem to) be a problem, as after the free you return to completely unrelated stuff. I am not experienced with Interfaces, but I do know that interfaces can create and free class instances automatically under the hood, and hence it might be better programming style to use same instead o manually do a Create and Free; in user code. If it would be possible to do such an interface driven thingy in a library in a way that the actual structure of the data can be defined in user code, this would be a great addition (IMHO better for the RTL than for the LCL). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Wednesday 19 March 2014 11:31:25 Michael Schnell wrote: The real issue is that in many cases you need to queue not only the call but the parameters for the call as well. Maybe have a look how it is done in MSEgui with tmseevent/tobjectevent, application.postevent() and friends? IIRC you already played with them? Martin -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/19/2014 02:04 AM, Hans-Peter Diettrich wrote: For Windows applications you should eventually know some bits about the main thread message queue. Not really, as LCL and RTL provide as well TThread.Queue and Application.QueueAsyncCall in Windows and Linux (and Mac, AFAIK). In Delphi you just have TThread.Queue. (Hence TThread.Queue in fact is my favorite way of asynchronous signaling. ) The very old style Delphi / Windows way for asynchronous signaling was using PostMessage(); and Procedure message .. . We poor Delphi programmers were forced to do this before Borland and friends implemented TThread.Queue() . In fact they were bold enough to provide the documentation for TThread.Queue only several versions later than the actually working implementation. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/19/2014 01:00 PM, Martin Schreiber wrote: Maybe have a look how it is done in MSEgui with tmseevent/tobjectevent, application.postevent() and friends? IIRC you already played with them? :-) :-) :-) Yep ! I do like this stuff ! On behalf of OS and Widget-Set independent and user friendly thread handling MSE is a lot more advanced than Lazarus, because id did not need to take Delphi compatibility into account. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 11:22 AM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and painting in an application? AFAIK, this is not supported by the PostMessage implementation in the LCL in Linux. So it in fact is a Windowish left-over. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 10:38 PM, Sven Barth wrote: Am 17.03.2014 19:15 schrieb Hans-Peter Diettrich drdiettri...@aol.com mailto:drdiettri...@aol.com: How would you handle keyboard and mouse input and painting in an application? Like any other widgetset which does know nothing about PostMessage does? AFAIK, all decent (with event queue, in fact all that support painting) Widget Types that are implemented in the LCL do provide PostMessage for thread - MainThread notification (but not for keyboard and mouse input and painting issues). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/17/2014 11:22 AM, Hans-Peter Diettrich wrote: Michael Schnell schrieb: This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and painting in an application? AFAIK, this is not supported by the PostMessage implementation in the LCL in Linux. The LCL is based on the message queue, regardless of any OS or widgetset. PostMessage is part of the message queue. So it in fact is a Windowish left-over. You didn't answer my question: which other event handling model would you prefer, for use on any target and widgetset? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/18/2014 09:57 AM, Hans-Peter Diettrich wrote: The LCL is based on the message queue, regardless of any OS or widgetset. PostMessage is part of the message queue. Yep. (Even though I prefer the term Event Queue as the queued information this is not necessarily similar to Windowish Messages.) In fact there is an Event Queue in the RTL (that is used e.g. for TThread.xxx based events) and an additional Event Queue that handles events based on the GUI the LCL binds to (here the Events are Messages if the GUI is Windows). With Windows, the Queue itself is implemented in the OS and only _used_ in the LCL, while with any Linux GUIs, the queue is implemented in the LCL and is fed by Events _generated_ by the GUI (no idea about Mac). Now, the GUI-attaching Widget Type implementations in the LCL merge the events of both queues, while the not GUI-attaching Widget types currently even ignore the RTL based queue. You didn't answer my question: which other event handling model would you prefer, for use on any target and widgetset? Because I don't understand the your meaning here. - I personally would prefer TThread.Synchronize and TThread.Queue because both are usable in Delphi, too, and provide as well blocking (.Synchronize) and non-blocking (.Queue) mode with identical syntax. - QueueAsyncCall has it's point, as it's easy to transfer a (queued) parameter to the procedure. With TThread.Queue, this is more effort, as you need to make the synchronized procedure part of a class you install an instance of before sending it to the main thread via TThread.Queue, and later, the instance of course needs to be freed (this seems to be possible in the synchronized procedure itself just before returning) - I don't understand what you intend by mentioning the mouse input and painting issue. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/18/2014 09:57 AM, Hans-Peter Diettrich wrote: The LCL is based on the message queue, regardless of any OS or widgetset. PostMessage is part of the message queue. Yep. (Even though I prefer the term Event Queue as the queued information this is not necessarily similar to Windowish Messages.) The message queue is not restricted to events. In fact there is an Event Queue in the RTL (that is used e.g. for TThread.xxx based events) and an additional Event Queue that handles events based on the GUI the LCL binds to (here the Events are Messages if the GUI is Windows). With Windows, the Queue itself is implemented in the OS and only _used_ in the LCL, while with any Linux GUIs, the queue is implemented in the LCL and is fed by Events _generated_ by the GUI (no idea about Mac). Yes, events fit nicely into a message queue. The events, created by the window manager and other OS services, must find their way to the component and user handlers, what in most widgetsets is done by calling dedicated callback functions. The parameter lists and events must be unified, so that the LCL can provide a common interface for all user supplied handlers. What's so bad in using the Windows messages for that purpose, and what would be your other way of doing that? Now, the GUI-attaching Widget Type implementations in the LCL merge the events of both queues, while the not GUI-attaching Widget types currently even ignore the RTL based queue. What's GUI-attaching? You didn't answer my question: which other event handling model would you prefer, for use on any target and widgetset? Because I don't understand the your meaning here. Do you understand events at all, their implementation and handling? [...] - I don't understand what you intend by mentioning the mouse input and painting issue. Then try to explain how e.g. a key or button press event is processed in your model. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 5:55 PM, Joao Morais l...@joaomorais.com.br wrote: Em 17/03/14 16:28, Marcos Douglas escreveu: On Mon, Mar 17, 2014 at 3:12 PM, Joao Morais l...@joaomorais.com.br wrote: Em 15/03/14 22:47, Marcos Douglas escreveu: So, what the best way to substitute PostMessage? Maybe using QueueAsyncCall + IFPObserved/IFPObserver? Have you tried decoupling your classes with interfaces? I thought, yes, but I want to keep simple as possible. Simplicity and portability - two arguments on behalf of interfaces! =) Simplicity with interfaces, not always... Why portability? If I understood your scenario correctly: Main implements an interface known by Proc, which sends itself to the Proc constructor. That's an idea... but isn't like that today. Proc (following example) do not know Main or any interface that Main knows. Proc could be used in many others classes and not knows nothing about these classes. Because of that Proc only knows an interface that Main, perhaps others should implement. Anyway just thinking out loud, you are the one that knows the requisites, what can and what can't be done. =) The requisites isn't a secret: a form needs to notify many windows using asynchronous messages. PostMessage do that but some programmers say this is an old Windowish approach so, I'm searching another method to do the same PostMessage does and making the code more cross. Regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/18/2014 02:13 PM, Hans-Peter Diettrich wrote: Then try to explain how e.g. a key or button press event is processed in your model. I don't have a model. I just tried to describe what the LCL does. You can see the multiple Queues in the source code: - Queue in the fpc RTL that is fed by things like TThread.Queue - Queue in the Linux GUI based LCL that is fed by events (such as Key or Mouse) generated by the WidgetSet it _attaches_ to (this defines is the attach word that I mentioned) - Queue in the Windows OS the LCL in a Windows based Widget type attaches to (instead of implementing it's own event queue) -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Em 18/03/14 10:47, Marcos Douglas escreveu:
a form needs to notify many windows
using asynchronous messages. PostMessage do that but some programmers
say this is an old Windowish approach so, I'm searching another method
to do the same PostMessage does and making the code more cross.
I missed the async part, sorry. What about reuse App.QueueAsyncCall
with interface?
type
IProcCallback = interface
procedure ASync(data: ptrint);
end;
TProc = class(TObject)
private
FCallback: IProcCallback;
public
constructor Create(const ACallback: IProcCallback);
procedure DoStuff;
end;
constructor TProc.Create(const ACallback: IProcCallback);
begin
inherited Create;
FCallback := ACallback;
end;
procedure TProc.DoStuff;
begin
//...
Application.QueueAsyncCall(@FCallback.ASync, 0);
end;
You can also use {$interfaces corba} if you don't use objects with refcount.
Following this architecture, the responsible for creating TProc instance
(let's say, TMain) needs to know someone that implements IProcCallback,
which can be itself (TMain) of course. TMain knows TProc. TProc, TMain
and others know IProcCallback, and IProcCallback doesn't know anyone.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/18/2014 02:13 PM, Hans-Peter Diettrich wrote: Then try to explain how e.g. a key or button press event is processed in your model. I don't have a model. I just tried to describe what the LCL does. You can see the multiple Queues in the source code: - Queue in the fpc RTL that is fed by things like TThread.Queue This queue may be unusable for LCL messages (dunno). - Queue in the Linux GUI based LCL that is fed by events (such as Key or Mouse) generated by the WidgetSet it _attaches_ to (this defines is the attach word that I mentioned) - Queue in the Windows OS the LCL in a Windows based Widget type attaches to (instead of implementing it's own event queue) IMO these queues are equivalent, only the implementor (Windows/LCL) is different. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Tue, Mar 18, 2014 at 1:52 PM, Joao Morais l...@joaomorais.com.br wrote:
Em 18/03/14 10:47, Marcos Douglas escreveu:
a form needs to notify many windows
using asynchronous messages. PostMessage do that but some programmers
say this is an old Windowish approach so, I'm searching another method
to do the same PostMessage does and making the code more cross.
I missed the async part, sorry. What about reuse App.QueueAsyncCall with
interface?
type
IProcCallback = interface
procedure ASync(data: ptrint);
end;
TProc = class(TObject)
private
FCallback: IProcCallback;
public
constructor Create(const ACallback: IProcCallback);
procedure DoStuff;
end;
constructor TProc.Create(const ACallback: IProcCallback);
begin
inherited Create;
FCallback := ACallback;
end;
procedure TProc.DoStuff;
begin
//...
Application.QueueAsyncCall(@FCallback.ASync, 0);
end;
You can also use {$interfaces corba} if you don't use objects with refcount.
Following this architecture, the responsible for creating TProc instance
(let's say, TMain) needs to know someone that implements IProcCallback,
which can be itself (TMain) of course. TMain knows TProc. TProc, TMain and
others know IProcCallback, and IProcCallback doesn't know anyone.
Ok, this is a good idea -- I'm implementing using concrete classes --
to minimize dependencies... but I still need using an Observer pattern
here because I need a broadcast message for many objects.
IMHO there is a design problem in PostMessage or QueueAsyncCall:
They are using a Pointer to pass arguments -- pointer or PtrInt as the
same. The caller -- using PostMessage or QueueAsyncCall, doesn't
matter -- doesn't know what valid argument that the receiver will
accept. The programmer could send a Record instance, Object, Integer,
whatever. This is not good. Here using interfaces is good: Encapsulate
the Async(AData: PtrInt) in a interface to each class implement your
own code to (a)sync.
Regards,
Marcos Douglas
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Tue, Mar 18, 2014 at 10:04 PM, Hans-Peter Diettrich drdiettri...@aol.com wrote: Marcos Douglas schrieb: The requisites isn't a secret: a form needs to notify many windows using asynchronous messages. PostMessage do that but some programmers say this is an old Windowish approach so, I'm searching another method to do the same PostMessage does and making the code more cross. A solution depends on the handling of your asynchronous messages. As long as the windows (forms?) exist in the same thread, all processing within this thread must be sequential (serialized). This can be achieved with a single queue. When you want true asynchronous processing, implement an thread with its own queue that receives the asynchronous messages. Then you are free to implement your own message dispatcher in that thread. You also can implement your own message dispatcher in the main thread, by implementing your own message loop. But then you risk to make the application temporarily unresponsive, when your asynchronous events are processed before UI messages. Another solution may be an Idle message queue, and IMO something like that is implemented for QueueAsyncCall and OnIdle events. Then it depends on the message priority whether it is processed before (high priority) or after (idle state) UI messages, in the (existing/your) main thread dispatcher. Or you add an OnIdle handler to all target windows, or to the main window only, that looks for and processes the asynchronous events in a dedicated message queue, without blocking the UI. The app do not need these sophistications (for now), it needs to be strong at the first place and I do not want to have problems with synchronization between threads at this moment. However I like your ideas... to the future. For Windows applications you should eventually know some bits about the main thread message queue. Windows e.g. creates mouse move events when needed, but not for every single move; instead the message receives the *current* mouse position, when fetched from the queue. Similarly a WM_PAINT request is queued only when the message queue is empty, and while the update region is not empty. This assures that painting has the lowest priority amongst all messages in the main message queue. Some other messages are sent immediately to a window, bypassing the message queue. And last not least some Windows controls bypass (or peek?) the message queue as well, so that some standard events are never received by user supplied message handlers. At least I found such behaviour with messages related to painting an edit control. Thanks for the tips. Regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Marcos Douglas schrieb: The requisites isn't a secret: a form needs to notify many windows using asynchronous messages. PostMessage do that but some programmers say this is an old Windowish approach so, I'm searching another method to do the same PostMessage does and making the code more cross. A solution depends on the handling of your asynchronous messages. As long as the windows (forms?) exist in the same thread, all processing within this thread must be sequential (serialized). This can be achieved with a single queue. When you want true asynchronous processing, implement an thread with its own queue that receives the asynchronous messages. Then you are free to implement your own message dispatcher in that thread. You also can implement your own message dispatcher in the main thread, by implementing your own message loop. But then you risk to make the application temporarily unresponsive, when your asynchronous events are processed before UI messages. Another solution may be an Idle message queue, and IMO something like that is implemented for QueueAsyncCall and OnIdle events. Then it depends on the message priority whether it is processed before (high priority) or after (idle state) UI messages, in the (existing/your) main thread dispatcher. Or you add an OnIdle handler to all target windows, or to the main window only, that looks for and processes the asynchronous events in a dedicated message queue, without blocking the UI. For Windows applications you should eventually know some bits about the main thread message queue. Windows e.g. creates mouse move events when needed, but not for every single move; instead the message receives the *current* mouse position, when fetched from the queue. Similarly a WM_PAINT request is queued only when the message queue is empty, and while the update region is not empty. This assures that painting has the lowest priority amongst all messages in the main message queue. Some other messages are sent immediately to a window, bypassing the message queue. And last not least some Windows controls bypass (or peek?) the message queue as well, so that some standard events are never received by user supplied message handlers. At least I found such behaviour with messages related to painting an edit control. DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/16/2014 02:47 AM, Marcos Douglas wrote: Like all Windows programmer, I use PostMessage/SendMessage a lot. Lazarus team has created Application.QueueAsyncCall method to substitute the (old) Windowish method todo async calls aka PostMessage. Ok. But what is the best way to use QueueAsyncCall when the caller to not knows what type is the receiver? As QueueAsyncCall does not exist in Delphi you might want to avoid it to stay Delphi compatible. So you can use TThread.Queue that is available both in Delphi (even though undocumented in some older versions) and in Lazarus/fpc (even though only in the not too old versions). QueueAsyncCall need to know the instance and the method to call... QueueAsyncCall is given the procedure to call and a parameter for same, but no instance. TThread.Queue only gets the (parameter-less) procedure to call. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/16/2014 09:23 AM, zeljko wrote: Why you must substitute PostMessage ? This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 10:56 AM, Michael Schnell wrote: On 03/16/2014 02:47 AM, Marcos Douglas wrote: Like all Windows programmer, I use PostMessage/SendMessage a lot. Lazarus team has created Application.QueueAsyncCall method to substitute the (old) Windowish method todo async calls aka PostMessage. Ok. But what is the best way to use QueueAsyncCall when the caller to not knows what type is the receiver? As QueueAsyncCall does not exist in Delphi you might want to avoid it to stay Delphi compatible. I don't care about Delphi compatibility in any case (in my applications).I'm using Lazarus and don't have any plan to use any commercial developer tool in the future. :) So you can use TThread.Queue that is available both in Delphi (even though undocumented in some older versions) and in Lazarus/fpc (even though only in the not too old versions). No, I'll keep using QueueAsyncCall as it is because it satisfies my needs. zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 11:03 AM, zeljko wrote: No, I'll keep using QueueAsyncCall as it is because it satisfies my needs. I am with you, as QueueAsyncCall additionally provides queuing a parameter for the procedure to be called in the main thread. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 6:56 AM, Michael Schnell mschn...@lumino.de wrote: On 03/16/2014 02:47 AM, Marcos Douglas wrote: Like all Windows programmer, I use PostMessage/SendMessage a lot. Lazarus team has created Application.QueueAsyncCall method to substitute the (old) Windowish method todo async calls aka PostMessage. Ok. But what is the best way to use QueueAsyncCall when the caller to not knows what type is the receiver? As QueueAsyncCall does not exist in Delphi you might want to avoid it to stay Delphi compatible. I don't care about Delphi compatibility. Today I only use FPC/Lazarus. So you can use TThread.Queue that is available both in Delphi (even though undocumented in some older versions) and in Lazarus/fpc (even though only in the not too old versions). QueueAsyncCall need to know the instance and the method to call... QueueAsyncCall is given the procedure to call and a parameter for same, but no instance. TThread.Queue only gets the (parameter-less) procedure to call. Yes, but the QueueAsyncCall needs to know what procedure to call for a especific object (instance). Of course you can simulate not to know which instance calling this procedure and the implementation will instanciate the especific class... adding complexity IMHO. Using PostMessage you can send a broadcast. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 01:31 PM, Marcos Douglas wrote: Yes, but the QueueAsyncCall needs to know what procedure to call for a especific object (instance) I don't understand. The definition of the function (I use) is procedure TApplication.QueueAsyncCall(const AMethod: TDataEvent; Data: PtrInt); with TDataEvent = procedure (Data: PtrInt) of object; I don't see an instance here. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 11:11 AM, Michael Schnell mschn...@lumino.de wrote: On 03/17/2014 01:31 PM, Marcos Douglas wrote: Yes, but the QueueAsyncCall needs to know what procedure to call for a especific object (instance) I don't understand. The definition of the function (I use) is procedure TApplication.QueueAsyncCall(const AMethod: TDataEvent; Data: PtrInt); with TDataEvent = procedure (Data: PtrInt) of object; I don't see an instance here. CASE 1: You have MainForm (Main) and ProcessForm (Proc). Proc do not know Main but Main needs to be updated about what happen in Proc so, Proc can use QueueAsyncCall that need a TDataEvent procedure as argument. If Proc not know Main, how he know the procedure (TDataEvent) to pass on argument? Sugestion: I can Create Proc passing the procedure (TDataEvent) to call inside Proc. CASE 2: You have MainForm (Main), InfoForm (that have 2 Frames F1 and F2 that not know InfoForm) and ProcessForm (Proc). Proc do not know Main, InfoForm or frames but they needs to be updated about what happen in Proc so, Proc can use QueueAsyncCall that need a TDataEvent procedure as argument. If Proc not know about these Handlers, how he know the procedure (TDataEvent) to pass on argument? -- I think that I need is too much for a simple call to QueueAsyncCall. I'm doing tests with FP Observer implementation too. Best regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 03:36 PM, Marcos Douglas wrote: The pointer to the Event Procedure, the self pointer of it's instance (both denoted by AMethod) and the pointer to the parameter to have it called with (denoted byData are queued and when the main thread is ready to handle the event, it calls AMethod appropriately. If you meant the self pointer of AMethod, I of course am with you (as same is a procedure of object). -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 04:09 PM, Michael Schnell wrote: If you meant the self pointer of AMethod, I of course am with you (as same is a procedure of object). But that is rather trivial, and AMethod could be a procedure of any class (inducing but not forcing the TThread instance that schedules the call. I think that I need is too much for a simple call to QueueAsyncCall. I'm doing tests with FP Observer implementation too. A nice trick is to create an instance of a data holding object, fill it and provide it as Data with QueueAsyncCall. In the call you can free the data holding object. Another trick that also works with TThread.Queue is to provide the data holding class with a procedure, create and fill same and provide the procedure (including instance) with TThread.Queue. Here you need to take more care with freeing the object. I'm not sure if you simply can do free; as the last instruction before returning from the procedure. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 04:20 PM, Michael Schnell wrote: I'm not sure if you simply can do free; as the last instruction before returning from the procedure. I just did a test and even this seems to work: An object seemingly can free itself and return to the caller of the function just as if this function would be another destructor. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 12:20 PM, Michael Schnell mschn...@lumino.de wrote: On 03/17/2014 04:09 PM, Michael Schnell wrote: If you meant the self pointer of AMethod, I of course am with you (as same is a procedure of object). But that is rather trivial, and AMethod could be a procedure of any class (inducing but not forcing the TThread instance that schedules the call. I think that I need is too much for a simple call to QueueAsyncCall. I'm doing tests with FP Observer implementation too. A nice trick is to create an instance of a data holding object, fill it and provide it as Data with QueueAsyncCall. In the call you can free the data holding object. I do that today using PostMessage. IMHO the problem in QueueAsyncCall, comparing with PostMessage, it is needs to know what procedure (method of an instance) to call to use on queue meanwhile PostMessage function just put a message on queue. The object that is listening for messages knows what procedure/method to execute itself. Another trick that also works with TThread.Queue is to provide the data holding class with a procedure, create and fill same and provide the procedure (including instance) with TThread.Queue. Here you need to take more care with freeing the object. I'm not sure if you simply can do free; as the last instruction before returning from the procedure. I do not have problems using Threads but I don't use TThread.Queue. I just use TThread.Synchronize and this is works for me. I know TThread.Queue is new, but I never used... maybe you can explain me what advantages, please. Regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 1:35 PM, Michael Schnell mschn...@lumino.de wrote: On 03/17/2014 04:20 PM, Michael Schnell wrote: I'm not sure if you simply can do free; as the last instruction before returning from the procedure. I just did a test and even this seems to work: An object seemingly can free itself and return to the caller of the function just as if this function would be another destructor. Could you send the sources of this test? Thanks, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/17/2014 05:42 PM, Marcos Douglas wrote: Could you send the sources of this test? I could if you are interested. This is a testing project I did for the development of Widget Types (with and without GUI Binding) on behalf of TThread.Synchronize, TThread.Queue, Application.QueueAsyncCall, and PostMessage. -Michael -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 2:25 PM, Michael Schnell mschn...@lumino.de wrote: On 03/17/2014 05:42 PM, Marcos Douglas wrote: Could you send the sources of this test? I could if you are interested. This is a testing project I did for the development of Widget Types (with and without GUI Binding) on behalf of TThread.Synchronize, TThread.Queue, Application.QueueAsyncCall, and PostMessage. I'm interested. Could you send for my mail, please? Thank you. Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Em 15/03/14 22:47, Marcos Douglas escreveu: So, what the best way to substitute PostMessage? Maybe using QueueAsyncCall + IFPObserved/IFPObserver? Have you tried decoupling your classes with interfaces? If I understood your scenario correctly: Main implements an interface known by Proc, which sends itself to the Proc constructor. -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Michael Schnell schrieb: On 03/16/2014 09:23 AM, zeljko wrote: Why you must substitute PostMessage ? This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and painting in an application? DoDi -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On Mon, Mar 17, 2014 at 3:12 PM, Joao Morais l...@joaomorais.com.br wrote: Em 15/03/14 22:47, Marcos Douglas escreveu: So, what the best way to substitute PostMessage? Maybe using QueueAsyncCall + IFPObserved/IFPObserver? Have you tried decoupling your classes with interfaces? I thought, yes, but I want to keep simple as possible. If I understood your scenario correctly: Main implements an interface known by Proc, which sends itself to the Proc constructor. That's an idea... but isn't like that today. Proc (following example) do not know Main or any interface that Main knows. Proc could be used in many others classes and not knows nothing about these classes. Using PostMessage Proc just notify handlers about a message with the possibility to send value objects too. Regards, Marcos Douglas -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Em 17/03/14 16:28, Marcos Douglas escreveu: On Mon, Mar 17, 2014 at 3:12 PM, Joao Morais l...@joaomorais.com.br wrote: Em 15/03/14 22:47, Marcos Douglas escreveu: So, what the best way to substitute PostMessage? Maybe using QueueAsyncCall + IFPObserved/IFPObserver? Have you tried decoupling your classes with interfaces? I thought, yes, but I want to keep simple as possible. Simplicity and portability - two arguments on behalf of interfaces! =) If I understood your scenario correctly: Main implements an interface known by Proc, which sends itself to the Proc constructor. That's an idea... but isn't like that today. Proc (following example) do not know Main or any interface that Main knows. Proc could be used in many others classes and not knows nothing about these classes. Because of that Proc only knows an interface that Main, perhaps others should implement. Anyway just thinking out loud, you are the one that knows the requisites, what can and what can't be done. =) HTH -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
Am 17.03.2014 19:15 schrieb Hans-Peter Diettrich drdiettri...@aol.com: Michael Schnell schrieb: On 03/16/2014 09:23 AM, zeljko wrote: Why you must substitute PostMessage ? This is a Windowish left-over and really alien regarding the OS-independent making of the LCL (even though In fact the LCL even simulates PostMessage in Linux. How would you handle keyboard and mouse input and painting in an application? Like any other widgetset which does know nothing about PostMessage does? Regards, Sven -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Windows.PostMessage vs Application.QueueAsyncCall
On 03/16/2014 02:47 AM, Marcos Douglas wrote: Hi, Like all Windows programmer, I use PostMessage/SendMessage a lot. Lazarus team has created Application.QueueAsyncCall method to substitute the (old) Windowish method todo async calls aka PostMessage. Ok. But what is the best way to use QueueAsyncCall when the caller to not knows what type is the receiver? PostMessage only need to know a Handler and a Integer (message). It can send a broadcast message as well. QueueAsyncCall need to know the instance and the method to call... So, what the best way to substitute PostMessage? Maybe using QueueAsyncCall + IFPObserved/IFPObserver? Why you must substitute PostMessage ? I'm using PostMessage successfully for inter-thread communication,also I'm using QueueAsyncCall when I want to delay something eg. in OnShow of form ... zeljko -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
