Winforms (VS2005) DataGridViewComboBoxColumn, CTRL+0 and Cannot set Column 'myColumnName' to be null. Please use DBNull instead.

Hello,

I recently had some trouble with setting a dataGridViewComboboxColumn to a dbNull value with the CTRL+0 (zero) keystroke. As you may know, the datagrid supports the CTRL+0 keycode to force a dbNull value into cell and subsequentialy into the bound datasource (a datatable in my case). In other words you can use that to clear out a combo box's value and set it back to "nothing". At least when the bound datatable column allows DbNull to be true.

This is where I experienced some strange behaviour. I used a datagridView to display some customer data. One of the fields specifies an optional characteristic , namely the qualification of a customer. At database level this is enforced with a referential integrity constraint in the form of foreign key specification with a look-up table. The primary key of this look-up table is an integer. Of course in the datagrid , on the comboxbox showing the customer qualification , you will see a description (cfr. valuemember versus DisplayMember).

This is where it goes wrong. When I try to clear an existing value in the combobox , I get the following error message. Cannot set Column '' to be null. Please use DBNull instead.

What is even more strange is that when you have a combobox in the datagridview where the valueMember's type is System.String, You will not have this exception. It just works. It is also only apparent with a datagridViewComboxBoxColumn. Because if I would use a
DataGridViewTextBoxColumn for the "integer" case, I would neither experince any problem with CTRL+0.

I looked for a solution on Google and I stumbled on this post . Somewhere on the middle you will see an entry by Mark Rideout , DataGridView Program Manager Microsoft (27 Jan 2006, 3:34 PM ) . ...And he talks about a bug. But more interssenting for me he also hints a possible work-around.

