Andrus,

Sorry, I have been out of the country on business for a week, with no time to do any extra forum surfing. Have you found a suitable methodology for handling this problem?

I'm not sure if the solution you posted below is the way you want to go, but if you've implemented it and it's working for you, then maybe I'm wrong.

A possible problem that I see is that you need to add this in all your toolbar button/menu item click events? (or maybe it can be done in a sub-class). Second, now you've tightly coupled the click events to other controls on your form ... that may be no big deal for you, but it's less than ideal. And thirdly, what you really need to do is to be able to call the Validate() event for the last ActiveControl on your Form, not an EndEdit(). I'm just not sure that this will work. Have you tried my ForceBind() methodology at all?

~~Bonnie


>Bonnie,
>
>thank you. What do you think about the following a much simpler approach:
>
>In the click event for toolbar button and menu item, add a Validate() statement.
>It will save any unfinished stuff in the control. Then do an
>EndEdit() to push the data from the controls down into the data source.
>
>After that I can safely update the data source.
>
>
>
>>Excellent questions, Andrus.
>>
>>>1. This should be common WinForms issue. Where to find generic code and documentation about this ?
>>
>>Yes, it is a common issue (keep in mind that it only occurs when the ActiveControl never loses focus, such as a click on ToolBar button or MenuItem), but I don't know where there's anything documented on it. We discovered this behavior many years ago and whether it's been addressed in .NET 2.0 or not, I don't know. I *do* remember finding a property yesterday (as I was looking for the code to get the DataSource, BindingMember and BindingProperty from the Bindings collection) that enabled you to specify at what point the value in the control would be forced into it's databound control. Unfortunately, I can't remember what the Property was, what class it was in or what the enum values were ... I've tried looking for it again with no luck. I'm kicking myself for not making a note of it at the time. =(
>>
>>>2. What do you think using other methods like:
>>>
>>>2.1 Create new dummy textbox, set focus to it, then remove this control.
>>>2.2 use SendKeys('{Tab}') to swith focus to next control
>>>2.3 Create dummy form, activate this and after that delete this dummy form.
>>
>>Those are all too kludgy, IMHO, and I don't think they'd work. Having some built-in functionality to handle this in all your sub-classed controls makes much more sense.
>>
>>>3. Will this code work with checkbox control ?
>>
>>Sure, except your bound property would be "Checked" instead of "Text". Plus, the code is much simpler since you can leave out the code for calling the ParseHandler().
>>
>>>4. Should I subclass all data-bound Winforms controls which I use and add ForceBind() method to all of them?
>>
>>Yes. You should make it a habit to always start with a sub-class of these controls anyway. First thing I did when I began working with .NET in 2002 was to sub-class everything (well, ok ... not *everything* ... but all the common controls that I was using on my forms). Some of my sub-classes had nothing in them, until I found some bizarre behavior that didn't quite work right (I started with 1.0, which was often quite buggy) and I could add stuff into my sub-classes to take care of it without having to change anything on my existing forms and usercontrols.
>>
>>>5. Why you check for Tag property: case "Tag" ?
>>>In which case it is reasonable to bound data to control Tag property ?
>>
>>Well, it's one of the properties that you *could* bind a TextBox to, so I didn't want to assume that all developers would only bind a TextBox to the "Text" property. I can't think of any reason off the top of my head, but you never know. <g> The same with something like the CheckBox control ... for the most part, you'd be binding it to the "Checked" property, but my sub-class also checks the "Text" and "Tag", just in case.
>>
>>>6. Will your code work if controls are bound to other objects, not to datasets ?
>>
>>Good question. Short answer ... no. It won't work as is. You'd have to find other ways to accomplish this in this case. Maybe someone else has some ideas about this. I've spent a good couple hours messing with this prior to posting this reply and don't have time to do much more. I'm thinking that the property that I mentioned in my answer to your #1 question might be of help here ... I only wish I could remember what and where it was. =(
>>
>>~~Bonnie