SendMessage and PostMessage are described to differ from the Windows specification. While the WinAPI sends window messages to the thread, that created (owns) the window, LCLIntf docs say that all messages go to the application message loop.

Can somebody explain the real implementation in the LCL?

DoDi

2011/11/24 Hans-Peter Diettrich :

SendMessage and PostMessage are described to differ from the Windows specification. While the WinAPI sends window messages to the thread, that created (owns) the window, LCLIntf docs say that all messages go to the application message loop.

Shouldn't the thread of the application loop (the main thread) and the thread that creates the windows be the same thread for most (all?) practical purposes anyways?

Bernd

Hans-Peter Diettrich wrote

Can somebody explain the real implementation in the LCL?

There already have been some threads on this issue on forum, so you might want to take a look back for further reference.

(In fact I was about to enhance the Lazarus documentation regarding these and some related functions, but at that time, I was not able to create working offline doc files (such as *.inf) from the source code and so I did not dare to modify the sources, as I could not be sure not to destroy them.)

In short:

These calls are not part of the "common" LCL, but are implemented multiple times in the files related to the different "LCLWidgetType"s (aka "Interfaces"). So they work in with some LCLWidgetTypes and don't work with others (e.g all non GUI related ones) (even though PostMessage() - using a "procedure...message" as a target - could be a useful feature with non-GUI-enabled but threaded applications.)

In short:

For non-Windows controls, SendMessage() works like "Dispatch()": it calls the handler function for the appropriate control. AFAIK, in Windows additionally SendMessage() can additionally pass information to a WinControl, bypassing the LCL's representation of same. SendMessage works like a normal call to the LCL and thus it is forbidden to use it in a Worker Thread, as SendMessage() is a non-reentrant call. OTOH, this is why SendMessage() can provide a return result from the target control to the caller.

PostMessage() queues the message in the EventQueue of the Main thread and thus the delayed action will occur on a maybe much later point in time. This is why no result can be passed back to the caller. The target always is the main thread. In Windows, the target of PostMessage() even can be another running program. "Locally", the target can be (implicitly) a control defined via the LCL, or (explicitly) a user function defined with "procedure...message.

A less windowish, more straight forward, and more versatile work-alike to PostMessage() -> "procedure...message" is
TApplication.QueueAsyncCall(), that does work with Windows and GTK2, but regrettably does not work in many other LCLWidgetTypes.

I did a testing program for the thread related use of these functions. It can be found in the bugtracker.

-Michael

Hans-Peter Diettrich wrote

While the WinAPI sends window messages to the thread, that created (owns) the window, LCLIntf docs say that all messages go to the application message loop.

AFIK, in Windows, it is possible to create (or just use ? ) an Event Queue (aka "message loop") for worker threads. This is not supported by the LCL (nor the Delphi VCL) as the LCL and VCL code is done in a non-reenrant way (supposedly for performance purpose). So this Windows-supported feature can't be used. With non-Windows LCLWidgetTypes, the EventQueue is done "manually" in the appropriate WidgetType related files of the LCL. But here (of course) again only a single EventQueue (for the main thread) is supported. In theory you could create another TApplication object to create another Event queue, but for sure this will crash because of non-reentrancy issues.

-Michael

Even if so, the documentation should be correct for all cases.

Message handling is one of the most important parts of the LCL, which should be well documented. When e.g. window creation or the handling of thread message queues differs across platforms, or is otherwise Delphi incompatible, such essential items should be documented properly.

DoDi

No, I'm pretty sure that gtk2 and qt can have more than 1 event loop (event queue). Both uses glib loop, and qt always start another event loop when eg. shows dialogs or similar stuff.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111124/9cea2314/attachment.html>

What do you mean by this ?

- LCL with gtk and/or qt already does provide support for event loops for more than one thread. (I am pretty sure that this is not the case ?) or
- Theoretically it is possible to provide event loops for multiple threads by an LCL-alike system using gtk and/or qt.

Here I do agree.

Regarding an event loop in an external library, I am pretty sure that LCL does not use same, but manually creates it in pascal code. AFAIK, the gtk or QT widget set library itself does not provide an event loop. Maybe there is an often used library provided for C(++) programs that provides event loops got use with gtk and/or qt. Maybe this in fact is a C++ library and thus not usable with FPC.

-Michael

Regarding an event loop in an external library, I am pretty sure that LCL does not use same, but manually creates it in pascal code.

Q: does the LCL support more than one message queue (the one in Application)?

If not, the widgetsets must route all messages to that queue, so that the handling inside the widgetset is unimportant to the application writer.

DoDi

Hans-Peter Diettrich wrote

Q: does the LCL support more than one message queue (the one in Application)?

There are various event loops:

