Recent

Author Topic: [solved] ECProgressBar problem  (Read 3236 times)

bobonwhidbey

  • Hero Member
  • *****
  • Posts: 592
    • Double Dummy Solver - free download
[solved] ECProgressBar problem
« on: August 29, 2016, 04:59:29 pm »
I recently installed the June 15, 2016 EyeCandy package. Installation was very easy and all the components are now on a ED-C tab. When I try to use the ECProgressBar nothing happens.
Code: Pascal  [Select][+][-]
  1.     pbar.min :=0;
  2.     pbar.max := 10;
  3.     for i := 0 to 10 do begin
  4.       pbar.Position := i;
  5.       delay(500); // one-half second delay
  6.     end;
     
Pbar is visible on the form but the progress bar does not move. What am I failing to do?
« Last Edit: August 29, 2016, 05:18:15 pm by bobonwhidbey »
Lazarus 3.0RC2, FPC 3.2.2 x86_64-win64-win32/win64

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: ECProgressBar problem
« Reply #1 on: August 29, 2016, 05:10:58 pm »
Without knowing the package or component or having checked anything myself, the most probable cause is that you do not give the GUI time to update the graphics.

Try to call application.processmessage() inside your loop and see if that helps. Most logical place would be to call that directly after you changed the position.

bobonwhidbey

  • Hero Member
  • *****
  • Posts: 592
    • Double Dummy Solver - free download
Re: ECProgressBar problem
« Reply #2 on: August 29, 2016, 05:17:59 pm »
Perfect!  Thank you Molly
Lazarus 3.0RC2, FPC 3.2.2 x86_64-win64-win32/win64

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: [solved] ECProgressBar problem
« Reply #3 on: August 29, 2016, 05:32:58 pm »
Perfect, thank you for reporting back bobonwhidbey.

I made a small error though  :-[. It should read application.processmessages() (with a s attached to the end). But luckily you figured that out yourself :-)

Remember that the Lazarus GUI (whatever widgetset) is event-driven. That means that you can change any property you want but, in case it is affecting graphical display then a paint or redraw event is generated that needs to be processed by the application. As long as this message is not send to through the 'application' it simply will not update the graphics. Other ways to influence that is to call the paint method yourself (but that is not recommended, as each and every individual widget has its own peculiarities).

bobonwhidbey

  • Hero Member
  • *****
  • Posts: 592
    • Double Dummy Solver - free download
Re: [solved] ECProgressBar problem
« Reply #4 on: August 29, 2016, 08:40:37 pm »
My general approach has been to use a Paint event. I'll change my evil ways and start using application.processmessages :)
Lazarus 3.0RC2, FPC 3.2.2 x86_64-win64-win32/win64

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: [solved] ECProgressBar problem
« Reply #5 on: August 30, 2016, 03:38:57 am »
I might not have been completely clear (for which i apologize). Note that i was referring to changing properties while inside a loop that does not get the paint message to get  through.

Usually you can just call a paint method, especially for those situations in which you know what you are doing  ;)

For (never-ending) loops like you showed, it is usually better to call application.processmessages() and let the LCL take care of how/when a control needs to be updated and/or repainted, e.g. why take over LCL's job ? (Only when you really need to, is it not ?)

bobonwhidbey

  • Hero Member
  • *****
  • Posts: 592
    • Double Dummy Solver - free download
Re: [solved] ECProgressBar problem
« Reply #6 on: August 30, 2016, 05:03:35 am »
I understand that you CAN use Paint at times without a problem, but when would it be better to use Paint rather than ProcessMessages?
Lazarus 3.0RC2, FPC 3.2.2 x86_64-win64-win32/win64

molly

  • Hero Member
  • *****
  • Posts: 2330
Re: [solved] ECProgressBar problem
« Reply #7 on: August 30, 2016, 09:25:21 am »
Unfortunately there is not a universal answer to that question as it depends on the component as well as the situation.

Try to look at it the other way around.

Instead of asking yourself when you should use calling paint method (usually the case when you want to force a re-paint at a certain point in time that you want to control), ask yourself when should you use application.processmessages.

When you change a property which influences graphical representation of the component, and you are inside a long ( lasting) loop you should call processmessages() when you are done updating (all) those properties that can influence  graphical display.

Sometimes it is even necessary to call processmessages on multiple occasions in such loops in order to get the GUI to act as you would like it to.

If instead you would use the paint method then you are literally taking over LCL's job (and potentially influence that wrongly).

Usually i only use paint method either when developing my own components (in which case a complete other set of rules apply) or when working with (animated) graphics. On most (if not all) other occasions calling processmessages does the job for me.

Processmessages is good for those situations where you want the GUI to be updated because your code is preventing LCL from doing so automatically.

bobonwhidbey

  • Hero Member
  • *****
  • Posts: 592
    • Double Dummy Solver - free download
Re: [solved] ECProgressBar problem
« Reply #8 on: August 30, 2016, 03:32:41 pm »
Great explanation. Thanks Molly.
Lazarus 3.0RC2, FPC 3.2.2 x86_64-win64-win32/win64

 

TinyPortal © 2005-2018