Well, I would be curious as to what you have setup in your code here.  For example, since the BO are managed within the session and from page to page, they will be left in exactly the same state from page to page, including the EditingState, unless something in your code either:

1. Changes the editing state by performing an Undo, Save, etc.
2. Automatically adds a new record when the user lands on the page without first testing to see if a record has already been added.

Depending on what you are trying to accomplish and what you code looks like, the editing state could change.  Here is also another little tip that can help with editing states.  If you look at the SF web sample, there is an option that allows you to set the ManageUIReadOnlyState to False enabling all of the controls.  So if you have the need, and depending on your code, you can always manage this manually if you like.  But the SF BOs will not change their states unless something is actually changing them for you.  One other thought here is if you have a session management class outside of SF that is manageing your session objects, this could come into play as well.

Hi,

I have problem as below



Case 1

1. User navigate to my aspx.

2. User click edit button to edit record.

3. Program call BO.Edit().

4. Controls are enabled for editing.

5. User refresh web page.

6. Dialog prompted to ask whether to "retry".

7. Click yes will cause "no edit is allow".



Case 2

1. User navigate to my aspx.

2. User click Add button to Add record.

3. Program call BO.Add().

4. Controls are enabled for Adding.

5. User navigate to other page and back.

6. ASPX back to "idle" mode.

7. If user click add again and save, "rubbish" would be saved as well.



How do you handle this kind of program usually?



Thank you