* Application.Run
* ShowModal makes a loop too
* ProcessMessages has a short lived loop

And user code can also start their own loops by using ProcessMessages

I wouldn't call those loops "event queues", because they don't implement any kind of queues, they process all events which are obtained immediately. The events are not stored in queues. The queue itself is inside the backend library, for example Windows API, X11, etc.

Hans-Peter Diettrich wrote

Q: does the LCL support more than one message queue (the one in Application)?

AFAIK, the implementation in most non-Windows LCLWidgetTypes is that multiple queues are created but the target of all of them is the main thread that provides a "loop" to "poll" all of them. And thus (disregarding the ordering or priority of the events) the resulting effect is the same as if there would be just a single Event Queue. LCL does not provide for means to have the user create additional queues or to allow for queues targeting other threads but the main thread.

-Michael

I think you chose a quite correct wording: Queue = store for events, Loop = functionality that takes events from a queue.

But IMHO (other than Windows) X11 and friends do not provide a relevant "queue" (aka store in this meaning) but here the queue(s) is (are) done in pascal code and are "attached" to X11 / Widget Set functions, that do callbacks to push events into this queue. (In fact it does not matter, if the implementation of X11/WidgetSet internally does some delay before the callback into the LCL is fired, as the LCL only sees the incoming events and (other than with Windows) can't (or in fact does not) issue events towards a potential external queue, what LCL sees is a "not queuing functionality", and thus needs to provide the event queue(s) itself.

-Michael

Indeed, there is an error in my last message. There is at least 1 queue in the LCL:

TApplication.FAsyncCall: TAsyncCallQueues;

And it is pooled by the main application loop.

I took a quick look and I didn't find any other queues in TApplication.

But IMHO (other than Windows) X11 and friends do not provide a relevant "queue" (aka store in this meaning) but here the queue (s) is (are) done in pascal code and are "attached" to X11 / Widget Set functions, that do callbacks to push events into this queue.

Not true, X11 provides a queue for it's own events, see the file: lcl/interfaces/customdrawn/customdrawnobject_x11.inc In the method TCDWidgetSet.AppRun

There are no queues there, only a loop to interact with the queue which is located inside X11. X11 does not send direct events. Direct events are sent by Cocoa and also by Android.

I don't know if you can stick non-X11 events into that queue, but this hability by itself is not what defines something as a queue or not.

LCL only sees the incoming events and (other than with Windows) can't (or in fact does not) issue events towards a potential external queue, what LCL sees is a "not queuing functionality", and thus needs to provide the event queue(s) itself.

I think it works just the same if you implement a queue ourself and pool it mixed in the main loop alternating 1 pool from the backend library and 1 pool from your own queue or if you use the pool of the backend library to store your extra messages.

But if there is no interaction with the backend queue at all, but you only get direct events, then things get problematic. I think that one solution would be creating a dedicated timer and use it to queue our internal pool.

Felipe Monteiro de Carvalho wrote

X11 does not send direct events. Direct events are sent by Cocoa and also by Android. I don't know if you can stick non-X11 events into that queue, but this hability by itself is not what defines something as a queue or not.

The question is what is meant by "send" here. AFAIK, (other than Windows that does a "Messages" mechanism) here, we have callbacks. And Callbacks result from the main thread of the application calling a function. (i.e. the LCL main thread calls it's own subroutine via this mechanism). OTOH, the external Widget Set only "runs" while being in this call and thus the main thread needs to do it "not-busy" waiting within such a call to the Widget set, to have same be responsive to the user. Thus the LCL-code of the mainthread is stalled while the WidgetSet function (including the Callback) is working. So the results that the LCL code produces withing the callback needs to be asynchronously transferred back to be handled (later) in a user-code event handler and thus need to be re-transferred to be handled withing the main execution loop (that calls the user code events). This is why an (additional) event queue fed by (results of) GUI events is necessary.

-Michael

Michael Schnell wrote

The question is what is meant by "send" here. AFAIK, (other than Windows that does a "Messages" mechanism) here, we have callbacks. And Callbacks result from the main thread of the application calling a function.

"here" means what? If it means X11, then you clearly didn't read lcl/interfaces/customdrawn/customdrawnobject_x11.inc

I can only recommend again that you read it to learn how X11 works.

This doesn't answer my question. What's the *source* of the processed messages?

So what happens on PostMessage, in detail when multiple threads post messages at the same time?

TWidgetSet.SendMessage and PostMessage are both documented as thread-safe. Is this correct, and if so, how is that ensured? Does a SendMessage call bypass any other messages which have been queued until that time? (by dispatching the message immediately to the target?)

What happens in TWidgetset.PeekMessage?

DoDi

Dear,

i can't compile lazarus ide or any projects.

Preliminary operation

1) Download and istall Lazarus 0.9.3 (lazarus-0.9.30.2-fpc-2.4.4-win32.exe)
2) with TortoiseSVN i have updated the files

