Not related to LLBL... but what the heck?

.Net data binding is good, not great. For example with WinForms, in order to update a field value to the underlying Entity, you have to tab out of the field. Which means that if you change a field entry and then go to a menu option called "Save", then the new value will NOT be saved to the database. I can't believe that the .Net engineers allowed this problem to persist in the production version!

Does anyone have a simple solution to this problem? I've heard about the use of IObserver - - has anyone implemented it?

Thanks! Jeff

I'm not aware of any solution to this. This is mostly due to the fact that winforms controls are based on win32 controls which work asynchronically, however .NET controls work synchronically. Win32 controls are controlled via messages send to them using the win32 SendMessage() method.

This means that the winform gives the focus to the textbox for example and comes into action if the focus has to move away from the textbox by a TAB key or some other event. Only THEN the validation kicks in.

Another way to do validation directly is by acting on every character typed in a textbox. This is very cumbersome but you are able to pick up the situation you want. In any other situation there is no way teh code can know that the user is finished typing.

Hi Frans

I've heard of situations wherein developers skip the data binding process altogether and implement an IObserver object to validate/update the Entity object. Apparently, this would get around the data binding problems (such as the one I've mentioned). However this sounds like a "big fix" for a relatively small problem. It would certainly introduce a new level of complexity and a new "learning-curve" for me. Your opinion?

Thanks. Jeff

Try this when you need to commit information to the datasource when databinding doesn't pick it up:

Me.BindingContext.Item(_boundObject).EndCurrentEdit()

"_boundObject" represents, of course the thing that your databindings are hooked to.

Jeff...

JMichelson wrote:

I've heard of situations wherein developers skip the data binding process altogether and implement an IObserver object to validate/update the Entity object. Apparently, this would get around the data binding problems (such as the one I've mentioned). However this sounds like a "big fix" for a relatively small problem. It would certainly introduce a new level of complexity and a new "learning-curve" for me. Your opinion?

Databinding was introduced in VB6 if I recall correctly, and it wasn't designed very well (it required a database connection directly on the form). So a lot of people, myself included, didn't use it and wrote our own control filling/control reading code. When .NET arrived databinding seemed to be implemented better. However if you didn't use datasets, you were a bit out of luck again.

After fighting with databinding goo for a long time during implementation of the runtime libs, I can safely say: databinding is seriously broken. It does work, sometimes, but for example the behaviour of a set of textboxes on a form is totally wrong: each time you move to another textbox, a NEW edit cycle is started for the bound object but doesn't end the previous!. It thinks (the currency manager) that it should act like a datagrid row (all textboxes together). However that's not the case.

This of course brings serious problems to the table: you have to end all edit cycles by hand for example for a dataset (I have added this code for you, but still...). There are numerous other problems with databinding too. I never use it, only for binding lists to a listbox or for simple gridlike edit forms when I feel lazy (because grids are not very good for editing data). Most of the time I write some code to fill the controls the way I want it (you have to in a lot of occasions anyway OR implement ToString() overloads all over the place) and the way I want the data back on the time I say so.

For the web it can be helpful, for example filling a repeater control with bound data can be set up easier than some loops filling a table structure. However the implementation of webbased controls anddatabinding is even more troublesome in a lot of areas. Like the confusion people have when they postback to a page and the bound object is gone. How to get it back? Where is it?

Databinding can help you with some tedious code, however it is again too 'RAD', which is completely unnecessary. To succesfully utilize databinding you have to dig into currency managers and use your own instead of the one on a form. This brings also a lot of complexity to the table which IMHO is more complex than a couple of loops to fill some combo's

jeffreygg wrote:

Try this when you need to commit information to the datasource when databinding doesn't pick it up:

Me.BindingContext.Item(_boundObject).EndCurrentEdit()

"_boundObject" represents, of course the thing that your databindings are hooked to.

This is one of the things indeed I mentioned, you have to do this for example to make some edit cycle 'end' itself. However for the entity objects you don't need to do this, the current value will be set and changes will be recorded. The problem is that if you start another cycle on the same field it can be problematic.

If you bind a collection to a MS datagrid for example and you edit a cell, the grid calls at random BeginEdit. So you have to check if you're inside a BeginEdit cycle or not, for the row (entity) or cell (field). Also, when the user moves the cursor to another cell (and row) the amount of EndEdit() calls are not matching the amount of BeginEdit() calls! (more). This totally doesn't make any sense. An EndEdit has to match a BeginEdit. And a BeginEdit has to have an EndEdit. It's totally garbage.

Hi there,

It is totally unbeliveble that MS implement a half solution on the same topic - in two generations of the dev tools.

It is absolutely not usable in a professional App - Talking about complexibility - events getting fired all over the place - and the amauont of house keeping required to get it "almost working"

Frans , I belive you have done a good job actually trying to support this for the benefit of your customers - but frankly speaking - you should never allow features for databinding to stop features of no databinding related features.

I will never use databinding for production stuff

IT wrote:

It is totally unbeliveble that MS implement a half solution on the same topic - in two generations of the dev tools.

It's their way of doing things. Every time there is a new vs.net, I see smiling fake-nerds demoing some drag-n-drop 'programming' and think it's what developers want. I mean... who wants to drag a data-adapter on a webform and have sql generated right there inside the webform...

It is absolutely not usable in a professional App - Talking about complexibility - events getting fired all over the place - and the amauont of house keeping required to get it "almost working"

indeed. If you check out the demo-app I wrote, there is more code in there to keep the stuff running related to databinding then there is for managing the data. Still it can be helpful though, if you like grids..

The databinding in whidbey seems to be a lot better with the objectsource object to bind objects (like entities) to a control at design time. Still I doubt if it will work with any custom class... (even if it implements a given interface)

Frans , I belive you have done a good job actually trying to support this for the benefit of your customers - but frankly speaking - you should never allow features for databinding to stop features of no databinding related features.

Oh, don't worry, that won't happen I add databinding features as a plus, not as a must-have. That's also why entity objects do not implement IComponent, because that interface is not useful for a lot of implementations but required if you want to have design time support.

I will never use databinding for production stuff

I don't use it a lot either, just here and there for lists, however it requires a lot of code too sometimes and then a simple for loop is easier. Like the new search form here. The forums you can search in are added to the select box with a forloop, I couldn't get it right to bind to a set of data and combine 2 fields to 1... Ah well... databinding really gets bad when component vendors do not support databinding correctly. (not that MS does it correctly, but it's at least a 'standard' people want to comply with). ComponentOne comes to mind...