Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread Michael Van Canneyt via Lazarus 



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 it in background ?


ShowModal() for a modal form will call it.


Ah really?
It happens in my application!


Then that is  your problem.

But is it correct behavior ? IMO it is against thread safety, which 
should Synchronize guarantee!


The two issues are completely unrelated. The current behaviour is correct.

Nowhere is it stated or guaranteed that synchronisation cannot happen in a GUI 
event
handler. Any code at any time can call the GUI message loop. A modal form is
just one instance. Your code must be able to deal with this.

Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread LacaK via Lazarus 






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 will call it.


Ah really?
It happens in my application!

Basicaly I have one form MyForm with one background thread, which every 
10 sec. checks for files in shared folder and adds them to listbox 
visible to user:

procedure TRefreshFileListThread.Execute;
begin
  while not Terminated do begin
Synchronize(@MyForm.UpdateFileList); // UpdateFileList is method 
which clears listbox and then adds files in given shared folder

Sleep(1);
  end;

When new file is shown then user can click on button, which imports data 
from this file:
Before import is shown another form with question about "Do you want 
really import file XYZ ?"


Do you say, that when this "question form" is shown it can release call 
to MyForm.UpdateFileList ?

Now I did quick test and it seems, that it is so!

But is it correct behavior ? IMO it is against thread safety, which 
should Synchronize guarantee!
While "main thread" is executing others threads should wait in queue ... 
if not fixable, then can it be documented?, because this is exception 
which is not intuitive


-Laco.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Teaching Pascal at College

2016-10-25 Thread Mehmet Erol Sanliturk via Lazarus 
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, "Michael Schnell via Lazarus" <
> lazarus@lists.lazarus-ide.org> wrote:
>
>>
>>
>> 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
>>
>>


My opinion is that writing a course outline is not an abstract process .


It will be delivered in a Department :

Goals of Department with its web site
Class of Students as Year ( First . ... , Fourth )
Curriculum of Department : Where the course(s) will be embedded
Goals of the Course(s) : What is the purpose of course : What will gain the
students from the course ?
Upward services to other courses : Names of such courses
Prerequisite Courses : If any
Background courses : Previous courses which can be used as supporting the
course
Text books selected for course(s) ;
How many course(s) with weekly number of class hours are selected


Course class schedule ( Two courses , etc. ) will determine load level of
classes
Possible Goals will serve to determine course Names and contents ( examples
, problems , etc. ) .


"Pascal" itself may require an independent course
"Lazarus" itself may require an independent course
"Event driven" programming ( with Petri Nets ) itself may require an
independent course

"Pascal" may be an independent course as a "First" computer programming
course or a "Second" .
There may be a previously taken "Computer Programming Algorithms" ( as
Introduction ) course or students may need such a course independent from a
programming language .


All of these affect a course sequence contents .


This means that to be able to design a course outline which will serve to
your needs , it is necessary to supply the above information ( at least )
without forgetting the instructor factor .


Thank you very much .


Mehmet Erol Sanliturk
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TPageControl OnChange calling issue

2016-10-25 Thread DougC via Lazarus 
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 decisions. One logical approach does not always work in all 
cases. However, good documentation alone goes a long, long way to improving the 
situation.





 On Tue, 25 Oct 2016 14:43:09 -0400vfclists . via Lazarus 
 wrote 




On 10 October 2016 at 10:12, Bart via Lazarus 
 wrote:

I think this is not logical. If the OnChange event is supposed to fire when the 
tab changes, and a PageIndex or a TabIndex changes the tab then it should do as 
it says. If the programmer wants Delphi compatibility then it is for the 
programmer to set a flag so that the OnChange event only fires when the end 
user changes the tab. In that case there should be a new event such as 
OnUserChange or something similar.




These illogical compatibility related definitions cause no end of trouble.If 
ill thought out definitions went into Delphi it is not smart to conform to 
them. Better make it known that they are illogical and that Lazarus and 
Freepascal do it the right way and gives them the option of switching to Delphi 
behaviour.


-- 

Frank Church









-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TPageControl OnChange calling issue

2016-10-25 Thread vfclists . via Lazarus 
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 and documented the
> changes in http://wiki.lazarus.freepascal.org/Lazarus_1.8.0_release_notes#
> TCustomTabControl_setting_TabIndex_or_PageIndex_by_code
>
> @Michl: feel free to open a seperate bugreport for the feature request
> to make this behaviour configurable.
> (Although I think you do not need it anymore?)
>
> Bart
> --
> ___
> Lazarus mailing list
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>


I think this is not logical. If the OnChange event is supposed to fire when
the tab changes, and a PageIndex or a TabIndex changes the tab then it
should do as it says. If the programmer wants Delphi compatibility then it
is for the programmer to set a flag so that the OnChange event only fires
when the end user changes the tab. In that case there should be a new event
such as OnUserChange or something similar.

These illogical compatibility related definitions cause no end of
trouble.If ill thought out definitions went into Delphi it is not smart to
conform to them. Better make it known that they are illogical and that
Lazarus and Freepascal do it the right way and gives them the option of
switching to Delphi behaviour.
-- 
Frank Church

===
http://devblog.brahmancreations.com
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Teaching Pascal at College

2016-10-25 Thread Travis Ayres via Lazarus 
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 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
> Lazarus@lists.lazarus-ide.org
> http://lists.lazarus-ide.org/listinfo/lazarus
>
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread Mattias Gaertner via Lazarus 
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 
> > check the call stack.
> >  
> But error (AV) happens only in production and only sometimes.
> Is there any way how to write call stack into file ?