Now the problems:

1) If I start Lazarus receive this errors:

Package: "FCL 1.0.1"
Unit: "XMLCfg"
Unit not founded: "XMLCfg"

Package: "FCL 1.0.1"
Unit: "Menus"
Unit not founded: "Menus"

Package: "FCL 1.0.1"
Unit: "Buttons"
Unit not founded: "Buttons"

... and many others

2) If I execute make or make clean all I receive more than 1887 errors similar to "Error makefile 3656: Command syntax error"
3) If I try to compile Lazarus into IDE the build stop on unit lclbasedowngrade with the message "Your project depends on LCLBase. Replace the dependency with LCL in the project inspector."
4) If I try to compile a new blank project I receive the same error of point 3

Note: Into Project inspector i do not use LCLBase but only LCL

Some ideas? ...and sorry for my very bad English

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sw_dept.vcf
Type: text/x-vcard
Size: 257 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111125/de257d52/attachment.vcf>

Hans-Peter Diettrich wrote

This doesn't answer my question. What's the *source* of the processed messages?

The usual flow of events for mouse / touch / keyboard events is:

Hardware -> Operating System -> Windowing Library -> LCL Widgetset Interface-> LCL

Examples:

Hardware -> Windows Kernel -> Windows API -> LCL-Win32 -> LCL

Hardware -> Linux Kernel -> X11 -> LCL-CustomDrawn -> LCL

Hardware -> Linux Kernel -> X11 -> Qt4 -> LCL-Qt -> LCL

Hans-Peter Diettrich wrote

So what happens on PostMessage, in detail when multiple threads post messages at the same time?

With PostMessage, the events are queued one after the other and (some days later) handled in the main thread in this sequence,

AFAIK, SendMessage (like Dispatch) (at least when addressing a GUI object) can only be used in the Main thread, as it (might) result din just calling the appropriate (not thread safe) LCL function.

-Michael

Hans-Peter Diettrich wrote

Does a SendMessage call bypass any other messages which have been queued until that time? (by dispatching the message immediately to the target?)

AFAIK, Yes. (i.e. in non-Windows LCLWidgetType implementations that provide their own queues, SendMessage() and the main thread loop taking an Event from the queue (can) result in the same function call to Dispatch.)

-Michael

Yep. But regarding the issue discussed, the questions is "when".

AFAIK, the WidgetSet does not create it's ow thread, so the code only runs when called by the Application (LCL's "interface" code).

Thus only within such a call any handling can happen.

I don't know if the Windowing system creates it's own threads.

I suppose, a kind of queuing always is necessary when transferring information from one thread to another.

-Michael

2011/11/25 Guadagnini David :

Hi David,
Could you try to install FPC and Lazarus using this tutorial? http://wiki.freepascal.org/Installing_Lazarus#Compiling.2Finstalling_FPC_and_Lazarus_from_Sources_of_SVN_.28Win32.29

Doesn't need to get and run the installer, just copy sources (and some "binutils" exe files) from SVN.

I will change the tutorial to use FPC 2.5.1 (fixes_2_6) instead.

Marcos Douglas

Try this before to update with SNV
delete all the file in the lazarus directory except the "fpc" and debugger directories and the lazarus executable (keep startlazarus.exe lazarus.exe and lazbuilld.exe), update with SNV and try rebuild the ide itself, so you gave a fresh Lazarus without interference of old .ppu files.
Ciao

2011/11/25 Guadagnini David :

Please have a look at the subject!

And how does PostMessage fit into the picture?

DoDi

Another reason: what when the event handler sends another message, e.g. for reading or writing a property? Queuing the new message would result in an deadlock.

DoDi

Hans-Peter Diettrich wrote

And how does PostMessage fit into the picture?

