Question

There are 2 forms.

Form2 isn’t auto-created.

 Form2:=TForm2.Create(Application);
 Form2.Show;

If to do Sleep(10000); inside any forms then another one will be frozen. How to prevent this behavior?

My problem: a big text file (3 Mb) is continuously assigned (Lines.Assign) into a text editor, so a form is frozen.

Can I use another unfrozen form (not modal) to show a progress bar (a style is pbstMarquee)?

Answer 1

All GUI code should be run from the main thread, and it looks like you are following that rule.

If you call Sleep then the calling thread will not execute code until the timeout elapses. If you call Sleep from the main thread, then the message queue will not be pumped until the timeout elapses. Hence the entire app appears frozen.

Why does calling Sleep from one form affect another form? Because all GUI components are served from the single message queue of the main thread. Once you stop pumping that queue, all GUI components stop receiving queued messages like WM_PAINT, WM_KEYDOWN etc.

As I understand it your problem is that your application appears hung when you are loading a 3MB text file into an edit control. That size of file doesn’t sound very large to me and one obvious solution would be to find an edit control that performs the load better. For example I’m pretty sure that Notepad, Notepad++ etc. do not take steps like showing progress when loading such files. I rather suspect that those apps don’t pump the queue when loading files but you just don’t notice because of the short time taken.

What you don’t want to happen is for you to pump your queue to keep your GUI responsive and in turn allow the user to start loading another file whilst the first one is still loading. You need to disable your UI whilst processing a load operation. A modal progress dialog is one way to do that.

If you can’t switch to a better performing control, you could show a modal progress dialog and use a background thread like this. The background thread would have load the file in small chunks, say into a string list. After each chunk of the file was ready it would then call Synchronize and get the main thread to add the contents of the string list to the edit control, and then clear the string list. The thread would then continue and load the next chunk. Adding to the edit control in small chunks would allow you to keep the message queue serviced.

You could show progress in a status bar rather than a modal dialog which would be less intrusive. But just remember to disable any UI that would cause re-entrant execution.