The following bugs have been fixed:

• [BUG] Fix for the grid’s verbosity in the console of the VS IDE while painting.

The following bug has been fixed:

• [BUG] Fixed a bug where the grid redraw the content of the entire row upon receiving notification from INotifyPropertyChanged interface for missing or hidden column.
• [BUG] Fixed minor bugs in the designer.

The following features have been added:

• [NEW] Added column filter serialization
• [NEW] Reengineered grid designer introducing intuitive and convenient user interface.
• [NEW] Significantly improved grid performance with selection large data volumes.
• [NEW] Overall performance improvement.

The following bugs have been fixed:

• [BUG] Fixed an error with the grid not unsubscribing from objects with composite properties when objects are removed from the grid.
• [BUG] Fixed an error with Dapfor.Net.dll not appearing in the list of available assemblies in Visual Studio.
• [BUG] Fixed an error with Column.Appearance property hiding cell highlighting.
• Minor bug fixes

In most cases programmers use this method without thinking of consequences or its working principle. MSDN documentation says that this method processes messages in queue and when there are no more messages it stops working and passes control to the next code.
In simplified form this method looks as follows:

NativeUnsafeMethods.MSG msg;
while (PeekMessage(out msg))
{
TranslateMessage(ref msg);
DispatchMessage(ref msg);
}

However, we may wonder what happens when application is intensively rendering controls, synchronizing threads and performing other operations in GUI thread? In such situation message queue always contains messages that don’t let method finish its work. As the result, the end user won’t notice the difference in application behavior as Application.DoEvents() will process executing messages, including WM_PAINT messages, i.e. controls will be redrawn and the program will not slow down. However, code execution will stop on Application.DoEvents() method. If there are important operations after this method, they will not be executed until message queue is freed. We have often seen the situation when application was updating stock market prices and in times of high volatility prices were updated with noticeable delays!!!

A simple example of the problem is shown below. Demo application intensively synchronizes threads and paints data. Main GUI thread continuously processes messages (including synchronization messages and WM_PAINT messages). Clicking Start button calls Application.DoEvents() once, and in normal situation it should immediately return control to subsequent code. However, in this example the things are different! This method is followed by MessageBox.Show(…) that doesn’t display anything.
If demo application is fully covered with any other window or collapsed in the taskbar, Windows stops sending WM_PAINT messages and as the result of it message queue becomes empty, Application.DoEvents() method stops and MessageBox.Show(…) is executed.

Download DoEventsExample.zip

Therefore, before using Application.DoEvents() programmers should look at application architecture and ask themselves whether this method is really necessary. If application code really requires Application.DoEvents(), we have added Dapfor.Net.Editors.MessageQueueHelper class starting from version 2.8.4. This class has similar behavior but it also supports maximum execution time limit. If there are no more messages in queue, MessageQueueHelper also stops and passes control to the subsequent code.

Let’s review a specific case of threadpool implementation consisting of a single thread. The requirements to this implementation are:

• Delay between adding task to threadPool and initiation of its execution should be minimal
• If there are no tasks, threadpool should not consume resources. Specifically, context switches should not be allocated to thread that doesn’t process tasks
• Threadpool should provide an interface (IDisposable is the best for it) for correct work termination and guarantee that upon Dispose() call, all tasks including tasks in execution shall be completely terminated.
• Tasks should be executed in sequence without acquiring synchronizing objects.
• Enable recursive task execution
• Providing interface for exception handling.

So, there are many requirements and all of those are sufficient. Monitor class is most convenient to implement thread synchronizations. It allows to protect task queue and to move thread to sleep state where it doesn’t consume resources and take it out of this state upon receiving a signal. On adding a new task to the queue and on thread termination request a signal should be sent to this thread. Another useful property of the Monitor is recursive and safe acquiring of the same synchronizing object enabling recursive task addition.

Now let’s review the process of thread pool termination. When a new thread is launched, it is transmitted a method called by the newly created thread. This method usually contains a task processing loop. During execution this cycle constantly checks value of a flag that specifies whether it is necessary to stop task processing. This flag is initially set to false, but Dispose function is set to true. When the calling thread sets this flag to true and notifies the threadpool about it, this thread should wait until threadPool execution ends using Join() method. If threadpool execution doesn’t end in allocated time, the calling thread may be forcibly terminated using Abort().

Exception handling. All task exceptions occur in threadPool thread. Therefore, if it they are not processed, the thread stops. To prevent it, the thread should catch all exceptions occurring during task execution. In a well designed system threadpool should provide interface for notification of extraordinary situation. UnhandledException event is most suitable for this purpose.
As new thread is not launched instantly, to prevent sending tasks to uninitialized thread, it is reasonable to add Monitor to thread start at threadPool.

Now we have just a few things to do – define the interfaces:

public interface ITask
{
    void Execute();
}

public interface IDispatcher
{
    void Dispatch(ITask task);
}

An example of ITask implementation enabling use of anonymous methods and lambda expressions for code reduction:

public class Task : ITask
{
    private readonly Action _action;

    public Task(Action action)
    {
        if (action == null)
        {
            throw new ArgumentNullException("action");
        }
        _action = action;
    }
    public void Execute()
    {
        _action();
    }
}

Now comes the hero: a code implementing threadpool based on a single thread:

internal sealed class SingleThreadDispatcher : IDispatcher, IDisposable
{
    private readonly Thread _thread;
    private bool _stopping;
    private readonly Queue _queue = new Queue();
    private readonly object _startSynchro = new object();

    public SingleThreadDispatcher()
    {
        lock (_startSynchro)
        {
            _thread = new Thread(Run) { IsBackground = true };
            _thread.Start();

            //White until the thread is started
            Monitor.Wait(_startSynchro);
        }
    }

    private void Run()
    {
        //Release the calling thread
        lock (_startSynchro)
        {
            Monitor.Pulse(_startSynchro);
        }

        while(true)
        {
            bool exit;
            ITask task = null;
            lock (_queue)
            {
                if (_queue.Count == 0)
                {
                    Monitor.Wait(_queue, 500);
                }
                else
                {
                    task = _queue.Dequeue();
                }

                exit = _stopping && _queue.Count == 0;
            }

            //Execute task without lock
            if (task != null)
            {
                try
                {
                    task.Execute();
                }
                catch (Exception e)
                {
                    if(UnhandledException != null)
                    {
                        UnhandledException(this, new UnhandledExceptionEventArgs(e, false));
                    }
                }
            }

            if(exit)
            {
                break;
            }
        }
    }

    public void Dispatch(ITask task)
    {
        lock (_queue)
        {
            _queue.Enqueue(task);
            Monitor.Pulse(_queue);
        }
    }

    public void Dispose()
    {
        lock (_queue)
        {
            _stopping = true;
            Monitor.Pulse(_queue);
        }

        //Join for a thread and if it doesn't exits, abort it.
        if(!_thread.Join(2000))
        {
            _thread.Abort();
        }
    }

    public event UnhandledExceptionEventHandler UnhandledException;
}

Example of initialization:

[STAThread]
static void Main()
{
    using (var t = new SingleThreadDispatcher())
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new MyForm());
    }
}

Example of use:

t.Dispatch(new Task(()=>
{
    //Some code here
}));

Hope this will help you in your dev.
Kind regards,
Dapfor Team