I'm using PostMessage in an audio application to update position of trackbar on mainform from another thread where audio file is loaded and playing and it works ok (tested qt and gtk2) ... and of course you cannot test result of PostMessage since it can be executed at any time after posting (depends when WS event queue will process your message)
If you need to check for result you must use SendMessage() but in that case you cannot use it from another thread (at least it does not work with qt and gtk2 as I expected or I've misunderstood point of SendMessage()). Qt have similar mechanism: SendEvent() & PostEvent() and it works in same way.

zeljko

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111125/b6056d6d/attachment.html>

Thank you all hor the help,

The problem was in the path variable of windows that in the first instance pointed to an another make

-------------- next part --------------
A non-text attachment was scrubbed...
Name: sw_dept.vcf
Type: text/x-vcard
Size: 257 bytes
Desc: not available
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111125/89954cef/attachment.vcf>

This looks like PostMessage is thread-safe, but is not a proof.

About multiple queues: do LCL forms have an owning thread? On Windows the owning thread is part of the window class data, but what about other widgetsets?

... and of course you cannot test result of PostMessage since it can be executed at any time after posting (depends when WS event queue will process your message)

That's documented behaviour.

If you need to check for result you must use SendMessage() but in that case you cannot use it from another thread (at least it does not work with qt and gtk2 as I expected or I've misunderstood point of SendMessage()).

I just wonder how a broadcast (to HWND_BROADCAST) works with SendMessage. But this is a feature that must not be supported for non-Windows platforms.

Qt have similar mechanism: SendEvent() & PostEvent() and it works in same way.

Are threads supported?

The more I try to understand the Lazarus message handling, the more questions arise :-(

Here's a snippet from the WinAPI SendMessage docs:

>

If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine. If the specified window was created by a different thread, the system switches to that thread and calls the appropriate window procedure. Messages sent between threads are processed only when the receiving thread executes message retrieval code. The sending thread is blocked until the receiving thread processes the message. However, the sending thread will process incoming nonqueued messages while waiting for its message to be processed. <<

The last sentences imply that the LCL *must* be reentrant, when intra-thread messages are implemented. But what about possible deadlocks then?

DoDi

Yes, PostMessage is thread safe.
The PostMessage function places (posts) a message in the message queue and then returns without waiting.
The SendMessage is not thread safe and executes immediately.

About multiple queues: do LCL forms have an owning thread?

No.
Maybe some widget sets have that internally.

Do you mean "need not"?

QT functions are beyond the LCL docs.

The LCL does not support creating windows from other threads. You can try doing that by calling the appropriate widget set functions yourselves. But I don't know if that will work.
So, your question is somewhat theoretical, isn't it?

Mattias

Hans-Peter Diettrich wrote

>> This doesn't answer my question. What's the *source* of the processed >> messages? And how does PostMessage fit into the picture?

If this is for writing documentation, then you are clearly on the wrong track here. Libraries work with the black box concept. The user does not need to know where the messages from PostMessage are stored, they are stored "somewhere" and will reappear "sometime later" in the main thread. That's enough.

Any information of "where" the messages were in between is an implementation detail which can change at any time. It also changes from widgetset to widgetset.

Maybe he want to explain how and where PostMessage can be used in multithreading environment, IMO this is important part since PostMessage is thread safe and gives you ability to do calculating stuff in threads and flood main thread with messages needed by your app. As I already mentioned, I'm already using such stuff in production app (OnAirDeeJay - radio station double player + mixer + libfmod4). Each player have it's own threads for loading data (ogg,mp3,wav), another is playing and 3rd is used for mixing (fade-in, fade- out). Complete stuff is synchronized to main thread via PostMessage and works perectly. Note that eg. player thread sends PostMessage each ms for each tick of TTrackbar, also user can click track bar and seek , also main thread have it's own threads for players to calculate spectrum data ,again PostMessage is response for this part too .... etc etc.

zeljko
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111126/3caaff57/attachment.html>

Hi all!

How do I create a socket server and client in Lazarus? In Delphi I used the visual components of the ICS (Internet Component Suite from The OverByte)

thank's

Fabiano.

on the wiki (http://wiki.lazarus.freepascal.org/Sockets), used an old package. Can't compile on Lazarus from SVN.

Use LNet: http://wiki.lazarus.freepascal.org/lNet
or Synapse: http://wiki.lazarus.freepascal.org/Synapse

LNet is better for single threaded applications and Synapse is better for multi-threaded applications.

Thanks.

The PostMessage function places (posts) a message in the message queue and then returns without waiting.

What again raises the question, how many message queues are supported by the LCL, and what's required to use them. Until now I suppose that the LCL has no platform-independent model for thread message queues, and offers TApplication.QueueAsyncCall instead for cross-platform applications. Right?

Perhaps I meant "must not necessarily...".

Englisch Sprak schwere Sprak ;-)

Right, but the docs should be valid for *all* platforms. This requires to mention cross-platform issues (restrictions...), which affect portable applications. What's a method worth, like TWidgetset.SystemParameters, when it is only supported on Windows?

It would be nice to get "not implemented" errors or at least "platform specific" hints at *compile* time, not only when an application runs on a customer's machine.

The LCL does not support creating windows from other threads. You can try doing that by calling the appropriate widget set functions yourselves. But I don't know if that will work. So, your question is somewhat theoretical, isn't it?

IMO the documentation of the TWidgetset base class is an essential part of the Lazarus documentation. It is not only required to understand the high-level LCL code, but also is a good place for the documentation of the named constants, usable as parameters in many methods across the entire LCL.

DoDi

It's not enough *if* messages can end up in different message queues, and when the user has to implement explicit message handling e.g. in threads.

Any information of "where" the messages were in between is an implementation detail which can change at any time. It also changes from widgetset to widgetset.

You already mentioned multiple message loops in the LCL. That's fine when a user does not have to care about these loops. I only want to know whether (and how) a user may have to provide explicit message handling code.

E.g. it's well known that a single-threaded applications should call Application.ProcessMessages during lengthy tasks, in order to keep the GUI responsive. Is something like that required in threads, too, or what else is the suggested way for inter-thread communication, instead of sending messages?

E.g. TWidgetset.AllocHWND allows to create (hidden) windows, which then can receive messages. Does this allow to send messages to threads, on *all* platforms? Such functionality IMO *can* be implemented in the LCL, for all widgetsets, question is whether it will be supported *by design*, or only exists for Delphi/Win32 compatibility?

DoDi

IMO, when the documentation uses the term "LCL" it should mean the the library as whole or the platform independent part. The "LCL interface" or "LCL widget set" is the glue between the LCL and the widget set.

The "LCL" has only one event queue, running in the main thread. There are some specials in each widget set and/or LCL interface. But these are implementation details, which can change any time.

Until now I suppose that the LCL has no platform-independent model for thread message queues, and offers TApplication.QueueAsyncCall instead for cross-platform applications. Right?

Yes.

Then yes.

QT functions are not valid for all LCL platforms.

Yes, that would be nice.
But many functions are not called directly by the application or are compiled in, but never used.
Maybe a "whole program optimization" compile can show which platform dependent functions are used.
But even this will show too many functions, e.g. functions that are only called on special combinations of parameters.

Are the new modifiers (platform, unimplemented, experimental) in fpc 2.4.2?

Simply write, that the LCL is single threaded with a few exceptions. Create windows and controls only with the main thread. The LCL functions do not check if they are called by the main thread.

Mattias

Maybe you should give people some time to answer your mails, before writing several mails all based on the same misunderstanding.

The LCL is event driven, and it does not matter how many event queues there are behind the scenes.
As always it gets a more complicated with multithreading. Other threads can only produce events via PostMessage, QueueAsyncCall, TThread.Synchronize or RTL functions.
In any case the LCL executes the events only via the main thread.

The Application.ProcessMessages is only needed by the main thread and must only be called by the main thread (like most LCL functions).

TWidgetset.AllocHWND is WinAPI specific.
If you use this you leave the safe harbor of the LCL. Then you have to read the WinAPI docs and see the implementation of the LCL interface code, e.g. for win32.

Mattias

Maybe you should give people some time to answer your mails, before writing several mails all based on the same misunderstanding.

ACK

I'd like to see such statements for all TWidgetset methods, other users may want that, too.

Can the lclintfh/winapih separation be used to distinguish between methods available in all widgetsets, and purely Windows specific extensions (for Delphi compatibility only)?

DoDi

Yes :-)

DoDi

2011/11/26 Felipe Monteiro de Carvalho :

I recently made (but never completed) a multi-threaded client application with LNet (Linux and Windows), the multithreaded networking stuff worked like a charm. I could not observe any problems.

If I were required to begin developing another networking application tomorrow I would choose LNet again.

Bernd

Bernd wrote

If I were required to begin developing another networking application tomorrow I would choose LNet again.

Is LNet still being developed. The last time I checked, nothing has changed in the last year or two - or maybe I was just looking in the wrong place.

The other problem with LNet is that it doesn't have a lot of TCP protocols implemented.

Why not simply use Indy 10.5.x. I've just started using it in a FPC project (using the to be released FPC 2.6.0 code), and so far I haven't detected any major problems. Currently I only use the HTTP (client & server) components from Indy, but will soon start using the FTP (client & server), SMTP and NNTP protocols too.

2011/11/26 Graeme Geldenhuys :

3 months, so there are still some signs of life:
http://svn.freepascal.org/cgi-bin/viewvc.cgi/lnet/?root=fpcprojects

The other problem with LNet is that it doesn't have a lot of TCP protocols implemented.

This might be a valid point, depending on what you need it for.

When I think about network applications I always see myself implementing some obscure rare protocols that sometimes don't even have a name. In my case I needed it for implementing the bitcoin p2p protocol and I already considered doing it with naked sockets alone when I read that bitcoin might eventually switch to using SSL in the near future. lNet seemed to me the simplest way to be prepared for this without needing to depend on a monstrous library of which I would only use 1%.

PS: I have stopped working on this one after It has become clear that bitcoin with its massive design flaws can not survive. The remains of my attempted half-finished pascal implementation are buried here: http://code.google.com/p/fpbitcoin/source/browse/trunk (R.I.P.)

The code that is using lNet is in bitcoin_p2p_peer.inc.pas Its a thread that makes a connection to another client. LNet calls the callback methods that are assigned in the constructor. The main program starts a hand full of these threads to always stay connected with a few peers. Incoming connections are not yet implemented.

If I remember correctly the trick to get blocking IO with lNet was to set the timeout to a non-zero value, then CallAction() will be a blocking call (with a timeout) and then you can easily use one thread per connection.

Bernd

Graeme Geldenhuys wrote

Is LNet still being developed.

I sent some patches some months ago including perl-like regular expression integration into TLTelnet, but from what I remember Almindor never answered my mails.

Maybe I should just commit directly, probably I have commit rights.

Why not simply use Indy 10.5.x.

I checked Indy some time ago because there was a bounty but I was quite lost at how to use it, it seamed much more complex then lnet / synapse.

I also disliked that from their website I got the feeling that Indy is just a legacy, it seams they have a new version written in C#. From my experience this is a strong sign to be very suspicious of them. If they prefered to reimplement from zero instead of using the Pascal version from .NET projects I have strong doubts about their commitment to the Pascal version. The tendency of people that support two APIs which do the same is eventually dropping one of them (for example the removal of Carbon from Mac x86_64)

Daniel Gaspary wrote

but what means this statement "In the future the FCL build will be replaced by the newer Indy.Sockets CLR project." ?

No idea. It seems the description between their CLR and VCL heading are mixed up, or conflicting. Better ask that question in some Indy mailing list.

On 27 November 2011 08:44, Felipe Monteiro de Carvalho

<felipemonteiro.carvalho at ....> wrote

expression integration into TLTelnet, but from what I remember Almindor never answered my mails.

Than is never a good sign, and clearly shows the original authors have moved on. So it seems the LNet project needs a new maintenance crew.

I checked Indy some time ago because there was a bounty but I was quite lost at how to use it, it seamed much more complex then lnet / synapse.

There is API help included with Delphi and Kylix. I found what I needed from that help files without much trouble. There are plenty of really good example projects too.

I also disliked that from their website I got the feeling that Indy is just a legacy, it seams they have a new version written in C#. From my

I don't think one needs to worry too much about that. Indy has shipped with Delphi since D7. So it is an integral part of the Delphi component suite. So I am pretty sure Embarcadero would selvedge the code if it comes to that. There is even discussions about porting Indy to the FireMonkey framework. So many existing Delphi clients seem to use the Indy components in VCL, and would like to continue that with FM.

I think it's still in operation. Almindor responded to a forum post of mine at the beginning of this month and I notice that the last release of LNet was in March this year, so I wouldn't say that a new maintenance crew is needed just yet.

Bernd wrote

3 months, so there are still some signs of life:

If you are lucky, 2-3 commits a year. I'd say LNet is on life support, with the battery charge running very low. But then, it just takes on dedicated developer to revive a dying project.

> The other problem with LNet is that it doesn't have a lot of TCP > protocols implemented. This might be a valid point, depending on what you need it for.

I don't know of any other TCP component suite that has so many protocols implemented. Indy has over a 100+ protocols implemented - that is just amazing. And in nearly all cases, those protocols include the client and server parts - this is something that is mostly missing from all other competing projects.

PS:
I have just completed full cross-platform n-tier support in tiOPF - thanks to Indy. :-) Finally, n-tier support with FPC. No need for something like CORBA, Midas or TCientDataset. tiOPF's n-tier support uses HTTP + XML. The XML nodes are compacted (short node names instead of long names - configurable by developer), then base64 encoded, then zlib'ed (configurable by developer) before transmission. Now that I have it working, I'll see if I can implement JSON support too - reducing the data packets even further, because XML is very verbose. And what is really cool, is that I can switch between local (offline) storage, client/server or n-tier by simply changing a compiler define
- no code changes required at all in my projects! Awesome.

Graeme Geldenhuys wrote

If you are lucky, 2-3 commits a year.

Sorry, my mistake. I was looking at the CHANGELOG file, not the actual repository commit history.

Good job!
This support for n-tier is part of tiOPF or could be use alone?

Marcos Douglas

Marcos Douglas wrote

Good job!

Most of the work and credit must really go to Peter Hinrichsen - I simply ported that code to be FPC and cross-platform enabled.

This support for n-tier is part of tiOPF or could be use alone?

It is part of tiOPF - the best way to write database applications (see promo paragraph). ;-) The n-tier support is simply a new persistence layer (like the existing Oracle, SqlDB, IBX, SQLite etc persistence layers), but called Remote. The interface is exactly the same as all the other persistence layers, that is why you can switch from local storage (XML, CSV, TAB) to client/server, to n-tier (remote) without changing a single line of code in your application. You can even change between database components (SqlDB, IBX, dbExpress, DOA, ZeosLib, FBLib etc) without changing a single line of code.

