I need to allow the end user to delete several specific records from a table using a maintenance form toolstrip before any of those deletions are propagated back to the database.  Then when they click the Save button, I need all of the deletions to be sent to the database all at once.

I set the maintenance form toolstrip property named AllowMultipleModifiedRecords to True and I made sure the business object's property named IncludeInFormDelete was set to True.  Unfortunately each deletion is propagated to the database as soon as the user clicks the Delete button and confirms that they want to delete the record.

I stepped through the StrataFrame code and I have found that the problem is in the cmdDelete_Click subroutine in the maintenanceformtoolstrip.vb file.  That method checks the business object's EditingState and only sets llRemoveAtServer to False if the EditingState is not Idle.  I do not understand why the editing state is being tested at all.

Is this another bug?  Is there a simple workaround?

Sam Tenney

Has this post been overlooked?  Perhaps I have not explained the problem sufficiently?

Sam Tenney

You're right, there is no reason to check for the idle state there. I'm suprised this hasn't been caught before but, regardless, we've made the change and it will be in the next build.

In the mean time, feel free to make the same change to your local strataframe source code so it doesn't hold up your development.  Here is the cmdDelete_Click handler within the MaintenanceFormToolStrip after the change has been made:

 

Private Sub cmdDelete_Click(ByVal sender As Object, ByVal e As System.EventArgs) Handles cmdDelete.Click
    '-- Establish Locals
    Dim loBO As BusinessLayer
    Dim llRemoveAtServer As Boolean = True

    '-- Cycle through the business objects on the delete and see if they are idle
    For Each loBO In Me.ParentForm.BusinessObjects
        If loBO.IncludeInFormDelete Then
            '-- Modified on 1/20/2011 --
            '-- Removed the requirement that the editing state not be idle in order to mark the row as deleted (rather than immediately deleting the record)
            '---------------------------
            If _AllowMultipleModifedRecords Then
                llRemoveAtServer = False
            End If
        End If
    Next

    '-- Treat the delete differently if more than a single record can be added at
    '-- a time.  If more than a single record can be modified, then the delete
    '-- should not be committed back to the server until the Save or Undo is called.
    Me.ParentForm.Delete(Not llRemoveAtServer, True)
End Sub

Sam,

I got an e-mail notification from you with no content. Was there something else you needed here?

Thanks,

Dustin

Hi Dustin,

Sorry about the empty email.  I intended to point out several other problems with that subroutine, but I accidently sent it before describing the problems.  Now I don't have sufficient time today to fully explain the problems, but I can quickly mention that scanning through all business objects without checking the forms property named "IncludeInFormDeleteType" seems wrong to me.  Perhaps the form's subroutine named "GetListOfDeleteBOs" could be used to limit the scanning of uninvolved business objects.  Actually we could probably replace all the code in the cmdDelete_Click subroutine with the following code because "_AllowMultipleModifiedRecords" is associated with the maintenance form toolstrip and is not affected by any business object.  Here is the entire code (it is just an untested idea from a beginner):

Me.ParentForm.Delete(_AllowMultipleModifiedRecords)

I can provide a detailed argument and analysis tomorrow if you are interested.

Sam Tenney

Oops,

I meant:

Me.ParentForm.Delete(_AllowMultipleModifiedRecords, True)

Sam Tenney

Speed kills .  I'm actually going to pull Trent in and make sure I'm not missing the boat on why they checked the idle state on that function.  When they wrote it they went through the extra trouble of checking the idle state there, I want to be sure they weren't accounting for some scenario I'm just not thinking of.

Regardless, feel free to change your local source to the single line. It will be a bit more efficient than the loop and, as you pointed out, now that we aren't checking the idle state there the loop isn't needed.

If they point out something we weren't thinking of, I'll let you know. Otherwise, we'll likely change this function to the single line execution to match the rest of the Adds/Edits/etc.