I think the problem I ran into when doing it that way was that the grid and the texboxes were not synchronized.  The current record on the grid was not the record displayed on the textboxes.  I'll give it another shot.

Rav-



What I would do is go back to how you origianlly had you bindings set up. (Grid to BBS and Textboxes to BO)



Then just handle the rowchanged or Cell Click event of the grid to tell your BO to navigate to another row.



Use the EditingStateChanged and FieldPropertyChanged Eventos of the BO on your form to manage the enabled/disabled state of your buttons







-Jerome

I understand and agree with you.  My only concern is if a user wants to edit only 1 field, he would have to tab out before the save button will be enabled.  You're right, this is turning out more complex than it needs to be.  I will simply handle the keydown event instead of the textchanged event.  I wanted to avoid doing this because if a user right clicked on a textbox and clicked on paste in the context menu, the save button still would not be enabled.  It's an issue i'll have to fix later.

Actually, I think that you may be making life much harder than it needs to be.  We were just trying to give you some ideas based on what you posted.  There are many different reasons developers do different things and we were just trying to accomodate your current question.

Your current problem is that you want the state of the BO to change without tabbing....well, this actually defies how data-binding works in .NET.  The validating event is actually what triggers the binding contexts within .NET to update the bound element.  So in that example you will have to leave the field (or at least attempt to leave the field) before the underlying context is updated and referenced.  The reason for this is efficiency and speed.  If the underlying data is updated with each keystroke, you will hve a very slow performing environment....especially over time and the larger your forms (or bound controls within the environment) become. 

I've implemented this and this takes care of the problem when the form is initially loaded.  However everytime I move to a different record, the textchanged event is fired which sets the the BO to edit state again.

I would think that what i'm trying to implement would be considered very common behaviour.  I'm curious, does everyone using this framework have their users click on edit before allowing the users to edit fields in their maintenance forms?  Instead of me adding all sorts of logic to my presentation layer to accomodate this behaviour, would a much more elegant solution be if I could tell when the BO is populating bound fields and distinguish that from when the user is entering data.  Is there any way I can tell when the BO is starting to populate bound fields and when it is done?  Perhaps another editingstate that allowed us to know when the bound controls were being populated?

Thank you, I will do this.  I was just checking to see if there was another "recommended" way, but this will work fine.

Rav,

You can still use the TextChanged event.  Create a private variable in the form named _FormLoaded for example.  THen set this to False initially.  In the forms Shown (or load) event, set this to True.  In the TextChanged event, only call the edit if this value is set to True.

Ok, i've done this and it is working except for one problem.  When I start typing in a textbox, the save/undo buttons are not enabled unless I tab to (or click on) another control (i.e the textbox loses focus).  I need the save/undo buttons enabled at the very first keystroke, not after I've typed and moved do a different control.  I tried capturing the textchanged event of the textbox and calling BusinessObject1.Edit, but the problem is the textchanged event is fired even when populating the textbox initially, so when my form loads the BO is already in an edit state.

You can add a method to your business object called RaiseEditingStateChanged() and in it, you can call Me.OnEditingStateChanged().  You can then handle the ListChanged event of the BusinessBindingSource and call the business object's RaiseEditingStateChanged() method which will cause the Save/Undo buttons to properly respect the BO as soon as you change one of the textboxes. 

As for why the textboxes are not properly navigating with the business object, I'm not sure.  You can use CType(bbs, ICurrencyManagerProvider).CurrencyManager to get a reference to the CurrencyManager that maintains the Position property to determine the record to which the textboxes are bound.  Check when you move the CurrentRowIndex with the toolstrip buttons, check the Position property value of the CurrencyManager to see if it's changing as well.

Thank you for your response, but I'm having a hard time implementing some very simple behaviour.  I've attached a sample (it uses your strataframeexample db).  Here's what I'm trying to do:

1.  I do not want the user to have to press the edit button in order to edit.  As soon as the user presses any key that modifies values in any of the bound textboxes, I'd like the save and undo buttons on the toolbar to become enabled.  Please see the example of how i'm trying to accomplish this.  It's not working...

2.  In the sample, the navigation buttons on the toolstrip navigate only the textbox that's synchronized to the BO and not the textboxes synchronized to the binding source.

I'm in the process evaluting strataframe for my project and would really appreciate if you could demonstrate in the sample I've provided how to accomplish this.