When a user hits the save button the content saves however when the editor reloads it loads up the content that was present before the user made any changes to it. This makes it look like all the users changes were just deleted. If you simply refresh the page the correct content is displayed. However if the user does not realize this they may waste time redoing their work several times until it's displayed correctly or they give up.

 

This is not a 100% chance. I rarely experience it on my computer while other clients have reported as low as a 10% successful save rate. Meaning it's erroring out for them 90% of the time. As you can imagine this is unacceptable to our clients and to us.

 

I am unable to reproduce in your demo however I am also unable to reproduce in my environment.  I have seen others reproduce it however and we are getting more reports than we would like. You should be able to reproduce it here.

 

This is the first time in the past year we have seen this problem and we haven't changed anything where we are seeing these problems since July 18th.  Any help or advice would be greatly appreciated.

 

We are investigating this issue and will get back to you as soon as possible. At the same time, ken will create an example for testing and send it to you.

Update for this issue. It seems  that the isPostBack is returning false which is causing the html content to not be saved. If you refresh the page it tries to do the save again and sometimes will save. So far the most reliable work around has been to switch from the normal view to the HTML view and then save.

 

 Above is a simplified version of the serverside code. So the html content that is being edited is stored inside a var cm_htmlcontent. The only time we pull from that is "if (this.IsPostBack)" When the problem occurs it seems to be skilling the "if (this.IsPostBack)" segment and going straight to the else segment which pulls the htmlContent that was last saved and ends by putting that original htmlContent back on screen effectively erasing any changes made by the user.

So I implemented the potential fix that was mentioned  in this thread about intercepting the save button  and running my own logic.

 

http://cutesoft.net/forums/thread/67839.aspx

 

What I'm curious about is that since I started  intercepting the save button the time it takes to save has been drastically reduced to a fraction of the time it used to take to save.  I'm essentially doing the exact same thing, so I'm wondering, what am I missing  out on by not using your save method? Is there  any type of validation that you guys do on your end that I  might want to  implement on my end now?

Processing the data in Page_Load event sometimes may cause the problem because form data may not sync to the controls. I suggest you use Page.LoadComplete event.

 

The LoadComplete event occurs after all postback data and view-state data is loaded into the page and after the OnLoad method has been called for all controls on the page.

 

Keep me posted 

What about my second question though? I've switched over to intercepting the save command and saving using my own logic. What is the down side to doing this? Was there anything the Cute Editor was doing during the save that I wouldn't have now that I'm using  my own logic?

 

The original problem is 'fixed' by not using  your save, I'm just wondering if there are any downsides to this fix.

Hi,

 

I guess some thing try to redirect the page for some reason.

 

If so ,  the POST will change to GET

 

Maybe you can always set a label's text in Page_Load for debugging :

 

label1.Text=this.IsPostBack.ToString()+":"+Request.HttpMethod;

 

if you do a post , but the HttpMethod is GET , that means a server unknown redirect occurs.

 

Regards,
Terry