Taoffi's blog

prisonniers du temps

Back to earth: DBNull and ConetxtMenuStrip target TreeView node


It is time now to set concepts aside for some more practical problems!

Last days, through the work on two different projects, I encountered DBNull twice, and faced a funny problem about locating the target TreeNode of a contextual menu!

Let us start by the first one:

DBNull in Silverlight and Windows Forms

I encountered a DBNull problem two times (in three days… that seems a bit much). The first time was in the context of a WCF service intended to feed a Silverlight application, and the second was in the context of a GridView control in a Windows Forms application.
For your information, DBNull is a .NET Type defined in namespace System (mscorlib.dll).

The first issue emerged with what appeared to be a communication problem between a Silverlight application and one related WCF service. After some research, DBNull was reported to be an unknown Type in XML serialization. The service was transmitting data read through a SQL Server database… We had a Cell class. Its Data member was an object.
A bit more research made it visible that the following code as the source of the annoyance:

cell.Data = data_reader.GetValue(cell_index)


In fact, when the field at cell_index was null, data_reader.GetValue() returned DBNull. Which was assigned as the cell’s Data. Serialized by WCF, DBNull was not recognized by the receiving Silverlight application.

Though the time needed to discover the source of the problem was quite long, the solution was quite simple:


cell.Data = data_reader.IsDBNull(cell_index)

                  ? null :data_reader.GetValue(cell_index)

// Which clearly means:


    cell.Data = null;


    cell.Data = data_reader.GetValue(cell_index)

Now that the cell content is null, everything goes right (because null is a recognize Type).
It will be a great day when DBNull (which implements the ISerializable Interface) will simply be serialized as null… let us just wait.

Yet another DBNull problem!

Once the Silverlight DBNull problem solved… precisely: the next day J, I just found myself again confronted by another DBNull. This time in a Windows Forms application.
In this new case, I had a DataGridView control which was filled using a DataTable and I wanted to programmatically add a row to those displayed in the DataGridView control.
Obtaining the row’s data was simple (calling a web service or by directly querying a database).
The task was then to add the obtained data as a new row of the DataTable used as the source of the control. The problem was again related to the cells containing null values in the new added row.

In fact, if you assign the row’s cells data through a DataRow object you may not have a particular issue. Issues appear when you try to assign an object’s properties values to the row cells.

In this particular case, we had an object with some properties of nullable types: for instance int?  parent_id. The code below generated an error:

DataRow row = table.NewRow()

row["parent_id"] = obj.parent_id;  // an error here when obj.parent_id == null

Some solutions are proposed in several forums. They mainly propose to handle some special events of the DataGridView (like DataError event) and/or play with custom interpretation of DBNull…
The solution I used seems more simple. It is based on the fact that when the row was created (using table.NewRow() method) it contained all required cells… each of which, a priori, filled with something (a sort of ‘null’ thing… we don’t really care about its type). So, we simply may assign cell values only if the data to be assigned is NOT null:

DataRow row = table.NewRow()

if( obj.parent_id != null)

       row["parent_id"] = obj.parent_id;

That seems to work!

Contextual menus… yes! but where is the target node?

TreeView control is a nice and useful control to show many data domains.
One nice and efficient thing of TreeView control is that it allows the developer to handle many aspects of tree nodes by their level in the tree hierarchy. You can for instance choose the icon of items according to their nest level in the tree hierarchy
Among the customizations you can do is to choose a specific contextual menu for each hierarchy level… very cool and simple to do.
When the user right clicks a node in the tree, he or she would see the assigned contextual menu and be able to execute operations in relation to the type of the node.
The thing is, when a menu is clicked, you developer should find out which node was selected when this menu was clicked… Curiously, this is not as simple as we may expect.

I naively thought, a contextual menu object will contain some relevant information about its Target object (in our case: the target Node)… unfortunately this was not true!
So, you simply find yourself with a command to execute (the menu clicked)… but don’t know on which object of the tree should you execute this command!
Few solutions are proposed to solve this problem, and none, of what I read, seemed sustainable.
Here again, we should ‘reinvent the wheel’…

Reinventing the contextual wheel!

The problem seems to be: “Locating the target tree node”. The problem’s definition starts by “Locate”… so let us think “location”.
I first started by trying to locate the mouse cursor at the moment of the click event (using MousePosition which returns the point of the current mouse position in screen coordinates)… but that seemed random, not always related to the node position (and also quite difficult to debugJ).
The next step was to think “location of controls”.
In fact, a contextual menu is a control and as such, it should have a location… hopefully relative to its parent control (which is the TreeView).
Our Click event is received from a contextual menu item (ContextMenuStrip object) which is located into a parent control (the contextual menu box), itself is a child control of the TreeView control containing the node.
The following figure illustrates this disposition 


