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.

The following features have been added:

• [NEW] Greatly improved the reliability and responsiveness of the grid when the CPU is heavily loaded.

The following bugs have been fixed:

• [BUG] Fixed a bug in the column configurator which in some cases does not allow reordering of visible columns.
• [BUG] Fixed a bug where merged columns were drawn with artifacts.
• [BUG] Fixed a bug when the grid incorrectly draws cells if there are simultaneously visible grouped rows and child header.
• [BUG] Fixed a bug when the grid incorrectly displays a vertical scrollbar if there are simultaneously visible grouped rows and child header.
• Minor bug fixes