Recent

Author Topic: Form shifting when non responsive then responsive  (Read 1799 times)

vonskie

  • Full Member
  • ***
  • Posts: 184
Form shifting when non responsive then responsive
« on: April 25, 2017, 04:01:16 pm »
When you are doing something like using the zipper lib when you tell it to compress the form becomes non responsive then comes back alive after compression is complete... When the form is responsive again it shifts.. When you are compressing a whole list of file it shifts back and forth the whole time... Anyway to avoid this behavior other than multi tread?

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Re: Form shifting when non responsive then responsive
« Reply #1 on: April 25, 2017, 04:15:11 pm »
If you do everything in the main program thread, then you should call
  Application.ProcessMessages;
after a processor-intensive or resource-intensive task.
It's not perfect, but unless you're tying up the CPU for many millions of cycles, it allows the UI to be responsive.

Remy Lebeau

  • Hero Member
  • *****
  • Posts: 1311
    • Lebeau Software
Re: Form shifting when non responsive then responsive
« Reply #2 on: April 25, 2017, 08:47:27 pm »
When you are doing something like using the zipper lib when you tell it to compress the form becomes non responsive then comes back alive after compression is complete... When the form is responsive again it shifts..

That means you are performing the compression in the context of the main UI thread, blocking the UI message loop until the compression is finished.

When you are compressing a whole list of file it shifts back and forth the whole time... Anyway to avoid this behavior other than multi tread?

If the lib exposes a status callback event, you can call Application.ProcessMessages() (or at least TForm.Update() to process pending paint messages) while compressing a file.  Otherwise, you could call it in between each file, but that means the UI is still blocked while compressing each file, and for large compressions that take time, that may still trigger the OS to flag the UI as unresponsive.

Otherwise, using a worker thread is best.  You really should not be doing any blocking operations in the main UI thread at all.
Remy Lebeau
Lebeau Software - Owner, Developer
Internet Direct (Indy) - Admin, Developer (Support forum)

 

TinyPortal © 2005-2018