[promo hat on]
tiOPF has a nice demo (demo 18 - a simple address book demo) showing how much code you can reuse by using tiOPF. The demo supports local storage, client/server and n-tier. The application server has a GUI user interface with a log window (very handy for debugging) and a background Services implementation. The client side has CGI (web), Console, and two GUI implementations. All business objects, business rules and persistence are shared between all applications. All persistence is validated via the unit test project. The demo even includes a web deployment / auto-upgrade application - demonstrating how you can deploy new versions of your application automatically to your clients. This is a very extensive demo showing the true power of tiOPF based applications.
[promo hat off]

OK.
I found this http://lazarus.freepascal.org/index.php/topic,14147.0.html but did not tested.

But there are apps that not uses tiOPF, but could benefit from using n-tier.

Good promotion! =)

You have loaded the new sources?
Is this the right SVN paths?
https://tiopf.svn.sourceforge.net/svnroot/tiopf/tiOPF2/Trunk (source) https://tiopf.svn.sourceforge.net/svnroot/tiopf/tiOPF2_Demos (demo)

Marcos Douglas

Marcos Douglas wrote

OK. I found this http://lazarus.freepascal.org/index.php/topic,14147.0.html but did not tested.

I thought there might be others - but all relatively unknown and untested.

I guess I am a bit spoiled by have all my code, and more importantly, the tiOPF very well unit tested. Automated tests run every three hours to make sure everything is rock solid.

