On Thursday 26 July 2012 08:28:29 Ivanko B wrote:
> What is the purpose of waitus(300)?
>
> For user to watch lblFinStatus.(caption & color).
>
> 2012/7/26, Ivanko B :
> > Oops, it was becfuse of Application.terminated.
> > =
> > No, the code ("lblFinStatus.*" in th
a visit to stomatist
=
To a dentist, sure :) Approx 5$ per a tooth.
2012/7/26, Ivanko B :
> What is the purpose of waitus(300)?
>
> For user to watch lblFinStatus.(caption & color).
>
>
> 2012/7/26, Ivanko B :
>> Oops, it was becfuse of Application.terminated.
>>
What is the purpose of waitus(300)?
For user to watch lblFinStatus.(caption & color).
2012/7/26, Ivanko B :
> Oops, it was becfuse of Application.terminated.
> =
> No, the code ("lblFinStatus.*" in threadcomp.OnTerminated) is entered,
> but the affected widgets d
Oops, it was becfuse of Application.terminated.
=
No, the code ("lblFinStatus.*" in threadcomp.OnTerminated) is entered,
but the affected widgets don't redraw after that code performed.
So, the current solution is:
lblFinStatus.*" & waitus(..) - in threadcomp.OnTerminate
Sh
On Thursday 26 July 2012 08:11:45 Ivanko B wrote:
> Application.terminated:= true called in "Treadcomp.OnTerminated" ater
> ShowMessage seems to be a solution.
> But is it OK that the progress_bar+waitus(300) only redraw in
> ThreadComp.OnTerminate + "application.unlock/lock" ? Me expected it
Oops, it was becfuse of Application.terminated.
Appzs for my being so inattentive - today me had a visit to stomatist :)
2012/7/26, Ivanko B :
> Application.terminated:= true called in "Treadcomp.OnTerminated" ater
> ShowMessage seems to be a solution.
> But is it OK that the progress_bar+waitus(3
Application.terminated:= true called in "Treadcomp.OnTerminated" ater
ShowMessage seems to be a solution.
But is it OK that the progress_bar+waitus(300) only redraw in
ThreadComp.OnTerminate + "application.unlock/lock" ? Me expected it to
redraw in Treadcomp.OnTerminated and w/o "application.u
On Thursday 26 July 2012 08:00:55 Ivanko B wrote:
> "ThreadComp.OnterminateD" seems not to be called if
> ThreadComp.Onterminate calls aplication.terminated:= true at its end
> so moving ShowMessage to "ThreadComp.OnterminateD" doesn't help.
>
After application.terminated has been set to true the a
"ThreadComp.OnterminateD" seems not to be called if
ThreadComp.Onterminate calls aplication.terminated:= true at its end
so moving ShowMessage to "ThreadComp.OnterminateD" doesn't help.
2012/7/26, Ivanko B :
> Hmm..The "lblFinStatus.*" stuff doesn't redraw in OnTerminated:
>
> //-
Hmm..The "lblFinStatus.*" stuff doesn't redraw in OnTerminated:
//-
btnCancel.enabled:= false;
case RESULTCODETY(ExitCode) of
SUCCESS: begin
lblFinStatus.caption:= 'Завершено успешно.';
lblFinStatus.color:= cl_ltgreen;
pbCurrentFile.value:= 1;
pbTo
Oops, it's a new event handler. Appzs !
2012/7/26, Ivanko B :
> 1) still needs application.lock/unlock to redraw GUI elements
> 2) ShowMessage still doesn't show
>
> //
>
> procedure tmainfo.tdupadteterminate(const sender: tthreadcomp);
> begin
> btnCancel.enabled:
On Thursday 26 July 2012 07:27:28 Ivanko B wrote:
> 1) still needs application.lock/unlock to redraw GUI elements
> 2) ShowMessage still doesn't show
>
And why don't you use the onterminated event I implemented especially for you?
Martin
---
1) still needs application.lock/unlock to redraw GUI elements
2) ShowMessage still doesn't show
//
procedure tmainfo.tdupadteterminate(const sender: tthreadcomp);
begin
btnCancel.enabled:= false;
case RESULTCODETY(ExitCode) of
SUCCESS: begin
lblFinStatus.capt
On Thursday 26 July 2012 06:52:45 Ivanko B wrote:
> threadcomp.onterminated which runs in main thread by means of
> synchronize(). ==
> Should "threadcomp.onstarted" do it too ?
> (just a question)
>
I don't think so because starting a thread normally will be done in main
thread.
threadcomp.onterminated which runs in main thread by means of synchronize().
==
Should "threadcomp.onstarted" do it too ?
(just a question)
2012/7/26, Martin Schreiber :
> On Wednesday 25 July 2012 18:10:17 Ivanko B wrote:
>> Use application.synchronize() for that code on Windows
On Wednesday 25 July 2012 18:10:17 Ivanko B wrote:
> Use application.synchronize() for that code on Windows for now
> ===
> Where to place this call ?
Git master c60d3c2cfaadeac6c192b15944483b8453c7e94a has
tthreadcomp.onterminated which runs in main thread by means of synchronize().
On Wednesday 25 July 2012 22:07:03 wahono sri wrote:
> How to draw timage.bitmap from hbitmap (windows)? I see in
> msegdi32.pas, but after some hours I can't understand this concept.
> I call external library to capture image from camera and that library
> give output as hbitmap. I want to draw th
On Thursday 26 July 2012 00:11:57 Graeme Geldenhuys wrote:
> On 25 July 2012 15:43, Martin Schreiber wrote:
> > MSEgui tprogressbar.value is thread safe.
>
> My point was not specific to the TProgressBar. widgte Yes, MSEgui's
> TProgressBar.Value property might be thread safe, but is every other
>
On 25 July 2012 15:43, Martin Schreiber wrote:
>>
> MSEgui tprogressbar.value is thread safe.
My point was not specific to the TProgressBar. widgte Yes, MSEgui's
TProgressBar.Value property might be thread safe, but is every other
property of every MSEgui widget threadsafe too? Developers might
How to draw timage.bitmap from hbitmap (windows)? I see in
msegdi32.pas, but after some hours I can't understand this concept.
I call external library to capture image from camera and that library
give output as hbitmap. I want to draw this hbitmap to timage1.
timage1.bitmap
Thanks
Use application.synchronize() for that code on Windows for now
===
Where to place this call ?
Why me ask - ShowMessage is interactive command, me need to confirm
that to proceed.
2012/7/25, Martin Schreiber :
> On Wednesday 25 July 2012 17:48:57 Ivanko B wrote:
>
>> showmessage(last
On Wednesday 25 July 2012 17:48:57 Ivanko B wrote:
> showmessage(lastopermsglocal,'ОШИБКА АВТООБНОВЛЕНИЯ'); // <<< WANTED TO
> WORK end;
> waitus(300);
Use application.synchronize() for that code on Windows for now.
-
Surprisingly:
//--
showmessage(lastopermsglocal,'ОШИБКА АВТООБНОВЛЕНИЯ'); // <<< WANTED TO WORK
//--
doesn't even show in Appliation.OnTerminateQuery [was the 1st place tried]
2012/7/25, Ivanko B :
> Call application.terminate instead. Application.terminated:= t
Call application.terminate instead. Application.terminated:= true does not
call terminatequery because it can not be canceled.
===
It [bypassing OnTerminateQuery] is done intentionally
- Pressing btnCancell puts the thread to terminate, its OnTerminated
at its very end sets "appliation.te
Should be noted in code.
what to "egrep" ?
2012/7/25, Martin Schreiber :
> On Wednesday 25 July 2012 17:18:43 Ivanko B wrote:
>> MSEgui tprogressbar.value is thread safe.
>> ===
>> A list of all thread safe MSEgui widget's properties ?
>>
> Should be noted in code.
>
On Wednesday 25 July 2012 17:19:34 Ivanko B wrote:
> application.terminated:= true" which doesn't fire
> application's "OnTerminated"
> ==
> Oops, application's "OnTerminateQuery"
>
Call application.terminate instead. Application.terminated:= true does not
call terminatequery because
On Wednesday 25 July 2012 17:18:43 Ivanko B wrote:
> MSEgui tprogressbar.value is thread safe.
> ===
> A list of all thread safe MSEgui widget's properties ?
>
Should be noted in code.
--
Live Security Virtual
On Wednesday 25 July 2012 17:17:46 Ivanko B wrote:
> Hmm, me can't display [called but doesn't show] ShowMessage (to tell
> about a cause why the app has just failed) in
showmessage() out of main thread does not work on Windows at the moment.
> "threadcomp.OnTerminated" and there's nowhere to dis
application.terminated:= true" which doesn't fire
application's "OnTerminated"
==
Oops, application's "OnTerminateQuery"
2012/7/25, Ivanko B :
> MSEgui tprogressbar.value is thread safe.
> ===
> A list of all thread safe MSEgui widget's properties ?
>
>
> 2012/7/25, Ivanko
MSEgui tprogressbar.value is thread safe.
===
A list of all thread safe MSEgui widget's properties ?
2012/7/25, Ivanko B :
> Hmm, me can't display [called but doesn't show] ShowMessage (to tell
> about a cause why the app has just failed) in
> "threadcomp.OnTerminated" and there's now
Hmm, me can't display [called but doesn't show] ShowMessage (to tell
about a cause why the app has just failed) in
"threadcomp.OnTerminated" and there's nowhere to display but this
place (my application blocks its terminating by any means but
threadcomp's "application.terminated:= true" which doesn
On Wednesday 25 July 2012 15:47:16 Graeme Geldenhuys wrote:
> On 25 July 2012 11:47, Ivanko B wrote:
> >> Most GUI
> >> frameworks recommend/dictate that ALL gui work must be done within the
> >> main thread
> >
> > ===
> > Even stepping/resizing progress bars ? How ?
>
> Yes. I have o
On 25 July 2012 11:47, Ivanko B wrote:
>> Most GUI
>> frameworks recommend/dictate that ALL gui work must be done within the
>> main thread
> ===
> Even stepping/resizing progress bars ? How ?
Yes. I have often used threads to notify the main thread to update a
progress bar or other w
On 25 July 2012 10:16, Martin Schreiber wrote:
> Although it is not recommended, MSEgui on Linux can access X11 from worker
> threads, the necessary lock infrastructure is implemented. IIRC it worked on
> Widows too.
Then that is truly impressive!
--
Regards,
- Graeme -
__
On Wednesday 25 July 2012 13:21:01 Ivanko B wrote:
> For example with FPC Synchronize() (not the same as MSEgui
> application.synchronize().
> ===
> What do they do ?
>
Run code in main thread.
--
Live Securit
For example with FPC Synchronize() (not the same as MSEgui
application.synchronize().
===
What do they do ?
2012/7/25, Ivanko B :
> Where is the money?
>
> Me mean if Win-32 & LINUX are declared as currently supported then
> they should behave & look same in MSEgui a
Where is the money?
Me mean if Win-32 & LINUX are declared as currently supported then
they should behave & look same in MSEgui apps :)
2012/7/25, Ivanko B :
> Proposals:
>
> 1) Smth like Python's "threadqueue" as multiple threads where each of
> has same OnExecute procedure but
Proposals:
1) Smth like Python's "threadqueue" as multiple threads where each of
has same OnExecute procedure but with per-thread data/object to
process. With priorities within the queue, sure.
[suitable for multiple file uploading..]
2) maintaining thread variables so that they can be accessed b
On Wednesday 25 July 2012 12:45:45 Ivanko B wrote:
> Probably I made extensions in
> window state tracking code which can deadlock.
> ===
> Sure, the multi platform MSEgui should consistently provide same
> features for all supported platforms :)
>
Where is the money? ;-)
Martin
On Wednesday 25 July 2012 12:47:23 Ivanko B wrote:
> > Most GUI
> > frameworks recommend/dictate that ALL gui work must be done within the
> > main thread
>
> ===
> Even stepping/resizing progress bars ? How ?
>
For example with FPC Synchronize() (not the same as MSEgui
application.syn
> Most GUI
> frameworks recommend/dictate that ALL gui work must be done within the
> main thread
===
Even stepping/resizing progress bars ? How ?
2012/7/25, Ivanko B :
> Probably I made extensions in
> window state tracking code which can deadlock.
> ===
> Sure, the mult
Probably I made extensions in
window state tracking code which can deadlock.
===
Sure, the multi platform MSEgui should consistently provide same
features for all supported platforms :)
2012/7/25, Martin Schreiber :
> On Wednesday 25 July 2012 09:50:35 Graeme Geldenhuys wrote:
>> On
On Wednesday 25 July 2012 09:50:35 Graeme Geldenhuys wrote:
> On 25 July 2012 05:19, Martin Schreiber wrote:
> >> It makes error reporting more complicated (global error codes etc).
> >
> > True, but the Windows architecture dictates constraints. I am not sure if
> > all problems can be solved. On
On 25 July 2012 05:19, Martin Schreiber wrote:
>> It makes error reporting more complicated (global error codes etc).
>
> True, but the Windows architecture dictates constraints. I am not sure if all
> problems can be solved. On Linux it could work.
It's not just Windows, other OSes have the sam
44 matches
Mail list logo
