none
App freezes when unlocking computer RRS feed

  • Question


  • Hi All

    Our application hangs when an user locks and unlock his account.
    After some research we think this may be a threading issue since we are using a backgroundWorker to create some controls that are displayed in the main form.

    I have replicated this on a small project that I will describe.

     

    There is a main form where we want to add some controls.

    The main form starts a backgroundWorker. 

    public MainForm()
    {
    
        InitializeComponent();
    
        InitializeBackgoundWorker();
        _homePageBackgroundWorker.RunWorkerAsync();
    }
    
    private void InitializeBackgoundWorker()
    {
        try
        {
            _homePageBackgroundWorker = new BackgroundWorker();
            _homePageBackgroundWorker.DoWork += newDoWorkEventHandler(_homePageBackgroundWorker_DoWorkStart);
            _homePageBackgroundWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(        _homePageBackgroundWorker_RunWorkerCompleted);  
        }
        catch(Exception ex)
        {
            HandleError(ex);
        }
    }
    
    

     

    On the DoWork, it will create some UI controls by using a custom class.

    private void _homePageBackgroundWorker_DoWorkStart(object sender, DoWorkEventArgs e)
    {
        try
        {
            CreateControls createControl = new CreateControls();
            createControl.LoadControl += new LoadControlDelegate(createControl_LoadControl);
            createControl.AddControls();
        }
        catch (Exception ex)
        {
            HandleError(ex);
        }
    }
    

    The class that creates controls will instantiate them and send them back to the main form via a delegate set in DoWorkStart:

    class CreateControls
    {
    
        public event LoadControlDelegate LoadControl;
    
        public CreateControls()
        {
        }
    
        public void AddControls()
        {
            SearchSmartPartNoResizablePanel smartPart = new  SearchSmartPartNoResizablePanel();
            if(LoadControl != null)
            {
                LoadControl(this, smartPart);
            }
        }
    }
    
    
    void createControl_LoadControl(object sender, Control c)
    {
        try
        {
            if (this.InvokeRequired)
            {
                LoadControlCallback cb = new  LoadControlCallback(createControl_LoadControl);
                this.Invoke(cb, new object[] { sender, c });
            }
            else
            {
                this.Controls.Add(c);
            }
        }
        catch (Exception ex)
        {
            HandleError(ex);
        }
    }
    


    The SearchSmartPartNoResizable control is made of a panel with a splitContainer. The split divides the panel horizontally and in the dowside panel is where the controls are added (Just a couple of textboxes).

    With this scenario, the application seems to work without any problems. But we have noticed that  if you lock and unlock your windows account, then the application is frozen (and you have to kill it).

    The msdn article mentions that "You must be careful not to manipulate any user-interface objects in your DoWork event handler. Instead, communicate to the user interface through the BackgroundWorker events."  (http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.dowork.aspx )

    However this seems really vague... (Be careful is not as explicit as "you shoudn't" or "experience unknown behaviour")

    What could be the consecuences of creating UI controls using a backgroundWorker?
    Could this freezing issue be related with creating UI controls using a backgroundWorker?
    Is this something we should avoid at any cost?

    We have uploaded a sample project that can be used to reproduce the issue: http://www.megaupload.com/?d=B08DDGLA

    Anything that could help us understand this issue would be appreciated.
    Cheers

    Wednesday, March 17, 2010 6:05 PM

Answers

  • We have asked the Microsoft Support team in respect of this issue.

    It seems there is a known bug with Windows Forms when creating UI controls in a thread other than the UI thread.

    This is the answer we have received so far from them (In case this can helps someone else):

     

    I have yet to try and reproduce this problem.  I will look into what you sent and see if I can reproduce it here.  However, there is a known common cause of this in Windows Forms.  And that is UI components being created on non-UI threads.  Please see:

     

    http://support.microsoft.com/kb/943139

     

    Since you are using a BackgroundWorker, I suspect that a window is being created on this thread and it subscribes to the UserPreferenceChanged event.  Please make sure that you are not creating an UI components on a non-UI thread (you can use Spy++ to verify this).

     

     

     

     

    • Marked as answer by SamAgain Tuesday, March 30, 2010 6:33 AM
    Monday, March 22, 2010 2:23 PM

All replies

  • We have asked the Microsoft Support team in respect of this issue.

    It seems there is a known bug with Windows Forms when creating UI controls in a thread other than the UI thread.

    This is the answer we have received so far from them (In case this can helps someone else):

     

    I have yet to try and reproduce this problem.  I will look into what you sent and see if I can reproduce it here.  However, there is a known common cause of this in Windows Forms.  And that is UI components being created on non-UI threads.  Please see:

     

    http://support.microsoft.com/kb/943139

     

    Since you are using a BackgroundWorker, I suspect that a window is being created on this thread and it subscribes to the UserPreferenceChanged event.  Please make sure that you are not creating an UI components on a non-UI thread (you can use Spy++ to verify this).

     

     

     

     

    • Marked as answer by SamAgain Tuesday, March 30, 2010 6:33 AM
    Monday, March 22, 2010 2:23 PM
  • Hi, HuelinSoft:

         Since Microsoft Support team has given some answer. I mark your reply as the answer for now. If there's any improperness, feel free to unmark it and let us know your further concerns.


    Please mark the right answer at right time.
    Thanks,
    Sam
    Tuesday, March 30, 2010 6:31 AM