On Wed, 26 Oct 2016, LacaK via Lazarus wrote:
Check for Application.ProcessMessages and CheckSynchronize calls.
These process synchronize queue, if I am not mistaken.
I do not call CheckSynchronize nor ProcessMessages in my application.
So only any LCL component or widget set can call
Check for Application.ProcessMessages and CheckSynchronize calls.
These process synchronize queue, if I am not mistaken.
I do not call CheckSynchronize nor ProcessMessages in my application.
So only any LCL component or widget set can call it in background ?
ShowModal() for a modal form
On Tue, Oct 25, 2016 at 9:23 AM, Travis Ayres via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> So...who wants to work on a modern course outline with me? We have a lot
> of opinions and people willing to chime in, maybe we can do something good
> for the community?
>
> On Oct 25, 2016 4:03 AM
Delphi's developers faced exactly the same dilemma with respect to Windows'
behavior. Some of the standard behavior triggering events did not make much
sense and they had to decide to keep it as it was or define an improvement. For
the most part they kept it as it was.
These are not easy dec
On 10 October 2016 at 10:12, Bart via Lazarus wrote:
> On 10/3/16, Michael W. Vogel via Lazarus
> wrote:
> > we want to discuss a bug report
> > http://bugs.freepascal.org/view.php?id=25554 here, not in Mantis (hope,
> > I understand Bart right).
>
> I have remove the call to DoChange in r53089
So...who wants to work on a modern course outline with me? We have a lot of
opinions and people willing to chime in, maybe we can do something good for
the community?
On Oct 25, 2016 4:03 AM, "Michael Schnell via Lazarus" <
lazarus@lists.lazarus-ide.org> wrote:
>
>
> On 24.10.2016 18:11, Travis A
On Tue, 25 Oct 2016 15:02:06 +0200
LacaK via Lazarus wrote:
> >> I do not call CheckSynchronize nor ProcessMessages in my application.
> >> So only any LCL component or widget set can call it in background ?
> >
> > It should be easy for you to set a breakpoint into MyForm.MyMethod and
> > che
On Tue, 25 Oct 2016 13:37:03 +0200
Michael Schnell via Lazarus wrote:
> > If you don't call CheckSynchronize within MyForm.MyMethod then yes.
> IMHO the (hardly documented) CheckSynchronize should not be called
> directly by an application that uses a Widget Type that features an
> Event Que
I do not call CheckSynchronize nor ProcessMessages in my application.
So only any LCL component or widget set can call it in background ?
It should be easy for you to set a breakpoint into MyForm.MyMethod and
check the call stack.
But error (AV) happens only in production and only sometime
On Tue, 25 Oct 2016, LacaK via Lazarus wrote:
Check for Application.ProcessMessages and CheckSynchronize calls.
These process synchronize queue, if I am not mistaken.
I do not call CheckSynchronize nor ProcessMessages in my application.
So only any LCL component or widget set can call it i
On 25.10.2016 14:12, LacaK via Lazarus wrote:
I do not call CheckSynchronize nor ProcessMessages in my application.
So only any LCL component or widget set can call it in background ?
It should be easy for you to set a breakpoint into MyForm.MyMethod and
check the call stack.
Ondrej
--
_
Check for Application.ProcessMessages and CheckSynchronize calls.
These process synchronize queue, if I am not mistaken.
I do not call CheckSynchronize nor ProcessMessages in my application.
So only any LCL component or widget set can call it in background ?
From Delphi doc:
"Synchronize c
Check for Application.ProcessMessages and CheckSynchronize calls.
These process synchronize queue, if I am not mistaken.
I do not call CheckSynchronize nor ProcessMessages in my application.
So only any LCL component or widget set can call it in background ?
-Laco.
--
___
My understanding is that, Synchronize schedules execution of
MyForm.MyMethod to main thread, so method is not executed until
control is returned from event handler in MyForm. Right?
TThread.Synchronze pushes the procedure that is given as a parameter
(including it's Self pointer) to the even
If you don't call CheckSynchronize within MyForm.MyMethod then yes.
IMHO the (hardly documented) CheckSynchronize should not be called
directly by an application that uses a Widget Type that features an
Event Queue. Here the user should do "Application.ProcessMessages", that
is decently docu
On 25.10.2016 13:21, LacaK via Lazarus wrote:
My understanding is that, Synchronize schedules execution of
MyForm.MyMethod to main thread, so method is not executed until
control is returned from event handler in MyForm. Right?
TThread.Synchronze pushes the procedure that is given as a paramete
On 25.10.2016 13:21, LacaK via Lazarus wrote:
I have form on which is button. When user clicks button OnClick event
handler is called (it is method of form). Processing of this method
takes some time say 1 minute.
In the background is operating another thread which every 10 seconds
calls Synchr
Hi *,
I have form on which is button. When user clicks button OnClick event
handler is called (it is method of form). Processing of this method
takes some time say 1 minute.
In the background is operating another thread which every 10 seconds
calls Synchronize(@MyForm.MyMethod).
My understan
On 24.10.2016 18:11, Travis Ayres via Lazarus wrote:
With over 100 replies, we could have already written a course outline,
introduction, ...
It seems we have lost (or silenced) the OP long since :-(
-Michael
--
___
Lazarus mailing list
Lazaru
On Mon, Oct 24, 2016 at 11:41 PM, Martin Schreiber via Lazarus <
lazarus@lists.lazarus-ide.org> wrote:
> On Monday 24 October 2016 19:53:21 Mehmet Erol Sanliturk via Lazarus wrote:
> >
> >
> > My opinion is that event based programming needs special care .
> > A simulation example may be useful ,
20 matches
Mail list logo
