Home/ Questions/Q 59537
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-10T18:01:15+00:00

Here’s the situation: I’m developing a simple application with the following structure: FormMain (startup

  • 0

Here’s the situation: I’m developing a simple application with the following structure:

  • FormMain (startup point)
  • FormNotification
  • CompleFunctions

Right?

Well, in FormMain I have the following function:

private void DoItInNewThread(ParameterizedThreadStart pParameterizedThreadStart, object pParameters, ThreadPriority pThreadPriority) {     Thread oThread = new Thread(pParameterizedThreadStart);     oThread.CurrentUICulture = Settings.Instance.Language;     oThread.IsBackground = true;     oThread.Priority = pThreadPriority;     oThread.Name = 'μRemote: Background operation';     oThread.Start(pParameters); }

So, everytime that I need to call a time consuming method located on ComplexFunctions I do the following:

// This is FormMain.cs string strSomeParameter = 'lala'; DoItInNewThread(new ParameterizedThreadStart(ComplexFunctions.DoSomething), strSomeParameter, ThreadPriority.Normal);

The other class, FormNotification, its a Form that display some information of the process to the user. This FormNotification could be called from FormMain or ComplexFunctions. Example:

// This is ComplexFunctions.cs public void DoSomething(string pSomeParameter) {     // Imagine some time consuming task     FormNotification formNotif = new FormNotification();     formNotif.Notify(); }

FormNotify has a timer, so, after 10 seconds closes the form. I’m not using formNotif.ShowDialog because I don’t want to give focus to this Form. You could check this link to see what I’m doing in Notify.

Ok, here’s the problem: When I call FormNotify from ComplexFunction which is called from another Thread in FormMain … this FormNotify disappears after a few milliseconds. It’s the same effect that when you do something like this:

using(FormSomething formSomething = new FormSomething) {    formSomething.Show(); }

How can avoid this?

These are possible solutions that I don’t want to use:

  • Using Thread.Sleep(10000) in FormNotify
  • Using FormNotif.ShowDialog()

This is a simplified scenario (FormNotify does some other fancy stuff that just stay for 10 seconds, but they are irrelevant to see the problem).

Thanks for your time!!! And please, sorry my english.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Almost every GUI library is designed to only allow calls that change the GUI to be made in a single thread designated for that purpose (called the UI thread). If you are in another thread, you are required to arrange for the call to change the GUI to be made in the UI thread. In .NET, the way to do that is to call Invoke (synchronous) or BeginInvoke (asynchronous). The equivalent Java Swing call is invokeLater() — there are similar functions in almost every GUI library.

    There is something called thread affinity. There are two threads in a WinForm Application, one for rendering and one for managing user interface. You deal only with user interface thread. The rendering thread remains hidden – runs in the background. The only objects created on UI thread can manipulate the UI – i.e the objects have thread affinity with the UI thread.

    Since, you are trying to update UI (show a notification) from a different thread than the UI thread. So in your worker thread define a delegate and make FormMain listen to this event. In the event handler (define in FormMain) write code to show the FormNotify.

    Fire the event from the worker thread when you want to show the notification.

    When a thread other than the creating thread of a control tries to access one of that control’s methods or properties, it often leads to unpredictable results. A common invalid thread activity is a call on the wrong thread that accesses the control’s Handle property. Set CheckForIllegalCrossThreadCalls to true to find and diagnose this thread activity more easily while debugging. Note that illegal cross-thread calls will always raise an exception when an application is started outside the debugger.

    Note: setting CheckForIllegalCrossThreadCalls to ture should only be done in DEBUGGIN SITUATIONS ONLY. Unpredicatable results will occur and you will wind up trying to chase bugs that you will have a difficuly tome finding.

    • 0