views:

159

answers:

3

In a Windows Application, when multiple threads are used, I know that it’s necessary to invoke the main thread to update GUI components. How is this done in a Console Application?

For example, I have two threads, a main and a secondary thread. The secondary thread is always listening for a global hotkey; when it is pressed the secondary thread executes an event that reaches out to the win32 api method AnimateWindow. I am receiving an error because only the main thread is allowed to execute said function.

How can I effectively tell the main thread to execute that method, when "Invoke" is not available?


update: if it helps, here is the code. To see the HotKeyManager stuff(where the other thread is coming into play), check out the answer to this question

class Hud
{
    bool isHidden = false;
    int keyId;

    private static IntPtr windowHandle;

    public void Init(string[] args)
    {
        windowHandle = Process.GetCurrentProcess().MainWindowHandle;
        SetupHotkey();
        InitPowershell(args);
        Cleanup();
    }

    private void Cleanup()
    {
        HotKeyManager.UnregisterHotKey(keyId);
    }

    private void SetupHotkey()
    {

        keyId = HotKeyManager.RegisterHotKey(Keys.Oemtilde, KeyModifiers.Control);
        HotKeyManager.HotKeyPressed += new EventHandler<HotKeyEventArgs>(HotKeyManager_HotKeyPressed);
    }

    void HotKeyManager_HotKeyPressed(object sender, HotKeyEventArgs e)
    {
       ToggleWindow();
    }

    private void ToggleWindow()
    {
        //exception is thrown because a thread other than the one the console was created in is trying to call AnimateWindow

        if (isHidden)
        {
            if (!User32.AnimateWindow(windowHandle, 200, AnimateWindowFlags.AW_VER_NEGATIVE | AnimateWindowFlags.AW_SLIDE))
                throw new Win32Exception(Marshal.GetLastWin32Error());
        }
        else
        {
            if (!User32.AnimateWindow(windowHandle, 200, AnimateWindowFlags.AW_VER_POSITIVE | AnimateWindowFlags.AW_HIDE))
                throw new Win32Exception(Marshal.GetLastWin32Error());
        }
        isHidden = !isHidden;
    }

    private void InitPowershell(string[] args)
    {
        var config = RunspaceConfiguration.Create();
        ConsoleShell.Start(config, "", "", args);
    }
}
A: 

Typically it's not done in a console app. If you're trying to use a Win32 GUI API, you should really be running a message loop, I suspect.

You could call Application.Run() or Application.Run(ApplicationContext) from your console app to start a new message loop. The idea would be to then use SynchronizationContext.Current to marshal back to the main thread. However, I haven't managed to get that to work yet... you need to somehow force it to register its message loop as the current synchronization context, and I haven't managed to persuade it to do so :(

Jon Skeet
updated the question with code...if that helps
Joe
A: 

I was thinking backgroundworker, but since you don't have a UI thread that's out of the question (see this question)

The 'classic' threading method of using semaphores should probably work. Use a thread safe queue or collection to store events in and notify the main thread that there is work to be donethrough a synchronization object.

StephaneT
+4  A: 

As the documentation on MSDN say :

The function will fail in the following situations:

  • [...]
  • If the thread does not own the window. [...]

So there is no "main" thread in question here (AFAIK Win32Api doesn't care about witch thread your program entry point is executed on).

The only condition is that you must execute AnimateWindow on a thread that is owning the window that you are animating. That's the one that called CreateWindow as it is the function that define the thread / message-loop afinity).

  • Most of the time as Jon said this thread should be running a message loop created by Application.Run.
    From another thread you could use the Control.Invoke method to force the main thread to execute code. If you don't have a Control reference, just create one while in the main thread and call it's CreateHandle method. If you have a main form just use it
  • The message loop could also be created the old school way, especially if you already create your window by PInvoke anyway. The main thread should have a standard PeekMessage loop waiting at least for WM_QUIT and a WM_EXECUTE_ANIMATE_WINDOW that you define. The secondary thread posing this message via PostMessage or PostThreadMessage.

Now that you have posted your sample code, the problem that you will have is that you aren't trying to animate just any window... but you are trying to animate the console window itself... And you aren't on it's owner thread (otherwise it won't refresh when you create an infinite loop in your application)... so calling AnimateWindow won't be possible except if you manage to coerce windows to execute code on that thread.

The fact console windows are in fact owned by CSRSS witch is a system process executing with elevated rights make messing with them really risky anyway.

Since windows vista it's even impossible to send a message to such windows due to process protection so any vulnerability that could be exploited previously to coerce this thread to execute code should now be unusable.

For the details regarding the specificity of the console window see the Why aren't console windows themed on Windows XP? post on the Raymond Chen blog (from the microsoft windows shell team so it's pretty much from the source)

VirtualBlackFox
I know that it doesn't really care about the main thread. Since it is a console app, the window is created by the main app thread. So, I just said that because it is the one I need to invoke my delegate on. Make sense?
Joe
and it isn't from a different program. It is the same app...i just need to get the delegate to execute on the correct thread. It sounds like PeekMessage might work. I'll look into it, thanks
Joe
I added details on my solutions but with your sample what you seem to try to do looks impossible i explain why in the post.
VirtualBlackFox
Yeah, I actually just realized this myself once I found a solution to my question. Oh well, looks like what I want to do can't be done. Thanks for your help
Joe
On a side note, why am I able to call SetWindowPos but not AnimateWindow? Seems like one isn't any safer than the other.
Joe
SetWindowPos is coming back from the first days of the Win32 API, there was nearly no security consideration in it's design. Anyway windows didn't have a security model to speak of before NT versions. At this time it didn't even have memory isolation. As for why it still work, even when manipulating system processes, the shell team may have been forced to balance application compatibility and real security risks.
VirtualBlackFox