Hi,
I initialise a single FCKeditor instance in a hidden div via js. A user can flip this to be visible in order to edit the page (kinda cms thing). This works fine so long as the editor is kept in WYSIWYG mode. If the source button is clicked then the FCKeditorAPI object seems to be destroyed (or at least becomes inaccessible) and so I cant get to the edited contents.
In the trouble shooting faq (http://wiki.fckeditor.net/Troubleshooti ... ab9d551417) the suggested solutions involve hiding and showing the containing div a couple of times and turning on design mode and/or using the SwitchEditMode method.
These solutions all use the FCKeditorAPI object which is unavailable to me (the crux of my problem) but the problem occurs under the same conditions. Is this the same issue or am I missing something?
This thread: http://sourceforge.net/forum/message.php?msg_id=3377383 talks about changing the source but that was 2 years ago - i assume the changes are already in 2.4.3?
The problem seems to occur equally in both ie6 and latest ff.
Cheers for any pointers.
Tromm
V 2.4.3
build 15657
Tue, 07/10/2007 - 10:24
#1
RE: Further API object issue
RE: Further API object issue
I make the reference like this:
var editor = FCKeditorAPI.GetInstance('myEditor');
var ammendedHTML = editor.EditorDocument.body.innerHTML;
in the save button's Execute method.
When the editor is in design mode this works fine but when it is in html mode it produces a "editor.EditorDocument has no properties" error on the second line. This occurs only in html mode - when I was storing the reference this would occur even if the editor had been switched to html mode and then back to design mode.
Ho hum - I will post back if i figure it out.
Tromm
RE: Further API object issue
just a note to report my solution.
My mistake was using "editor.EditorDocument.body.innerHTML" while the editor is in source mode rather than using the GetHTML() , GetXHTML() , SetHTML() methods. In source mode it seems that the reference returned by FCKeditorAPI.GetInstance('myEditor'); no longer has the EditorDocument property.
I thought I had got the snippet using innerHTML from the faq but no matter :p
So in short use the Get/SetHTML() methods, dont set and read the innerHTML.
Tromm
RE: Further API object issue
Now the EditorDocument is destroyed when switching to source mode, but previously if you did use its innerHTML it would only seem to work, because in fact you were reading the innerHTML of an object that it isn't on the screen, so you lose all the changes done while in source mode.
The correct way to work is to use the GetXHTML (GetHTML is just an alias for backward compatibility)
RE: Further API object issue
Everything is working nicely in FF now but I have an (obligatry) IE(only tested in ie6) bug. If the editor is in source mode I cant set the contents with SetHTML (works fine in design mode).
I'll keep looking and reply to myself if i find something - is that bad form?
RE: Further API object issue
OK issue resolved - I should have held off my last post but Im not usually this efficient :p
IE's js console gives this error: "Can't move focus to the control because it is invisible, not enabled, or of a type that does not accept the focus". Not sure why its doing it but if you switch back to design mode before you use SetHTML it seems to circumvent the focus problem:
var editor = FCKeditorAPI.GetInstance('decode_editor');
editor.EditMode = 0; // switch back to design mode before setting content
editor.SetHTML( tempArea.innerHTML );
Again this all seems very similar to the problem in the troubleshooting page of the wiki ( http://wiki.fckeditor.net/Troubleshooti ... ab9d551417 ) but by the looks of things that bug is rather elusive too so I wouldn't like to say whether or not its the same thing.
Cheers for the pointers Alfonso.
Tromm
RE: Further API object issue
I've tested with the sample 8 and I don't have any problem to get or set the contents in source mode.
But doing "editor.EditMode = 0;" might lead to problems, I'm not sure but it doesn't seems right to me, after all you are just flipping a variable stating the current mode of the editor instead of really forcing a change of editing mode.