Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » Crash with CExtButton inside a CExtStatusControlBar. Collapse All
Subject Author Date
Eric Aug 4, 2011 - 9:10 AM

I have a serious problem.

Data is loaded into our application using a seperate thread.

This is to give the user the opportunity to cancel the thread if he or she wishes to do so.

The thread is cancled via a CExtButton inside the CExtStatusControlBar.

Our code for creating the button, and removing it, is exactly the same as in the StatusPanes sample application.

I get a crash during the following situation:

When a very small ammount of data is loaded, the thread starts and end very quickly.

So, the ammount of time that the button is "alive" is very short.

The problem is that the button receives a WM_ENABLE message after it’s been destroyed.

This cause the application to crash.

Please note that I am NOT creating and destroying this button across the thread boundary BUT by sending a message to the main frame.

We are using the lastest version of Prot-UIS and the problem was not present with that previous versions.

Any help would be appreciated.

Eric Aug 4, 2011 - 12:37 PM


 

Thank you for the prompt reply.

Sorry if my last message was not clear but I am well aware of basic multi threading concepts in MFC.

As stated in my first message:

PLEASE NOTE THAT I AM NOT CREATING AND DESTROYING THIS BUTTON ACROSS THE THREAD BOUNDARY BUT BY SENDING A MESSAGE TO THE MAIN FRAME.

In other words, the button is created and destroyed IN THE MAIN THREAD OF THE APPLICATION.

What trigs the creation and destruction of the button is a message send from a worker thread to the main thread via SendMessage.

Anyway, the answer I was looking for was the one I found shortly after posting.




Changing


m_wndStatusBar.SetPaneControl(&m_MyButton, ID_PANE_BUTTON, true);




to


m_wndStatusBar.SetPaneControl(&m_MyButton, ID_PANE_BUTTON, false);




That way the control is not destroyed by the satus bar during removal.

Thus avoiding the crash.

Technical Support Aug 4, 2011 - 10:55 AM

MFC and Prof-UIS are only partially multi-threaded. GDI is not multi-threaded at all. So, if you instantiated some CObject, CWnd or CExtButton in some thread, then you must invoke its methods in the same threads only. If the CWnd::FromHandlePermanent() method returns a non-NULL pointer to a CWnd object in some thread, it will return NULL pointer in any other thread. I.e. maps of MFC objects are per-thread individual. You can even consider different threads using different copies of MFC. The same is related to Prof-UIS. The CWnd::FromHandle() method invoked in different threads will return different CWnd * pointers for the same one HWND handle. But you can use HWND handle of CExtButton object in your secondary thread if the button is created in main UI thread. Additionally, Prof-UIS controls use one global instances of Prof-UIS paint manager and command manager components. This means you should use Prof-UIS controls in the main UI thread only.