Controls not readonly when bound to a businessbindingsource


Author
Message
Rav
Rav
StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)
Group: Forum Members
Posts: 10, Visits: 20
I'm testing out strataframe and so far it's working well.  I'm using a janus grid for navigational purposes.  Users select a record from the grid and details for that record are displayed in some textboxes.  The grid is bound to a businessbindingsource.  So far so good, here are my questions:

1.  I've discovered that if the textboxes are bound to the bo, the grid is not syncronized with the textboxes.  If I select a record on the grid, the textboxes do not reflect this change.  To fix this, I bound the textboxes to the businessbindingsource as well.  This solved the problem.  Is there an advantage to binding textboxes (and other controls) directly to the bo instead of the bindingsource?  I'd prefer to bind all my controls to the binding source since I use many 3rd party controls.

2.  Now that I've bound the textboxes to a businessbindingsource, they are not readonly.  When bound to the bo, they are readonly until the edit button is pressed.  How can I get the same behaviour when binding to the businessbindingsource.

3.  If I decide not to use edit button (and have the controls editable without users having to click the edit button), I would like the save and undo buttons to become enabled as soon as the user starts making changes (eg. user presses a key in a textbox).  First I tried using the textChanged event to set businessobject.edit.  This didn't work because the event is fired whenever the textbox is populated.What is the best way to accomplish this behaviour?

Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
All of your 3 points really come down to one anwser.  The logic that enables and disables fields based on their editing state is actually in the controls rather than the BO.  StrataFrame comes with an interface called IBusinessBindable which is the interface that provides native data binding.  This interface also has the method hooks that provide the enabled and disabled status of the controls based on the state of the BO.  So you would have to do one of two things:

  1. You could create a custom grid text box that implements the IBusinessBindable interface and add your enabled and disabled logic.
  2. You could simply use the raised events on the BO to enabled or disabled the fields within the grid.  For example, you could manage the EditingStateChanged event of the BO and set the fields accordingly.

Rav
Rav
StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)
Group: Forum Members
Posts: 10, Visits: 20
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...Crying

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.

Attachments
example.zip (92 views, 335.00 KB)
StrataFrame Team
S
StrataFrame Developer (4.2K reputation)StrataFrame Developer (4.2K reputation)StrataFrame Developer (4.2K reputation)StrataFrame Developer (4.2K reputation)StrataFrame Developer (4.2K reputation)StrataFrame Developer (4.2K reputation)StrataFrame Developer (4.2K reputation)StrataFrame Developer (4.2K reputation)StrataFrame Developer (4.2K reputation)
Group: StrataFrame Developers
Posts: 3K, Visits: 2.5K
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.

Rav
Rav
StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)
Group: Forum Members
Posts: 10, Visits: 20
Ben Chase (04/17/2007)
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.

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.

Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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.

Rav
Rav
StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)
Group: Forum Members
Posts: 10, Visits: 20
Thank you, I will do this.  I was just checking to see if there was another "recommended" way, but this will work fine.
Rav
Rav
StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)
Group: Forum Members
Posts: 10, Visits: 20
Trent L. Taylor (04/18/2007)
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.

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?

Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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? 

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. 

Rav
Rav
StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)StrataFrame Beginner (10 reputation)
Group: Forum Members
Posts: 10, Visits: 20
Trent L. Taylor (04/18/2007)
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? 

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 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.

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search