You are not logged in.
Pages: 1
I'm developing an intranet application requiring a WYSIWYG editor. I ran into a problem with placing WYSIWYG fields in blocks that display in fixed positioned windows. Essentially, the auto or toolbar options both gave me extrordinarily small WYSIWYG fields, the editable area was around 100 pixels wide, while the toolbar spanned all the area available to it.
Some investigation revealed that the 'toolbar' option wasn't doing what it is supposed to do. A check of this line revealed the culprit:
case 'toolbar': {width = parseInt(this._toolbar.offsetWidth); break; }
(Around line 1102) offsetWidth was outputting zero. I suspect this could have something to do with how I have designed my application, the WYSIWYG fields appear in blocks that are set to display: none, and are only displayed when the user selects a particular option.
I hacked around this problem by making the following changes (around line 1233):
// Set the dimensions of the container
this.innerEditor.style.width = 'auto'; //width + 'px';
this.innerEditor.style.height = height + 'px';
this.innerEditor.style.position = 'relative';
// and the iframe
this._iframe.style.width = 'auto'; //editorWidth + 'px';
this._iframe.style.height = editorHeight + 'px';
this._iframe.style.position = 'absolute';
this._iframe.style.left = editorLeft;
this._iframe.style.right = 0;
this._iframe.style.top = editorTop;
// the editor including the toolbar now have the same size as the
// original textarea.. which means that we need to reduce that a bit.
this._textArea.style.width = 'auto'; //editorWidth + 'px';
this._textArea.style.height = editorHeight + 'px';
this._textArea.style.position = 'absolute';
this._textArea.style.left = editorLeft;
this._textArea.style.right = 0;
this._textArea.style.top = editorTop;
These edits work for me because my intranet application is designed for Gecko exclusively (so setting both a left and right offset property works here, where it would fail in IE), however I'd rather not have to fork the code. Is this a known issue? Is there something better that I could do to work around the problem?
FYI I'm using the latest nightly, which I downloaded today, 3-18-2005.
Offline
I've seen something similar. I just set the this.width to "toolbar" in htmlarea.js. Seems to have fixed it for me.
-----------------------------------------------------------------------------------------
Content Management with Business Intelligence [url]http://www.formvista.com[/url]
Offline
Indeed, if you start the editor in a display:none area, things will be, err, fishy to say the least (actually it used to be that moz would crash if you tried to do that).
I'm working (on and off) on fixing up the sizing (and resizing) of the editor, at the same time as I put in some small support for skins and fix up the toolbar problems.
James Sleeman
Offline
I´m searching for a workaround for the problem, that Xinha could not start in a display:none area without problems in Firefox. This feature would be great to have a navigation for different parts of one form (e.g. area one with file meta information, area two with html content via xinha). I think an easy solution could be, if you just start the editor after setting the second area to display:block. To enable the switching I need a function to convert the div area with toolbar, iframe and statusbar back to the textarea. The starting point could be parallel to startEditors function:
HTMLArea.closeEditors = function(editors)
{
for(var i in editors)
{
if(editors[i].restoreTextarea) editors[i].restoreTextarea();
}
}
The restoreTextarea function would be like this I think:
HTMLArea.prototype.restoreTextarea = function() {
// create textarea
// move the current iframe content to textarea
// remove innerEditor
};
Now my question: Are there any functions which could help me in creating the restoreTextfield function. I´m sure that I´m just blind for it because of the setMode function which replaces the iframe by a textarea, but all I have tried has failed.
Offline
Pages: 1