On 11/26/2011 01:33 PM, 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 p
On 11/26/2011 11:50 AM, Hans-Peter Diettrich wrote:
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 fo
On 11/26/2011 08:25 AM, zeljko wrote:
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
On 11/26/2011 01:10 PM, 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
i
On 11/26/2011 11:14 AM, 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 LCLWidge
On 11/26/2011 11:14 AM, 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
On 11/25/2011 10:57 PM, 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
On 11/26/2011 12:07 AM, 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
On 11/25/2011 10:57 PM, Hans-Peter Diettrich wrote:
The more I try to understand the Lazarus message handling, the more
questions arise :-(
Here's a snippet from the WinAPI SendMessage docs:
I don't think it makes much sense to apply the WinAPI documentation on a
not necessarily Windows base
On 11/25/2011 10:57 PM, 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 b
On 11/25/2011 03:08 PM, zeljko wrote:
Qt have similar mechanism: SendEvent() & PostEvent() and it works in
same way.
That is why Lazarus provides the non-Windowish (and
LCLWidgetType-independent) function TApplication.QueuAsyncCall).
BTW.: Delphi provides the non-Windowish TThread.Queue
Mattias Gaertner schrieb:
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.
Yes, that would be nice.
But many functions are not called directly by the application or are
compiled
Mattias Gaertner schrieb:
Maybe you should give people some time to answer your mails, before
writing several mails all based on the same misunderstanding.
ACK
E.g. TWidgetset.AllocHWND allows to create (hidden) windows, which then
can receive messages. Does this allow to send messages to t
On Sat, 26 Nov 2011 11:50:53 +0100
Hans-Peter Diettrich wrote:
> Felipe Monteiro de Carvalho schrieb:
> > On Fri, Nov 25, 2011 at 2:33 PM, Hans-Peter Diettrich
> > wrote:
> This doesn't answer my question. What's the *source* of the processed
> messages?
> >> And how does PostMessage f
On Sat, 26 Nov 2011 11:14:48 +0100
Hans-Peter Diettrich wrote:
> Mattias Gaertner schrieb:
> > On Fri, 25 Nov 2011 22:57:34 +0100
> > Hans-Peter Diettrich wrote:
> >
> >> zeljko schrieb:
> >>> On Friday 25 of November 2011 14:33:16 Hans-Peter Diettrich wrote:
> >>>
> >>>
> >>> > And how does P
Felipe Monteiro de Carvalho schrieb:
On Fri, Nov 25, 2011 at 2:33 PM, 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
w
Mattias Gaertner schrieb:
On Fri, 25 Nov 2011 22:57:34 +0100
Hans-Peter Diettrich wrote:
zeljko schrieb:
On Friday 25 of November 2011 14:33:16 Hans-Peter Diettrich wrote:
> And how does PostMessage fit into the picture?
I'm using PostMessage in an audio application to update position of
On Saturday 26 of November 2011 07:45:36 Felipe Monteiro de Carvalho wrote:
> On Fri, Nov 25, 2011 at 2:33 PM, 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?
>
> I
On Fri, Nov 25, 2011 at 2:33 PM, 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
On Fri, 25 Nov 2011 22:57:34 +0100
Hans-Peter Diettrich wrote:
> zeljko schrieb:
> > On Friday 25 of November 2011 14:33:16 Hans-Peter Diettrich wrote:
> >
> >
> > > And how does PostMessage fit into the picture?
> >
> >
> > I'm using PostMessage in an audio application to update position of
zeljko schrieb:
On Friday 25 of November 2011 14:33:16 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 wor
On Friday 25 of November 2011 14:33:16 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
Michael Schnell schrieb:
On 11/25/2011 10:35 AM, 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
p
Felipe Monteiro de Carvalho schrieb:
On Fri, Nov 25, 2011 at 10:35 AM, 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 Librar
On 11/25/2011 11:09 AM, Felipe Monteiro de Carvalho wrote:
The usual flow of events for mouse / touch / keyboard events is:
Hardware -> Operating System -> Windowing Library -> LCL Widgetset
Interface-> LCL
Yep. But regarding the issue discussed, the questions is "when".
AFAIK, the Widge
On 11/25/2011 10:35 AM, 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, S
On Fri, Nov 25, 2011 at 10:35 AM, 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
E
On 11/25/2011 10:35 AM, 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,
TWidgetSet.SendMess
Felipe Monteiro de Carvalho schrieb:
On Thu, Nov 24, 2011 at 6:18 PM, 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 lo
On Fri, Nov 25, 2011 at 10:14 AM, 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
On 11/25/2011 09:45 AM, 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 ques
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 d
On 11/24/2011 08:56 PM, Felipe Monteiro de Carvalho wrote:
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 no
On 11/24/2011 06:18 PM, 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 "
On Thu, Nov 24, 2011 at 6:18 PM, 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 thei
Michael Schnell schrieb:
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
On 11/24/2011 12:46 PM, zeljko wrote:
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
What do you mean by this ?
- LCL with gtk and/or qt already d
On Thursday 24 of November 2011 10:12:25 Michael Schnell wrote:
> 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 (su
Bernd schrieb:
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.
Shou
On 11/24/2011 08:44 AM, 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 "messa
On 11/24/2011 08:44 AM, 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 reg
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 t
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 L
43 matches
Mail list logo