Regarding that link you posted, thanks for that. It might be worth if somebody adds that info to the FPC wiki. Currently the wiki has no info on n-tier support for FPC. I briefly read the forum post, and it sounds promising, but a the same time, it sounds like it still has quite a few problems too. I'll create a small wiki page mentioning some multi-tier option for FPC developer. Somebody else can extend that page further then.

But there are apps that not uses tiOPF, but could benefit from using n-tier.

But then I can't say "It's the best way to write database applications". ;-) I have switched to using tiOPF some 8 years ago, for all my database needs (and even non-database needs). I simply cannot see myself ever going back to dropping a TQuery, TDataset or TDataSource etc components on a form, and with every field defined, locking my UI into a specific database layout and vendor lock-in with every database component used.

Below is what I came from 8 years ago, and I vowed never to go that route again! EVER! :)

http://opensoft.homeip.net:8080/~graemeg/datamodule.png

Saying all that, tiOPF is open source, so anybody can grab the application server code, and see if they can tweak it for a more traditional Delphi-style database development model. I'll start documenting the units used for Remote Persistence, which will help non-tiOPF users if they wanted to adapt the code for their needs.

You have loaded the new sources?

No, I'll commit the changes tomorrow morning. I've just finished the code last night. I've tested under Delphi 7, and FPC under 32-bit Windows and 32-bit Linux. I want to test under 64-bit Linux tomorrow at work, and if all related unit tests pass, then I'll commit it to the repository.

