I have a little problem that my Form gets stuck when I run this first code. I have a lot of code in the event.
The code runs fine but if I now will deactivate the form by clicking with the mouse on the desktop and again click somewhere on the form, the form will "Not respond" and this goes on for about 3 minutes.

// 200 pages of code

Application::DoEvents();
Form2::Update();

Now if I show a MessageBox in the end of the code, click OK, click on the desktop and again clicking on the form, everything works fine and the form respond as it should and doesn´t get stuck.

I dont know why everything works nice when I show a MessageBox. I started to think that I updated the form in somehow by doing that.
This is why I tried Applicaton:: DoEvents() and Form2::Update() in the above code.

I wonder if there would be any other code that fix this like the MessageBox did, peheps some kind of update of the form was done when the messagebox was showed ?

// 200 pages of code

MessageBox::Show("Finish");

Dani AI

Generated

: the behavior you described (handler runs, form later shows "Not Responding" until a modal dialog is shown) is a classic UI-thread blocking symptom. Showing a modal dialog implicitly runs a message loop and lets pending window messages (paint, activation, input) be processed, which is why that made the form responsive again. The open/close-form-in-Load workaround achieves the same side effect but is fragile.

A reliable fix is to stop doing long work on the UI thread. For WinForms/C++/CLI the usual pattern is to run the heavy work on a background thread and marshal only UI updates back to the form. The BackgroundWorker is simple and safe for this scenario; use its DoWork for the long operation, ReportProgress/ProgressChanged for status updates, and RunWorkerCompleted for final UI work. Avoid manual message pumping as a permanent solution because it causes reentrancy and subtle bugs — see the docs for Application.DoEvents for the risks.

Minimal C++/CLI sketch (setup + handlers):

// create and configure
bgw = gcnew System::ComponentModel::BackgroundWorker();
bgw->WorkerReportsProgress = true;
bgw->DoWork += gcnew System::ComponentModel::DoWorkEventHandler(this, &Form1::bgw_DoWork);
bgw->ProgressChanged += gcnew System::ComponentModel::ProgressChangedEventHandler(this, &Form1::bgw_ProgressChanged);
bgw->RunWorkerCompleted += gcnew System::ComponentModel::RunWorkerCompletedEventHandler(this, &Form1::bgw_RunWorkerCompleted);
bgw->RunWorkerAsync();

Key practical notes:

  • Start background work after the form has shown (Shown event) so initial painting is not blocked.
  • Never touch controls directly from the background thread; use ReportProgress or Control::Invoke/BeginInvoke instead.
  • Catch exceptions in DoWork and check RunWorkerCompleted->Error to avoid silent failures.
  • If the code uses COM or synchronization primitives, ensure thread affinity is handled correctly to avoid deadlocks.

References: BackgroundWorker class, Control.Invoke, Application.DoEvents.

: the above should let reproduce a minimal example without sharing full project source.

Recommended Answers

All 2 Replies

Would you mind posting the entire project zipped (with unneeded compiler generated files excluded) so I can run it and take a closer look.

Thank you, William Hemsworth

I appreciate that very much, the problem is that I cant ´give´ out this code.
However it seemed to be solved if I opened a new Form and closed it in the Load_event.
The whole process and solution seems strange and as I beleive for sure wrong solution but I will go with it for now and see if it works without problem.

Regards
/L

Would you mind posting the entire project zipped (with unneeded compiler generated files excluded) so I can run it and take a closer look.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.