I am using automatic edit mode on a maintenance form with a maintenance form toolstrip.  On the toolstrip I set the property named "AutoManageIsDirtyChangedEvent" to True and removed the Edit button.  I dropped two business objects on the form and set the property named "ManageUIReadOnlyState" to False on both business objects.  I set all the form's "IncludeInForm...Type" properties to AllBusinessObjects except the "IncludeInFormNavigateType" which I left set to PrimaryBusinessObject because when the primary business object navigates I want to retrieve a single related record from the other businees object which I am handling in the primary business object's navigated event.

I want both business object's EditingState to stay in sync with each other.  Since automatic edit mode does not use an Edit button to determine when a business object should enter the editing state, I am having trouble keeping the EditingState the same for both business objects.  If the user makes any change to any databound control for either business object, I want the EditingState for both business objects to immediately go into the editing state.  When the user clicks the Save button it is possible that only one business object needs to be saved, but after that business object is successfully saved, I want both business objects to go into the idle state.

Where should I put the code to force the unmodified business object into the editing state and then later into the idle state after the modified business object is successfully saved?  I would also appreciate a suggestion for the actual code to do this.

Sam Tenney

Well, that was a lot to follow.  But from the sounds of it, you want the editing state of the BOs to remain the same.  One thing that I do at times is create an event handler for each BO on the for for the IsDirtyChanged event.  This will get fired when any one individual BO gets dirty and then would allow you to update the other BOs.  Let me know if I am not catching something here.  Thanks.

Hi Trent,

I appreciate your suggestion but I think I may need to take a giant step backwards and consider restructuring my database tables.  I feel like I am fighting the framework and that is seldom a good idea.

I was trying to keep two business object's editing states in sync with each other because the two related tables have a one to one logical relationship.  Now I think I need to combine the tables into a single table and start over.  I ran into too many unexpected StrataFrame gotchas so maybe a simpler approach is called for.

Sam Tenney

Just out of curiousity, why are you trying to sync the edit states?  I can't think of a reason why this would be necessary if you are running on a IsDirtyChanged concept instead of an Edit mode concept. 

Hi Trent,

I appreciate your interest and because you asked, here it goes.  The need to keep the BOs synchronized starts with the nature of the two tables.  In FoxPro these tables were separated to keep one of them from unauthorized Windows access to confidential information while the other table contained public information, but the data in these two tables logically belongs in a single table with the security issue being handled by RBS.  Because of this one to one relationship, when a record is added in one table a related record must be added in the other table etc.  So all of  the adding, editing, deleting, saving, and undoing needed to be synchronized.  The IncludeInForm...Type properties allow that sychronization easily.

The gotchas in the framework  that I kept running into mostly related to the visibility of buttons on the MFTS.  The framework handles the visibility of these buttons in a Private (non-overridable) method named HandleEditingStateChanged in the MFTS which gets executed many many times and apparently sometimes without raising the EditingStateChanged event.  When determining the visibility of the New, Edit, and Delete buttons that method checks all the BOs that are involved in the form's Add, Edit, or Delete to see if any one of those BOs is in the idle state.  If so, the related button on the MFTS is made visible.  A specific instance of the problem is when a user begins editing one of the BO's.  Because that BO goes into the editing state but the other remains in the idle state, the New button gets incorrectly enabled by the framework.  Similar problems occur when only one BO is dirty and a Save fails because of a rule violation.  Many permutations of this problem were getting difficult to solve and I finally decided that the framework was not designed to handle this special case one to one type relationship.  It might have been possible if a property existed somewhere indicating this special case was needed but then the HandleEditingStateChanged method would need to be modified which I could not do myself.

So in the end, I think combining these two tables into one and handling the security with the RBS is much easier and safer.

Sam Tenney

Hi Sam,
Yes you are right and will be better off re-designing the table structures.  With the tools in SF and the RBS you will be easily be able to handle the security of your fields in any way you want much easier.  You can even encrypt fields values and save them in the database and the BO field property will decrypt and show the value at will.  Look at the SF help file for field encryption sample.

Edhy Rijo