The Owner property of the menu strip contains its parent menu control information. Through this information, we are able to obtain the location of the menu box, and thus, the location  of the first menu strip relative to the TreeView control. With some more simple arithmetic, we can finally locate the right-clicked node (the target node) using the TreeView control GetNodeAt(Point point) method :



static TreeNode LocateContextMenuTargetNode(

             TreeView            tree_view,

             ToolStripMenuItem   menu_item)


       // check entries

       if( tree_view == null || menu_item == null || menu_item.Owner == null)

             return null;


       ToolStrip           menu  = menu_item.Owner;

       // top most menu item

       ToolStripMenuItem   first = (ToolStripMenuItem) menu.Items[0];


       // obtain the enclosing rectangle of the menu box

       Rectangle           menu_rect   = menu.RectangleToScreen(menu.ClientRectangle);

       // obtain the rectangle relative to the TreeView control

       Rectangle           tv_rect     = tree_view.RectangleToClient(menu_rect);

       // obtain the optimal point that corresponds to the right-clicked node

       Point               point       = newPoint(

                                    first.ContentRectangle.X + tv_rect.X,

                                    first.ContentRectangle.Y + tv_rect.Y);


       // finally, get the right-clicked node

       return tree_view.GetNodeAt(point);




 That works fine for contextual menus with few elements and in a ‘normal’ screen resolution.
If the contextual menu contains many items, the first item may be quite far away from the target node!...So, what?
Let us look for a more sustainable way to locate our item… we may again, rethink ‘mouse location’!

In this solution, we will keep track of the current ‘right-clicked node by responding to the MouseDown event of the TreeView.

TreeNode     m_context_menu_target_node; 

void treeView1_MouseDown(object sender, MouseEventArgs e)
    // if this is not a right-click: do nothing
    if (e.Button != System.Windows.Forms.MouseButtons.Right)
        m_context_menu_target_node = null;
    Point point = e.Location;

    m_context_menu_target_node = treeView1.GetNodeAt(point);


Now, when a contextual menu is clicked, we can first see if the target node is not null… execute the command and reset the target node to null (until the next time): 

       TreeNode node = m_context_menu_target_node;

       if (node == null)

       // reset the target node to null
       m_context_menu_target_node = null; 

       // execute the command on the node


Meta models… what is it and how can it be useful (for you)


I spent a long time during the last months writing about meta-models. That was in the context of a book for Editions ENI (France) about some concepts to which I dedicated some work since quite a while (it was around 1998, as long as I remember, that I started studying the basis of the approach).


In previous posts (see, for instance, Silverlight database to DataGrid, yet another approach- Part II) I exposed a generic approach for describing database meta-data. The direct practical purpose of those posts was reading and displaying data into Silverlight DataGrid. Through this exercise, we also saw how can our structures help us in integrating business rules at several level (meta-column, meta-table… and so on).


In this same exercise, applying the meta-models approach would consist of persisting these structures into the database… to read and create them dynamically.


We would, for instance, store our meta-columns / meta-tables definitions into the database and let our software objects load these structures and transform them into ‘live’ data, integrating all defined business and technical constraints.




What are meta-models?


I use the term "meta-model" to designate "a description of a description" stored in a database and interpreted (read and presented) by one or more (specific) software objects (classes).


That is: the information stored in the database describes an object or a behavior, and the software class that reads this information is aware of the fundamental semantics of this information and is, thus, able to interpret it independently of a particular context.


This means that, according to our view, a meta-model is composed of:


§  Database objects and structures to store the model's data;


§  Software (kernel) objects that know the fundamental semantics of the database model.




The collaborative aspect between the 'description' stored in the database and the 'runtime object' (which reads and interprets that description) is essential for this approach to be applicable.




Why use meta-models?


Let us take a sample application where the software should display a page (or form) composed of a Master / Detail connected regions… i.e. a list of items in a Master grid, with a Detail form that displays the details of the item selected in the Master grid.


That 'Master/Detail’ layout may be the software application's approach for presenting the information of several entities. The application developer may choose to create a specific page for each manipulated entity… a choice which may be correct in some contexts, but which also remains questionable by its repetitive approach.




In another, more automated, approach, the software developer may prepare templates for each entity's specific Master/Detail information, and load the required template according to the context's entity.


This latest approach would be a first step for a meta-modeling approach for entities' presentation.




In fact, storing these templates as part of software objects would make them dependent of their related objects' compiled state. That is: the template cannot evolve without changing and recompiling related objects' code. Storing template's information in a database (meta-model) would circumvent this inconvenience.


