Empowering communities to develop their languages.

What! The Button didn't take the focus

We have a number of events which are triggered off of losing focus. I had assumed that a text box would lose focus when a button was pressed, however that is not the case. The button began doing it's thing and later the lost focus event fired. Kaboom! Since the state was now different than I expected. Including the following code at the beginning of the OnClick event fixed that.

 if (!_btnNextWord.Focused)
 {
   // we need to make sure that any ghosts have lost their focus 
   // and triggered updates before we do anything else
   _btnNextWord.Focus();
 }

Subclassing GTK# classes

When specializing any GTK# class, you have to override the GType member and it must be public. The following is what is required when specializing the treeview class.

 [DllImport("libgtk-win32-2.0-0.dll")]
 static extern IntPtr gtk_tree_view_get_type();

 public static new GLib.GType GType
 {
   get
   {
     return new GLib.GType(gtk_tree_view_get_type());
   }
 }

Without it, we got mysterious memory access violation exceptions.

Storing subclassed objects in Db4o

When db4o stores a class which is subclassed from another, it actually stores it so that it can be queried from either type (its type or its base type). Therefore, if you query against the base type, the result will be all objects of base type or that specialize that base type.

Db4o is a database, not memory persistance

When you store nested objects of the same type to the database, then query against that type, each nested object will appear at the top level of your query. Use a higher level container if you want to be able to access these from the root.

Windows Nunit doesn't like Mono dllmap config files

Nunit on Windows fails with System.IO.FileNotFoundException: could not load file or assembly 'nunit.core ...' when the test dll it is attempting to load has a .config that includes dllmap sections in order for that to work on Mono. Removing the .config file makes the problem go away.

Gtk blowing up on a dual-core machine

It turns out that even when you label your main function with [STAThread] on a dual-core machine, we get problems with weird crashes (See my request for help). The solution is to use the following thread idiom:

 Glib.Thread.Init();
 Gdk.Threads.Init();
 Application.Init();

 Gdk.Threads.Enter();
 try
 {
   Application.Run();
 }
 finally
 {
   Gdk.Threads.Leave();
 }

For more information, see Mono's discussion of threads.

Disposing of a Control Removes it from the Controls Collection

This code will only dispose of the 1st half of the controls:

foreach (Control control in base.Controls) {

   control.Dispose();

}

This code does what you want:

while(base.Controls.Count>0) {

    base.Controls[0].Dispose();

}