Is this the right SVN paths? https://tiopf.svn.sourceforge.net/svnroot/tiopf/tiOPF2/Trunk (source)

This is the correct path. The demo I was talking about is also under this URI.

The documentation describing most of Demo 18 can be found below. It was a presentation Peter H. gave in 2008 in Australia.

http://tiopf.sourceforge.net/Doc/PersistingObjectsAndRelationships/SimpleCollection/index.shtml

Graeme Geldenhuys wrote

I'll create a small wiki page mentioning some multi-tier option for FPC developer. Somebody else can extend that page further then.

I've created a small page on the wiki.

http://wiki.freepascal.org/multi-tier_options_with_fpc

Well... I personally would not want either to use Delphi.NET for something like this, especially if I want other .NET languages to use this ^^ And maybe Prism/Oxygene/Chrome wasn't as far and popular as it is today, so they used the "main" .NET language.

Regards,
Sven

That is why Lazarus provides the non-Windowish (and LCLWidgetType-independent) function TApplication.QueuAsyncCall).

BTW.: Delphi provides the non-Windowish TThread.Queue function, but unfortunately Lazarus (in fact the FPC RTL that provides the TThread type) does not have it.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111128/42868dae/attachment.html>

Hans-Peter Diettrich wrote

This looks like PostMessage is thread-safe, but is not a proof.

PostMessage just needs to be Thread save, as it is done exactly for the purpose of being called in worker threads. So if it were not thread save, this needs to be considered a bug (not withstanding the lacking documentation).