In the same time, storing templates' information in a database would also require a (more or less important) change in software object's structure and behavior. Using a database meta-model approach (to describe Master/Detail templates in our case), requires the software object to act in a more abstract way. And this is what we called 'collaborative' approach (between database meta-model and runtime objects).




Finally, in the long run, our software object would constitute a 'kernel object' capable of displaying and handling any entity's Master/Detail information stored in a database meta-model.




What can we do with meta-models?


The sample exposed above can of course be extended to more elaborate models and interactions between descriptions stored in a database and their software objects' counterpart.


Let us again take another practical sample: an application that may need to normalize the appearance of asp.net data grid controls.


We know that a GridView control contains some appearance properties like:


§  Width;


§  HeaderStyle-CssClass;


§  AlternatingRowStyle-BackColor;


§  … etc.




We may choose to use the database to store values for each of these properties and let our software objects assign these values to each DataGrid (on the page's load event for instance).


Now, to handle the appearance of our GridView controls, we just need to assign new values for these properties in the database. A task which requires less effort, less time and fewer technical skills.




Meta-models and Reflection


Reflection is the process of introspection (self-examining) of the internal structures of software objects at runtime. .NET implements Reflection in some classes defined in the System.Reflection namespace.




Our previous exercise can be extended to more abstract and useful applications.


In fact, a software object (like GridView in the last sample) has properties to which we can dynamically assign values if we may simply know their name:





PropertyInfo property = Type.GetProperties().FirstOrDefault(

                            p => string.Compare( p.Name, my_name) == 0);





After locating the property inside the specified object's Type (class) we may assign it a specified value:





property.SetValue( … )





Our meta-model may make use of Reflection mechanisms to store property names and values in the database, to read and assign the specified values to the specified objects at runtime.




This approach may be of interest in many software applications. Its main advantages are, again:


§  More adaptable and versatile software;


§  Reducing development and maintenance efforts, time and cost!




Meta-models and method invocation


What we explained above about using System.Reflection to discover an object's property by name and assign a value to the retrieved property, is also applicable to methods:





MethodInfo method = Type.GetMethods().FirstOrDefault(

                            m => string.Compare( m.Name, my_name) == 0);


method.Invoke( … )





On the other side, user interface’s command elements like Menus, buttons… are often associated with an event handler that represents the entry point for the action of the command.




To explain how a meta-model can be useful in this area, let us take an example of an update button.


An update button collects the user entries into the form fields, checks their integrity and submits them to the server for updating the specified table;


Having the meta-data and business rule constraints for the columns of the entity, this update operation can be handled through one same handler. Or be handled by a dynamically selected handler specific to the context.


So, we know that a data entry form would have an update button. And we may need to assign a specific method as the handler of the Click event for this button.


All these required information elements can be stored into a database meta-model. The meta-model software would then:


§  Read (or otherwise find) the name of the method assigned as handler of the button's action event;


§  Dynamically locate the method in the software (loading the assembly when required);


§  Invoke the method.




Again, this meta-model solution can be applied on different contexts (records submission, web service operations invocation… etc.) and/or on different objects or controls (buttons, menus… etc.).




Interoperability and Integration


The database meta-model approach may also be used in a way similar to what we already use in Interop assemblies (which create links between 'unmanaged / native' code end 'managed code').


A meta-model-aware assembly method may, for instance, prepare entries to methods that reside in non-meta-model-aware assemblies or methods.


Such methods can also be defined in different projects independent of the 'meta-model-kernel' assembly. And may, thus, allow a high level integration of existing applications (or data) into the meta-model solution.






As we said above, the meta-model as exposed in this paper, is a collaborative ensemble where the database descriptions are tightly connected to the meta-model kernel software.


Two more questions though:


§  What about the evolution of the meta-model's own kernel?


§  How to describe objects that we don't yet know about?




Here comes another important point which seems to represent a good basis for answering the above questions:


§  An object is represented by a set of properties;


§  A property is, essentially, a definition composed of


·         A Name


·         And an Attribute (the Attribute defines property's constraints: mainly 'Data Type');


§  A Value can be assigned to a property in the context of either a class (static property) or to an instance of this class. (Note: Value should conform to the attribute's constraints).




So we may consider the data of an object as a collection of (Property / Value)… i.e. a collection of ((Name/attribute)/Value).


This seems to be, more or less easily, presented in a meta-model, which may allow us to handle future 'unknown objects' or future unknown 'properties'.




Meta-models self-describing


On one hand, meta-models are data stored in a database… and on the other, they are extensible. Managing them can also be described by meta-models. This recursive aspect can be of interest to some applications to allow users to autonomously manage software semantic behaviors without the need of extensive technical knowledge.