Re: [Lazarus] Any active plans to release Lazarus with FPC 2.6.4
Le vendredi 14 mars 2014 07:59:00 Mattias Gaertner a écrit : On Fri, 14 Mar 2014 07:26:41 +0100 zeljko zel...@holobit.net wrote: [...] Is there already a patch to get 1.2 to build? (is it just r43371?) A patch for what? Is there a bug? afaik yes , in 1.2 but it's already fixed in trunk and merged to fixes (qt and carbon are affected).Don't know for other problems with 1.2 and 2.6.4 Even 1.2.0 compiles with fpc 2.6.4. What does not work? Mattias I get Lazarus 1.2.0 compiled and packaged with FPC 2.6.4 on x86_64 architechture both using Qt and GTK on a small french Linux distribution without any problem. You can check our compilation scripts (comments are in french, sorry about that): http://git.tuxfamily.org/0linux/0linux.git?p=0linux/0linux.git;a=blob;f=0Linux/d/fpc/fpc.recette http://git.tuxfamily.org/0linux/0linux.git?p=0linux/0linux.git;a=blob;f=0Linux/g/lazarus/lazarus.recette Regards, -- Geoffray « Fatalerrors » Levasseur-Brandin geoffray.levasseurbran...@numericable.fr geoffray.levasseur-bran...@ac-toulouse.fr http://www.geoffray-levasseur.org/ http://0linux.org/ GNU/PG public key : A25E944254C62E34A8E58DCF688A5F74289C1897 Errare humanum est sed perseverare diabolicum aut cretinum. signature.asc Description: This is a digitally signed message part. -- ___ 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
[Lazarus] linux linking
Hi Folks. I've ported a console project from win32 to Linux x86_64, Lazarus 1.0.12 On win32 it compiles and runs OK. On Linux, compilation fails with a linker error: Error: Error while linking and nothing else. Any track to follow ? Is it any way to display more diagnostics ? Thanks, Antonio. --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ 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] linux linking (Solved)
Le 18/03/2014 14:09, Antonio Fortuny a écrit : Hi Folks. I've ported a console project from win32 to Linux x86_64, Lazarus 1.0.12 On win32 it compiles and runs OK. On Linux, compilation fails with a linker error: Error: Error while linking and nothing else. Any track to follow ? Is it any way to display more diagnostics ? Units missing. Thanks, Antonio. --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] linux linking (Solved)
Units missing? Which units? 2014-03-18 12:23 GMT-03:00 Antonio Fortuny a.fort...@sitasoftware.lu: Le 18/03/2014 14:09, Antonio Fortuny a écrit : Hi Folks. I've ported a console project from win32 to Linux x86_64, Lazarus 1.0.12 On win32 it compiles and runs OK. On Linux, compilation fails with a linker error: Error: Error while linking and nothing else. Any track to follow ? Is it any way to display more diagnostics ? Units missing. Thanks, Antonio. --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] linux linking (Solved)
Le 18/03/2014 16:38, Fabio Luis Girardi a écrit : Units missing? Which units? ideintfpackage and LCLIntf unit. This solved the compilation error. 2014-03-18 12:23 GMT-03:00 Antonio Fortuny a.fort...@sitasoftware.lu mailto:a.fort...@sitasoftware.lu: Le 18/03/2014 14:09, Antonio Fortuny a écrit : Hi Folks. I've ported a console project from win32 to Linux x86_64, Lazarus 1.0.12 On win32 it compiles and runs OK. On Linux, compilation fails with a linker error: Error: Error while linking and nothing else. Any track to follow ? Is it any way to display more diagnostics ? Units missing. Thanks, Antonio. --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org mailto:Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org mailto:Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus -- The best regards, Fabio Luis Girardi PascalSCADA Project http://sourceforge.net/projects/pascalscada http://www.pascalscada.com -- ___ Lazarus mailing list Lazarus@lists.lazarus.freepascal.org http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com -- ___ 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
