FreeTextBox

Hi!,
This is my problem, loosing content on post-back, the first time the page is loaded all is OK, but on submit button content is empty ...mmm, what can I do?

The problem is:

freetextbox need a mouseclick somewhere to copy the content from design to html

if u try to click around the window before doin a postback, you notice that all work correctly
the same if u write the text directly into the html mode

i've tryed many solutions, but the problem seems to be that the postback javasciript function is called before saving text from design to html

so, or u call the function to save html before the postback or u add a simple confirm("save?") on the botton u use for the postback... and all works

I have the same issue.  My problem is manifesting itself when I have other controls on the page and the end user clicks quickly on one of those other controls whcih causes a post back before the control is loaded.

What is the fix for this?

We're seeing the same issue. The only way we where able to work around this issue is to test the text returned and compare to what was sent out. If it is empty or just contains what is equal to an uninitialized FTB's HTML, then we are going back to what was sent out to the FTB instead of what was returned through the post-back.

RichTextBox and other controls that I know is more robust against this mal-function, and if anybody has a better solution, I would be more than happy to know it.

Best Regards
Christian "Bargib" Koerner

Here's the basics on FreeTextBox and what might be causing the problem.

FreeTextBox uses an IFRAME for the editing area and a TEXTAREA for the HTML. The IFRAME is not an HTML input control, so anything inside it is not sent on a postback. Since a TEXTAREA is an HTML control, whatever is inside it will be sent on postback.

FreeTextBox copies the HTML in the IFRAME over to the TEXTAREA when the FORM is submitted by subscribing the the FORM's onsubmit event. Usually this works great, but some .NET controls fire postback's without the going through the FORM's onsubmit event and this is where the problem is occuring. The other problem that can occur is that the IFRAME may not yet be initialized with the HTML and the empty IFRAME can get copied back to the TEXTAREA if it's not yet ready.

That sums up the problem(s), but doesn't give a solution. I'll do some more investigation into the issue and see if we can come up with some more work arounds for these kinds of issues.

Thanks for bringing them up. We had hoped to have a release this week, but we'll try to work this in even if it means a slight delay.

JD

---

John Dyer
freetextbox.com

Hi John,
I have been trying to track this error down for the DotNetNuke Core of and on for a few days now thinking it was in our forums.  It's very intermittent so was kind of hard to troubleshoot.

I manged to track it back to FTB and was looking for a way to correct when I thought I should come over and see if anyone else was having the issue.

Anyway, I have found that if the client takes a little while to load, like if all the images have to be downloaded or the server is really slow that someone can start typing in the editor and it prevents the onblur event from being added which in turn never fires the CopyHTMLToIFrame.

I'm thinking some kind of document.readyState needs to be added before adding the events, but hopefuly you have a better idea.

I'll keep playing with it in the mean-time.

Thanks for a great editor!

My workaround to this issue is, that an empty, initialized FTB returns different HTML than an uninitialized.

So how can one use that? If the HTML returned is unitilized, I know I have to reuse the exisisting content, and not what has been provided through the FTB. E.g. I recreate the HTML from the box as it was before the trip around the users browser.

The errror is MUCH more likely to happen as the number of FTB's increase on one page. With 40 FTB's it happens quite often.

I'm not only having a problem with FTB losing it's content on Post-back, it also freezes the buttons.

Wim

wimthepimscake wrote:

I'm not only having a problem with FTB losing it's content on Post-back, it also freezes the buttons. Wim

I have set visible to false and on postback visible= true, and then it says
"HtmlTextBox has not been correctly installed"

Hi

I am also experiencing this problem where I have multiple boxes on one page. Is this something that is likely to be addressed? Seems like a pretty serious bug to me

 

 

same problem .. it happens on a form with drop down boxes and multiple select boxes .. and it only happens on certain records within my database.

more likely to occur on a complex table based page

the occurance rate on our application is approx  1 in 20 pages

all content lost after postback

On the problem pages the control does not load properly, the html edit is locked, you cannot edit in html mode .. it looks ok in regular mode ,so the user thinks all is ok.. presses submit and it is gone

same problems reported with ie and firefox

i think it is related to the data and the loading of the data into the control .. the problem records will never save no matter how many times you repeat.

Our solution is the following:

On postback, we test if the length of the returned HTML. If the returned length is lower than 20 AND if there was content send out to the FTB. Then we test for the following MultiLine RegEx:
(?<!(.|\r\n))\r\n(?!(.|\r\n))|(?<!(.|\n))\n(?!(.|\n))

As far as I recall, the FTB that has lost content returns a <NewLine> and <CR>, but no HTML. If the user returns an initilized FTB, then there is HTML in it - as far as I remember just "<p></p>".

In this way, if we test for return of Carriage Return, and we did send out content, we know we should return to the previous content for that FTB.

This works pretty well in our solution, where many thousand people update through FTB many, many thousand times a day. I think we currently "recreate" around 200-300 times day. So it still only happens like once in a thousand edits, but then for many FTB's on that page.

Hope this can help somebody! :o)

Cheers
Christian "Bargib" Koerner

I too had a problem with losing content on Postback.  For some reason I did not have the problem on my local machine but only with my server site.  My solution to the problem was to set up a hidden text box to store the contents of my FreeTextBox.  I created a procedure for the ProcessText event in which I moved the contents of the FreeTextBox to my hidden text box.  Then on the PostBack I moved the contents of the hidden textbox back to my FreeTextBox.  So far it is working for me.  The ProcessTest event occurs before the Postback which is why it seems to work.

I have to take back my previous comment about fixing the postback problem as I have encountered lost text again although it only happens rarely now.  In any event, until this problem is fixed, FreeTextBox is not ready for primetime.  This bug is a show stopper.

Any update on this issue? I have had to turn off the FTB in my forums and use a basic text based editor instead. It is frustrating as all of my users have to hand code any text formatting in HTML if they want to control display formatting. At the same time, it's better than typing up a long post and having it disappear on submission. 

Out of curiosity, has anyone seen this happen outside of DNN? I am running into this problem in DNN and I see that a number of the posts in this thread directly reference DNN integration. Any updates would be greatly appreciated.