-Michael

I don't think it makes much sense to apply the WinAPI documentation on a not necessarily Windows based library even if same provides a function with the same name. I think that (if not documented appropriately) you need to consider it just a case of luck if calling the LCL function provides the same outcome as the Windows API call with the same name. (Thus you are very right creating this thread asking for a decent documentation of the function.)

-Michael

Mattias Gaertner wrote

QT functions are beyond the LCL docs.

The fishy thing is that there are WIN-API-look-alike functions in the LCL (such as PostMessage() ) and the lack of a documentation suggests that they are suppose to work as documented by Microsoft (even if the program is not running on Windows). This is not the case with any other LCLWidgetType.

This of course is because in Delhi does the same thing (here of course no other WidgetType than Windows is available at all).

IMHO, at best, these LCL features would be dropped in favor of portable functions (such as TApplication.QueuAsyncCall and TThread.Queue), that can be decently and independently documented. Maybe a "WindowsCompatibility" unit might be provided to allow for using the windowish functions for those who know what they are doing.

-Michael

Hans-Peter Diettrich wrote

On Windows the owning thread is part of the window class data, but what about other widgetsets?

Does the Delphi VLC really support creating Forms from other threads than the main thread ?

AFAIK, the VCL is not more thread save than the LCL is, and this if creating and using a form from a min thread would result in a crash. (I seem to remember that I some years ago did test this and in fact got a crash.)

-Michael

Hans-Peter Diettrich wrote

What again raises the question, how many message queues are supported by the LCL, and what's required to use them.

As creating a Form from a thread is not supported (the LCL is documented to be not thread safe), the target of the Message only can be the main thread, Thus (in effect) there only is a single queue.

-Michael

Hans-Peter Diettrich wrote

IMO the documentation of the TWidgetset base class is an essential part of the Lazarus documentation.

Yep. But, IMHO, the documentation of non LCLWidgetType-dependent is more essential.

PostMessage right now is "supposed to be" non LCLWidgetType-dependent (as it exists in Windows, QT, GTK and supposedly Mac). (I already said that I don't think that this is a good idea.)

-Michael

Mattias Gaertner wrote

The "LCL interface" or "LCL widget set"

Please do use the term "LCLWidgetType" as this is what the IDE user interface provides (Project -> Project Options -> Build Modes) .

So I understand that this is what "users" are supposed to see and what in fact is clear and unambiguous (even though a little bit clumsy),

-Michael

In fact the historical cause is that in Delphi programs the users use "PostMessage()" for that purpose, because "TThread.Queue()" (for reasons I don't understand) is existing for exactly this purpose, but missing in any document ion I know.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20111128/dc311af8/attachment.html>

Please don't hitchhike a running threads with unrelated stuff !

-Michael

It's is not _possible_ in worker threads as Application.ProcessMessages Messages is not thread safe in any way (and there is not work alike for threads).
It's not _viable_ in worker threads as Threads don't provide their own Event Queues and thus there is no Message that could Processed.

In fact, worker threads do not provide Event driven programming.

I already years ago suggested, that Lazarus should be enhanced to allow for "Object-Pascal-style" event driven programming in worker threads (i.e. allowing for creating a TApplication instance for threads - with or without the possibility to create visible forms for threads), but this of course is quite a seldom issued request and needs a lot of very basic work in the LCL, and is not "Delphi-compatible". So I suppose the the chances that anybody is inclined to take on this work are very small.

-Michael

Mattias Gaertner wrote

TWidgetset.AllocHWND is WinAPI specific. If you use this you leave the safe harbor of the LCL.

To be clear this also is true with PostMessage(), as there are lots of Windows-specific Message-Numbers and possible targets for Messages that are not portable.

-Michael

--- El dom 27-nov-11, Graeme Geldenhuys escribi?:

The tiOPF Quick Start at http://tiopf.sourceforge.net/Doc/QuickStart/index.shtml is half written, do you have the missing part? or do you have some Lazarus oriented documentation that helps to learn how to use the framework?

A tutorial similar to the presentation in SimpleCollection link but oriented to Lazarus would be great.

Jesus Reyes A.

The "Quick Start" was an early attempt at the "Simple Collection" page. I'll read the content of the "Quick Start" page again and see if it can be merged with the "Simple Collection" or if it really needs to be a separate page - at which point it needs to be completed.

A tutorial similar to the presentation in SimpleCollection link but oriented to Lazarus would be great.

Yes, this is already done in a ODT document (OpenDocument Text format), but not published to the web yet. My bad. I'll generate a PDF from the ODT, which is at work (so I can't do it now). I'll post a download link on the web page "Simple Collections" page, and a link here in the mailing list. This document use Lazarus IDE, and FPCUnit.