You can try GetStackTrace(true) and save it string to a file. It must be
called from main thread.

Mattias
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread Mattias Gaertner via Lazarus 
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 Queue. Here the user should do "Application.ProcessMessages", that 
> is decently documented.

CheckSynchronize checks the FPC thread queue.
Application.ProcessMessages calls CheckSynchronize and checks the LCL event 
queues.

It is not forbidden to call CheckSynchronize in a LCL application.

Mattias
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread LacaK via Lazarus 



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 sometimes.
Is there any way how to write call stack into file ?
TIA
-Laco.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread Michael Van Canneyt via Lazarus 



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 in background ?


ShowModal() for a modal form will call it.


Michael.
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread Ondrej Pokorny via Lazarus 

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
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread LacaK via Lazarus 




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 causes the call specified by AMethod to be executed using 
the main thread, thereby avoiding multithread conflicts.
If you are unsure whether a method call is thread-safe, call it from 
within the Synchronize method to ensure that it executes in the main thread.
Execution of the current thread is suspended while the method executes 
in the main thread. "


Looking from where is called CheckSynchronize:

- TWin32WidgetSet.AppProcessMessages

- win32callback.inc:
 case Msg of
  WM_NULL:
  if (Window = Win32WidgetSet.AppHandle) then
  begin
CheckSynchronize;
...

Cann't something send WM_NULL to application which can as reaction run 
sheduled thread ?
WM_NULL sends HandleWakeMainThread() which is handler stored in variable 
WakeMainThread


Messages in win32callback are processed by "main thread" only, so 
execution cann't happen while form method is executed ?


-Laco.


-Laco.


--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread LacaK via Lazarus 


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.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread LacaK via Lazarus 




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 event queue and then the Therad 
that called TThread.Synchronize is stalled.

ok

Some time later the main (GUI) thread will execute the scheduled 
procedure. When this call returns, the thread that called 
TThread.Synchronize is activated.

ok

but what is relation between "main thread" and this "sheduled procedure" 
? Can "sheduled procedure" jump into execution while main thread is 
still executing prior called form method ?




There also is TThread.Queue that works identically, only without 
stalling the thread.

yes, but I do not want this



But in my case happens, that method is executed while execution of 
event handler does not finished yet ... is it expected behavior ?


What is "that method"? If same is called by the thread after 
TThread.Synchronize, IMHO this can't be correct.


Yes this can happen.
MyForm.MyMethod is called also from event handler and also is used in 
Synchronize(@MyForm.MyMethod)

How can this happen/play role?

I have suspection that somewhere in Win32 widgetset is called 
CheckSynchronize as reaction on some message or so, which releases 
execution of MyForm.MyMethod ... but it is inappropriate, does not ?


-Laco.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread Michael Schnell via Lazarus 



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 documented.


-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread Michael Schnell via Lazarus 


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 parameter 
(including it's Self pointer) to the event queue and then the Therad 
that called TThread.Synchronize is stalled. Some time later the main 
(GUI) thread will execute the scheduled procedure. When this call 
returns, the thread that called TThread.Synchronize is activated.


There also is TThread.Queue that works identically, only without 
stalling the thread.


But in my case happens, that method is executed while execution of 
event handler does not finished yet ... is it expected behavior ?


What is "that method"? If same is called by the thread after 
TThread.Synchronize, IMHO this can't be correct.


-Michael

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TThread.Synchronize

2016-10-25 Thread Ondrej Pokorny via Lazarus 

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 Synchronize(@MyForm.MyMethod).


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?


If you don't call CheckSynchronize within MyForm.MyMethod then yes.

But in my case happens, that method is executed while execution of 
event handler does not finished yet ... is it expected behavior ?
If not is there any workaroud which enables me to hold thread until 
event handler finishes ?


Check for Application.ProcessMessages and CheckSynchronize calls. These 
process synchronize queue, if I am not mistaken.


Ondrej
--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] TThread.Synchronize

2016-10-25 Thread LacaK via Lazarus 

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 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?


But in my case happens, that method is executed while execution of event 
handler does not finished yet ... is it expected behavior ?
If not is there any workaroud which enables me to hold thread until 
event handler finishes ?


Thanks

-Laco.

--
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Teaching Pascal at College

2016-10-25 Thread Michael Schnell via Lazarus 



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
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Teaching Pascal at College

2016-10-25 Thread Mehmet Erol Sanliturk via Lazarus 
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 , for example , by using PetriSim
> > sources , adapted to Free Pascal .
>


Please here add the following sentence :


Then a Petri Net definition may be represented by Lazarus forms easily .
I am not ignoring other works such as fpGUI , mseIDE-mseGUI , but we are
talking about mostly Lazarus .




> >
> The last chapter of "Programmieren macht Spass!" is a lift simulation:
> http://mseide-msegui.sourceforge.net/pics/aufzug.mpeg
>
> Martin
> --
> ___
>



It is difficult to play *.mpeg files in Linux ( there is no default player
) . If you have a converter to format which can be played with default
players of Linux ( for example , Dragon Player ) , it would be a very good
contribution .


Simulation subjects may be selected easily for the Department related
subjects where Lazarus is taught .


Mehmet Erol Sanliturk
-- 
___
Lazarus mailing list
Lazarus@lists.lazarus-ide.org
http://lists.lazarus-ide.org/listinfo/lazarus