How can you find out if you are using the main user interface thread? (In CF)

Question

Now, unfortunately, due to the fact that when starting / uninstalling a WinCE Usb device, it appears through WindowsMessages, I have to make sure that a certain (non-user) component is not created in the background thread. I would like to claim this with an exception, but I don't have enough code to approve.

This component creates MessageWindow * and uses it to receive received or deleted usb messages. The problem is that someone creates this component in the background thread (not necessarily, IsBackground = true), when the thread leaves the window, it will be destroyed.

Any ideas?

* aside, I still don’t know why Form does not inherit from this class

Update

I think my version 1 was not very clear. So this is v2.

When you create a MessageWindow or form in this case in the stream, when this stream exits the window / form, it will be destroyed.

My component creates a "hidden" message box to intercept some important events, ergo, I do not want it to be destroyed. So I have to somehow make sure that the code that creates the form works in the "Main User Interface" thread.

If possible, I would like to avoid passing a link to the "main" form to this component, since it (architecturally speaking) should be a few miles from the user interface.

Update

Moving the registration issue to a separate Q.

Answer 1

Well, I understand that you do not want your component to "know" about the main window - it makes sense.

How about this: how about you always include your component in the main thread? The component will create this listener window in the constructor thread.

If you do this, you just need to make sure that you call the constructor from the main thread. I make some assumptions about your code, but I assume that you should have a class in your architecture that knows about the UI and your component. Build your component there using the callback and the main InvokeRequired / Invoke method.

Answer 2

In forms, you use the InvokeRequired property.

Answer 3

Why not create a non-UI component in the background thread, and when you go on to upgrade any UI component, just look to see if invokeRequired and then go back to the main thread for the actual update.

You should not have anything really related to the main event thread, IMO.

Answer 4

You can use it as follows:

void MyCallback() { if (form1.InvokeRequired) { // form1 is any existing gui control form1.Invoke(new Action<>(MyCallBack)); return; } // your logic here } 

Answer 5

Hi, I had an idea about your problem. This is just a random thought, and I don’t know for sure whether it will work (I did not test or even compile it - it just hit me):

What if you get a window handle to the main window of your application and then create a control around it (I assume you have a gdi-based application like Winforms)?

this code may not compile, but it closes (it will go into your component - note that your component will need a gdi windows / winform application, not a console application or a WPF application).

If you try, I would love to hear if this works for you.

 using System.Diagnostics; using System.Windows.Forms; void Init() { // get handle to the main window intPtr mainWindowHandle = Process.GetCurrentProcess().MainWindowHandle; Control mainWindow = Control.FromHandle(mainWindowHandle); if(mainWindow.InvokeRequired) mainWindow.Invoke(SetupMessageWindow); else SetupMessageWindow(); } void SetupMessageWindow() { // do your thing... }
using System.Diagnostics; using System.Windows.Forms; void Init() { // get handle to the main window intPtr mainWindowHandle = Process.GetCurrentProcess().MainWindowHandle; Control mainWindow = Control.FromHandle(mainWindowHandle); if(mainWindow.InvokeRequired) mainWindow.Invoke(SetupMessageWindow); else SetupMessageWindow(); } void SetupMessageWindow() { // do your thing... }