Unexpected behavior


Author
Message
Sam Tenney
Sam Tenney
StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)
Group: StrataFrame Users
Posts: 70, Visits: 3.5K
I am seeing some unexpected and inconsistent behavior that I will try to explain.  First let me explain what I think should be happening and then I will explain what is happening.  Hopefully someone will agree with me and we can get a very minor improvement made in the StrataFrame Application Framework.

On a simple maintenance form with controls bound to a simple properly configured business object, if there are no visible records in the local data table (business object), I would expect all the bound controls to be automatically disabled when the business object is in the idle state because there is no data to bind the controls to.  That is exactly how the StrataFrame framework behaves when using the default mode which requires clicking the Edit button on the toolstrip to enable editing.

However on the same maintenance form and using the same business object if I change just 3 properties to enable automatic editing so that the user does not need to click the Edit button to begin editing, the behavior is unexpected and inconsistent with the default mode described first.  In my opinion if there are no visible records in the local data table (business object), all the bound controls should automatically be disabled because there is no data to bind the controls to.  The behavior should be the same whether using the default mode requiring clicking the Edit button to edit records or using the automatic editing mode.  No records means no data to bind the controls to, so the controls should be disabled until a new record is added etc.

The only properties that need changing to switch from default editing mode to automatic editing mode are setting the toolstrip property named AutoManageIsDirtyChangedEvent to True and the business object property named ManageUIReadOnlyState to False.  And then I always remove the Edit button from the toolstrip when choosing to use automatic edit mode.

The undesired symptom when using the automatic edit mode is that controls are enabled even though they are not bound to any actual data because there are no visible records.  Entering data into those incorrectly enabled controls does not actually change any records but it is very confusing to the end user to be able to enter data but not be able to save it.

A simple "OrElse (Not DataPresent)" added at the end of the If statement at line 3404 in the businesslayer.vb file would probably solve the problem.  I don't think I can override that method, so I do not know of any way I can solve the problem myself.  This is really just a simple question of whether or not controls should be enabled when they have no data to bind them to.

Sam Tenney
Ivan George Borges
Ivan George Borges
Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)
Group: StrataFrame MVPs
Posts: 1.9K, Visits: 21K
Hi Sam.

Try this:

Set all your bound controls Enabled property to False at design time.

Then, for your BO EditingStateChanged event, insert the following code:

    Private Sub YourBO_EditingStateChanged( _
                ByVal e As MicroFour.StrataFrame.Business.EditingStateChangedEventArgs) _
                Handles YourBO.EditingStateChanged
        For Each Item As MicroFour.StrataFrame.UI.Windows.Forms.IBusinessBindable In Me.YourBO.BoundControls
            If Me.YourBO.Count = 0 Then
                CType(Item, System.Windows.Forms.Control).Enabled = False
            Else
                CType(Item, System.Windows.Forms.Control).Enabled = True
            End If
        Next
    End Sub


I guess you open your forms with an empty BO and then let the user Add or BrowseDialog it to a record. So, when they first enter your form, the controls will be disabled and they won't be able to type anything on them unless they click Add. Or, they will go to the BD and pick a record, and hopefully it will work as you want.
Sam Tenney
Sam Tenney
StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)StrataFrame Novice (102 reputation)
Group: StrataFrame Users
Posts: 70, Visits: 3.5K
Hi Ivan,

Thanks for the code.  Do you know if it will interfere with readonly security on specific fields?  I have not purchased RBS yet but I hope this code does not defeat security.

I still would like to request the simpler code change I suggested as a permanent improvement to the framework.  I believe it would work correctly and would not require adding your code whenever developers want to use automatic editing mode.

I appreciate the help you always provide.

Sam Tenney
Ivan George Borges
Ivan George Borges
Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)Strategic Support Team Member (3.5K reputation)
Group: StrataFrame MVPs
Posts: 1.9K, Visits: 21K
Nope, this is basically only Enabling/Disabling the controls, so the readonly should be fine.

I will pass your suggestion ahead. Meanwhile, remmember that if you plan to have all your forms behaving this way, make sure you have a Base Form and add this logic into it. Even if you will have a mix of forms behaving like this and not, you can add a property to your base form which can be set at design time and test on this property whether you want this behavior or not.

By the way, RBS is a must. I can't believe the ammount of time I saved with it and the professional look it gave to my applications.

You are most welcome, Sam. Cool
Edited 14 Years Ago by Ivan George Borges
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