He talks about overriding the DataGridView.ProcessDataGridViewKey Method . This method calls the key-processing method appropriate to the key pressed. In this method you could check for the CTRL+0 keystroke (D0) . That is exactly what I immediately tried out. I made a custom DataGridView (i.e. I created a class inheriting from the System.Windows.Forms.DataGridView and overrided the ProcessDataGridViewKey(see MSDN) . In this method I check for the CTRL+0 keystroke and some other characteristics . And if everything is true, I programmatically set the value for the currentcell to system.DbNull.Value.

Public Class CustomDataGridView : Inherits System.Windows.Forms.DataGridView


    Protected Overrides Function ProcessDataGridViewKey(ByVal e As System.Windows.Forms.KeyEventArgs) As Boolean

        If (e.KeyCode = Keys.D0 or  e.KeyCode = keys.NumPad0) _
            AndAlso TypeOf MyBase.Columns(MyBase.CurrentCell.ColumnIndex) Is _
              System.Windows.Forms.DataGridViewComboBoxColumn _
            AndAlso MyBase.Columns(MyBase.CurrentCell.ColumnIndex).ValueType IsNot _
              GetType(System.String) Then
            MyBase.CurrentCell.Value = System.DBNull.Value
            Return True
        Else
            Return MyBase.ProcessDataGridViewKey(e)
        End If


    End Function
End Class

And guess what? It works (at least for me)! I also tried it in VS2008. There the same error is thrown ( I gues the bug report got lost somewhere ). But the same trick with ProcessDataGridViewKey works in VS2008.

I haven't tried it yet on other dataTypes like guid's and so. That why i check for datatypes in the code. But for my situation, this solution is OK .

Maybe there is another solution? If you know of one, don't hesitate to let me know...

Meanwhile if you like, you can download my test-program.

Thanks for reading.

Best regards,

Alexander

Design for testability - developer testing context

Hello,

Some more thoughts on design for testatbility in the developer testing context (see previous post ).

Test automation plays an important role in the developer testing context. The advent of the xUnit testing concept , nUnit and the integration of xUnit concept in Visual Studio, has put developer testing more in focus.
The test case is a description that tells us how we can see whether to system has done something as we expected it do that something.
Before executing a test , we must put the put the system in state so our test can actually operate. For example before testing the deletion of an order in our order system, the system must contain an order that we know of. For example a order record in a database.
The act of deleting an order necessitates that we can say to the system that we want to delete that explicit order . So not only to we need control of the initial situation, but we also need control of specifying the input and controlling the place where the order is physically kept (i.e. our test database with Order record with ID ORD1)
After executing the functionality, we must be able to verify if the system has actually done its piece of work. We must “see” the result of its processing. We need to compare this outcome with our initial expectations. A discrepancy can mean either the behaviour of the system was not correct or test case was not correct in terms of initial situation , the actions we took or the expected results.

An automated test (case) in xUnit terms can be viewed as follows (freely adapted on drawings found on http://xunitpatterns.com/ (Gerard Meszaros)).











Automated means that important steps in the execution of a test are preformed “automatically” . In other words exercising a test case on a unit (a method ) involves programmatically

• supplying the initial situation (setup)
• doing the actions (execute)
• comparing the actual results with expected values (assert)
• Cleaning up (teardown) so the next test case can proceed in a clean situation.

So how can we improve the testability in a developer context. On which aspects of the code can we influence the ease of performing developer test and facilitate the localisation of defects.

• Control : In order make automation possible we need to be control of the initial situation as of the all the input that a method needs, so we can steer the processing of the unit in such a way it will produce the outcome we expect.
• Observation : In order to compare actual and expected results , we must be able to observe what the outcome of the processing of a unit is.
• Complexity: Network integration, database integration, Message queuing, Security , Registry, Windows services, COM+ , …. Makes it difficult to set up a test environment.
  Large methods with complex conditional flow necessitates many test case in order to get desired test coverage.
  Inheritance : abstract base class can not be instantiated.
  Large inheritance tree : may test cases to see if combination of base and specialized code works as expected.
• Isolation: Ability to isolate certain dependencies and replacing them with test-doubles improves testability because we control what the test-doubles will do. That way we can concentrate on the logic in the CUT . The DUT will replaced by a test-double. Any calls from the CUT to the DUT (replaced by the test-double) will result in “controlled answers or behaviour”. Hence our test case for the CUT will be easier to setup
• Separation of concerns : The class with a clear responsibility should improve testability in terms of knowing what to test in the first place.
  Smaller things to test
• Heterogenity : Single language or language framework improves testability

If you have remarks or other thoughts, don't hesitate to drop a comment.

Best regards,

Alexander

Design for Testability

Hello,

I have been reading up on "design for testability" because some of the code I deal with is not always easy to test. Some thoughts ....

Context

“Business” wants software application to help them do their job. They use them because they bring “value” to them. In order to make that happen software application must do what they are required to do (fit for purpose) and must be “reliable”.

Through a mixture of process guidance, technology and human skills, to use the previous to elements efficiently and effectively, IT tries to deliver those application on time while adhering to the intrinsic quality attributes like for example reliability. Quality processes are put in place to ensure achievement. In order to assess the if the quality attributes are indeed incorporated into the software product, we need to check it. This is where testing comes in. Testing should give us insight into the quality of a system. This insight should help us decide to release the software for usage by the business because it can bring value to the business. Or it can tell us that there are still some discrepancies and we need to improve quality before handing it over to the business.

Testing is some something we must do although it does not immediately raises the quality of the system. It reports only. Many times “business” can not understand why we can’t deliver something right the first time. Testing costs money! Software creation is still an error-prone endeavour for many reasons despite all advancement in processes , technology and skills of people. In other words we start off with the assumption (certainty!) that software contains errors. Both functional and programming wise. Testing is about finding those. So it is important that we make the best possible test cases to reveal them. Use tooling to support our testing effort etc. Bust beside the test process it self , we can do more.

During the inception and construction of software we can introduce measures to make this testing effort even more efficient and effective. In other words we must make our system as “testable” as possible in order to and to facilitate performing the test and finding the errors.

Testability

Testability is about the ease of performing test against your system and ability of the tests to reveal any defects in a certain context. The context of the test , system testing (functional and non-functional) or developer testing, puts different meanings to testability. Also is it important that other software artefacts beside code, affect testability ; for example the requirement specification documents.

These are some aspects that influence the testability :

• Understanding: The better you know what the thing is supposed to do , the better you can test for it.
• Controlling ; You must be able to manipulate the input , in order to verify the correctness of the output.
• Operational : We can only test it when it works !
• Visibility : You can only verify the result , if you can see the output.
• Simplicity : The less there is to test , the more quickly we can test it
• Stability : The fewer the changes to less test if need to re-do and/or re-write
  
  

So manipulating the influencers, can change the testatbility !

It is important to acknowledge that testability does not come on its own. We must take testing into account from the beginning of our software development endeavour. Because we know our software will contain errors (this will only increase with the size and complexity of today’s systems), we must prepare for it to easily test our system and find them before we ship the code.

In other words we must design for testability. It is important because testing costs money. Also faulty software systems can cost the business money (in the best case or worse in case of threat to safety or life) . Therefore we must make the testing as effective and efficient as possible. But Business will benefit from this as well in the long run because we should be able to find defects thus raise the quality of the system, thus raise the value to the business.

Also future changes to the software to incorporate new requirements will benefit from this testability feature because we should be more confident to change working code with regression testing. Also external factors such as SOX compliance make it important for the business to assemble test evidence. Testable systems certainly can aid .

Design For testability

To increase both the ease and value of testing we can tack different areas of the software development process and the software product itself. For example

• The software development methodology (“testable” requirement concept, etc)
• The software technology (Procedural vs. Object-Oriented, Mainframe, etc )
• The software architecture & design (Layered vs. monolithic, Coupling , Encapsulation , etc)
• The code (Assertions , mocks/stubs , etc )
• Tool support (Automation , Xunit framework , etx)
• The developer (Training and education , code reviews , etc)
  
  

This broad spectrum calls for an holistic approach of course. The test context will put certain focus in that approach. For example

• For functional testing you need good test reference in form requirements documents to establish your test cases
• For System testing , you must be able to let system work under operational condition together with data and sometimes external systems.
• For developer testing , you must sometimes be able test your unit in isolation and sometimes you would like to integrate a set of unit together.
  
  

Currently I'm interested in the developer testing context . So if you have experiences in raising the testability of your code and wish to share them , please do so. I would to hear from you how dependency injection help you ( or not) , how unit testing helped you find defects easily , etc.

Best regards,

Alexander

Application taxonomies

A classification of software application can help you to think about an architecture and/or determine a reference architecture in your catalogue.
Multiple characteristics can be used to set up a taxonomy. These taxonomies can help you I think because it sets up a context for making a software architecture and the usage of reference architectures. Usually one classification criterion alone doesn’t fit the entire application . Multiple axes.

I think one of the main message would be : Don’t be fooled that one reference architecture can be used in all scenarios.

• Front-end technology
  o Windows (classic / touch screen)
  o Web-based (classic / Rich Internet client )
• Distribution
  o Desk-top
  o Mobile/PDA
  o Sever
  o Distributed
• Connected
  o On-line
  o Disconnected with on-line capabilities (smart client)
• Communication
  o Asynchronous
  o Synchronous
• Target
  o Consumer ( E-commerce, PDA)
  o Business (Traditional administrative data keeping or/and decision support)
  o Industry (MES, CIM, MRP, SCADA, real-time systems, PLC, Robotics)
  o Government E-government
  o Entertainment (Games)
• Connectivity
  o Internet
  o LAN
  o WAN
  o VPN
• Function
  o OLTP applications
  o Reporting applications ,Data warehouse, BI
  o Batch application
  o Service–oriented apps
  o Mobile device applications
  o Integration Applications ( ERP, Mainframe , etc)
  o Office applications and Office integration
  o Portals
  o System software
• Organisation boundaries
  o Departmental
  o organisation
• Usage pattern
  o Collaboration
  o Transactional, data keeping
  o Decision support
• Time pattern
  o Long running “transactions” (Workflow)
  o Short running business transactions
• Expected life-time
  o Short-term
  o Long term
• Business area
  o Medical
  o Financial
  o Government
  o Industry
  o Commerce
  o Etc
• Saas (Software as a Service ) software.
• Etc.

What do you think?

Best regards,

Alexander

Software architecture decisions

Hello,

I recently had to give a definition of what a software architecture is . Not always that easy because Software Architecture is a much loaded term. If you want some formal definitions what a software architecture is , I recommend reading the information on http://www.sei.cmu.edu/architecture/published_definitions.html#Modern

General tone in these definitions is that you need to make high-level decisions about the system you' re going to build;

• What style are you going to use? What is the structure?
• How is it going to function? How do structural components of the architecture work together?
• How does it meet the needs of all the stakeholders?
  
  

These high-level decisions have a high impact on the application. You can not change them easily if wanted or needed. Unless you’re prepared to put enough resources on the table.

In the bullets below I tried to sum up the different aspects of a software architecture. This list is not intended to be exhaustive.

• Windows front-end or web front-end ( Rich Internet clients)
• Layering, organization of code, separation of concerns,
• Representing “business objects” persisted in a database
• Exposed domain model or using Data transfer Objects / Presentation Model
• DataSets versus classic classes
• Organization of “back-end” logic
• Organization of “Presentation” logic
• Organization of “data-access” logic
• Distribution or not
• Remoting technology
• Authentication, authorization, Audit
• Data binding
• Synchronous / asynchronous
• ORM tools or raw ADO.NET
• Multi-language
• Exception handling versus status code
• Instrumentation /Logging
• Configuration
• Caching
• Database schema fixed or freely adaptable to need of design designs
• Long-running “transactions” (conversations)
• Reporting needs
• Validation rules placement (Attribute based, Intra object based, Inter object based)
• Etc.

It is important to take holistic approach towards the desicions. You will need to take some trade-offs and influencing criteria into account.

• Kind of application built (taxonomy)
• Tooling can constrain how you organize your application (code generators, frameworks, application building blocks, software factories ,etc)
• Availability/knowledge of people can constrain the “feasibility” of your architecture
• Process (top-down versus bottom up, behaviour-centric versus data-centric)
• External / internal regulation can influence your architecture (SOX, internal Audit rules
• Availability of reference architecture.
• Non-functional requirements
• Patterns
• Time-to-Market
• etc.

If I missing some points or you want to comment on this. Please feel free.

Best regards,

Alexander

Comparing to Linq to SQL

Hello,

Recently I took some time to investigate Entity Framework (CTP3) and Linq to SQL (RTM) further. While going through the examples I compiled following list with benefits & concerns. Maybe you have made a list for your own? Maybe you would care to comment. Please do so!

Linq to SQL

Benefits

• Already available in VS2008 RTM
• Generation of partial classes based on the database schema
• Relationship are also detected and modelled as special properties in the entity classes
• You work with these entity classes in you application.
• Generated classes can be augmented with custom methods
• Generated classes can be augmented with partial methods
• LINQ support to specify queries
• Dynamic generation of SQL (you do not have to write SQL your self)
• Databinding support
• Lazy loading (default) and immediate loading flexibility
• Updating only changed columns
• Optimistic Concurrency support through mapping directives.
  

Concerns

• Basis mapping capabilities ( 1 table -> 1 Entity)
• Only SQLServer
• Distributed application requires special attention (dataContext)
• Designer lets you start from a blank model but I haven't found something to create a database schema from the entity model.
• Serialization of entity classes only set if generated with SQLMetal command-line tool option.

Entity Framework

Benefits

• Generation of partial classes based on the database schema
• Designer lets you start from a blank model but I haven't found something to create a database schema from the entity model.
• You work with these entity classes in you application.
• Generated classes can be augmented with custom methods
• LINQ support to specify queries
• Dynamic generation of SQL (you do not have te write SQL your self)
• Databinding support
• Normally foreseen to accommodate multiple database systems
• More flexible mapping capabilities than Linq To SQL (fine-grained entity model, Inheritance mapping flexibility, etc)
• Generated classes by default serializable
• Data driven Object-modelling point of view
• Lazy loading (default) and immediate loading flexibility
  

Concerns

• Promised to be shipped with SP1 VS2008
• Distributed application requires special attention (ObjectContext)
• Designer lets you start from a blank model but I haven't found something to create a database schema from the entity model.
• In the designer you can not add behaviour in the model( somewhat normal because it is a DSL for data persistence but still....). Entity are now more geared towards a data-container role.
• Two flavours to query the databases system (linq to entities and entity SQL). At this moment I'm not very sure when to use which.

So if you have other points of interest or remarks , I would like to hear them.

Thanks in advance.

Best regards,

Alexander

VISUG Event (03 April 2008): WCF - Beyond endpoint - Juval Löwy

WCF : A brave new world


The Belgian Visual Studio User group (VISUG) had invited no one less than Juval Löwy to present a session on WCF Juval is an authority on the subject and is/was? a member of the advisory comitee of WCF. From the summary on the VISUG website (http://www.visug.be/) you could tell that this wasn't going to be your typical WCF 200 type of presentation (or 300 or 400 for that matter).

Juval immediately set the tone of his presentation (or should I say show) by stating that WCF is a better .NET . WCF will deprecate .NET. During the next hour and a half it took the audience the numerous of demo apps to make his point.

WCF is the next development platform according the Juval. He pushed it a little bit further by saying Microsoft is masquerading this "Truth" from us. He mentions the whole marketing message Microsoft put behind the start of the first version of .NET : .Net is the platform to build web services. We all learned in time that there is much more than web services to .NET. This was primarily done to soothe the organisations and companies that just spent tons of money in making their developers COM- savvy and converted their applications to VB6 / C++ ATL/ COM + . Don't worry, people. We have got this new thing here but it is for web services. Don't be alarmed. By the way we have created VB.NET . You already know half. And yes there were migration wizards and .NET - COM interoperability features. In the end .NET was not so easy ...

Comes along WCF: ....It is a new breed of communications infrastructure built around the Web services architecture ... ( MSDN site) Again they stress onto web services (although the term connected systems is more present in the WCF literature on MSDN) . Again to soothe the companies that have invested in their developers to learn ASP.NET web services but also other technologies like Messaging (MSMQ) , .NET remoting, Enterprise services (COM+). Again ...don't be alarm folks, it is only about web services.



Juval has more visionary message to tell regarding WCF. We are standing again on the foothill of a big mountain. We at the brink of a new paradigm shift. A service-orientation, declarative program model we you , if you like, also can create web services. But the granularity of what a service might be is not solely at level of web services. According to Juval the interception mechanism of the WCF run time can be used at every class. WCF everywhere is the nirvana. At least to Juval. I don't know if he really meant that or just wanted to keep us on the edge. I think the message was as your class need certain services (security, reliability, transactions, etc) And WCF can offer them , why need turn your class into a "service" and leave to plumbing to WCF.
To me that was the thing I learned from the presentation. Don't ever write plumbing code yourself, leave it to the experts. Concentrate on the domain logic.

With a few smart examples he showed us the essence of what WCF can give to you . And the sheer power you sometimes get by just changing the config settings or changing an attribute on a class ( or should I say service). Some of things you of course could do with regular .NET but the amount of effort and knowledge you need to have to do so are so big ,that it can be difficult to defend not using the out-of-the-box features of WCF. And don't talk about the testing effort and maintenance effort you have to put into all this plumbing code (your customer hasn't asked you for in the first place. After the session we al received the WCF resource CD from IDesign with lots of demo's.

But the again developers love to know how things work ( so they can share this "wisdom" with the world in for example VISUG event ...or blogs :-) They love make their own stuff. But like Juval said "By giving a VB programmer the ability the use over the threading library is like giving a child a hand full of blades. They will bleed to dead. " But he immediately added "C++ don't always do it better. They are only more used to seeing blood."

Sometimes we act more as "Google-programmers" . We (me included) look something up . Bend it and shape it a little so it works for us; Put the name of the original author on it and carry on. Sometimes not really really understanding what is going on under the hood. Disasters lurk around the corner.

WCF takes responsibility for all that hard plumbing code . You never should create it on your own (except if you are the plumber). In WCF you actually don't see any plumbing code. All its powers get unleashed by configuration and attributes. Will not writing the infrastructure code yourself doesn't mean you don't need to understand conceptually what is going own or what the annotations are for. In fact Juval mentions that we need to think about the design more than ever but we do not necessarly write it our selves (as application programmer) . The paradigm shift maybe needs a somewhat different approach to the design process and the way we need to structure our applications.

This is the foothill Juval is talking about. Of course he can offer that guidance :-) He wrote a book on the subject (Programming WCF Services) and gives master classes on the WCF and Service Orientation in his own company IDesign .

So enter this brave new world of service orientation. It may like a class but offers so much more . A whole application of services , all running in their own "process" giving you a lot of infrastruture functionality right out of the box.

Still I have some concerns.

• Focus on your own domain code. Leave plumbing to someone else. We heard that one several occasions and other (non-Microsoft) technologies before. In fact in 1996 when Microsoft transaction Server was released as part of option pack for NT4, you already had that notion of interception. In COM+ additional "services" were made available to "objects" hosted in the COM+ space. What is different now? Yes of cours WCF can do lots more. But still COM has been deprecated. (Has it? Office is still COM isn't it ?) and .NET came along. Now WCF is there.
• Companies have invested lots of money in applications running on previous . Programmers have invested time in learning these technologies. Now we have to learn something new again ! Of course in each branch there is a progressing insight how things work and how problems can be solved. Our business the pace is somewhat quicker. If you come to think about it .NET started somewhere in 2001-2002. Time for something new thus . Maybe this is another reason not (as a application developer) get too deep into the nitty-gritty details of something although I must admit... I too like to know how things work). We should concentrate on acquiring domain knowledge or the skill to translate requirements to the platform . So actually the abstraction gap between the real world needs we translate into an information system and the actual code bits gets pushed from both side of the gap. On the one hand coding it becomes more clear, no nuisance of infrastructure code. On the other the whole model-driven movement is trying to find a way to abstract the requirements in such a way "machinery" can kick in to produce the (part) of the code. I think both efforts will find its way to each other. ( Entity Framework, Web Service Factory Modelling edition, Volta, Oslo) . I wonder how this all stand against "agile development"? Are these opposites?
• Technology is one thing. Process (design , methodology) and people are other big variables in the equation. Or maybe synergy is a better word. How will WCF affect our design process. What skills do I need to learn understand WCF and correctly apply WCF. How to do I architect my apps?
• Besides development there is also the operations side. How will this be affected?
• Is WCF everywhere actually feasible with the current WCF. Juval made a special in proc factory to ease some of the config burden. Will this be enough to ease configuration (XML hell ) Will it not be too slow?
• Why is an outside expert promoting this vision? Where are the Microsoft Evangelists? Where is Don Box actually?

Best regards,

Alexander