Question

I’m working on an application that has been tightly bound to GTK# by using Application.Invoke’s through many of it’s libraries. Unfortunately, we’re porting the application (server type application) to a system with no window manager, so it currently crashed when we initialize GTK.

Application.Invoke doesn’t seem to work without calling Application.Init, even when running my own GLib.MainLoop.

I am looking for a suitable replacement for Application.Invoke. How should I go about replacing Application.Invoke within the Libraries used by the application, so that I can remove the dependency on GTK ?

Note: I’ve proposed a refactoring to get rid of the GUI from the app and domain code and move it into a view, but that’s been shot down for now. I’m basically trying to get it to run on a system with no window manager.

Answer 1

Application.Invoke does not need to be replaced (at least for the version I am using). This was a misconception. Application.Inoke simply turns around and adds a delegate to GLib.Timeout, with the timeout set to 0, and returns “false”, therefore only firing once.

Instead of getting rid of Application.Invoke, I attempted to find out why my delegates were not firing when using Application.Invoke without Appliation.Run or Application.Init. Keep in mind that I had already started my own GLib.MainLoop.

As it turns out, the Application’s static constructor calls GLib.Thread.Init(), which is basically a timebomb. GLib’s documentation states that GLib.Thread.Init must be called when using multiple threads, and that if GLib.Thread.Init is ever called, it must be called BEFORE any other GLib usage.

So, in the code I was working with, we added a delegate to GLib.Timeout after Application.Init, but before Application.Run, and before any calls to Application.Invoke. This means we were safe, because Application.Init would invoke the static constructor of Application, therefore invoking GLib.Thread.Init. This was good. However, when we removed Application.Init, and called Timeout.Add first, Thread.Init had not yet been called. This meant that if we called Thread.Init later, the threading, timeouts, delegates, etc, would choke.

Sure enough, Application.Invoke or Application.Run would invoke the static constructor of Application, which in turn would invoke GLib.Thread.Init. This caused the problem.

TLDR;

Long story short, make sure you invoke Application’s static constructor before using Timeout.Add in your application code. Don’t call Glib.Thread.Init manually, because calling it twice on Mono will make the application crash.

This is okay:

Application.Init();
Timeout.Add(0, delegate { return false; });
Application.Invoke(delegate { Console.WriteLine("Hey"); });
Application.Run();

This will ruin your life:

// Application.Init();
Timeout.Add(1000, delegate { return false; });
Application.Invoke(delegate { Console.WriteLine("Hey"); });
new MainLoop().Run();
//Application.Run();

But this is fine:

// Application.Init();
Application.Invoke(delegate {});
Timeout.Add(1000, delegate { return false; });
Application.Invoke(delegate { Console.WriteLine("Hey"); });
new MainLoop().Run();
//Application.Run();