Coco_XH

[cmb]

Hi B,

Must be a problem with ckeditor

Do you use the latest version (1.0rc)? I'm quite sure that 1.0b5 doesn't work.

Christoph

[Gert]

Hi bca,

excuse my stupid advice, I have not read your posts exactly ... I thought you had nothing, but you had a blank textarea without editor.

So I think it's a problem with the old CKeditor, like Christoph said,

Gert

[bca]

That's better!
Was using old version of Ckeditor.

Now to have a play!

BTW if i want to style each cocontent box differently do i use the plugin stylesheet or the main template stylesheet or doesnt it matter.

B

[cmb]

Hi B,

do i use the plugin stylesheet or the main template stylesheet or doesnt it matter.

Actually it doesn't matter. But usually you'll enclose the call to coco() in a <div> with an ID or class in the template. So it seems natural to style this in the template's stylesheet.

Christoph

[bca]

Hi Christoph
Is there a minimum height for the Coco box?

Full story: I have edited CKeditor so the sidebar option has the source view. I have a text box which is height:175px.
When in Coco mode the editor window cuts of the bottom of the editor view and there are no scroll bars.
Bur if i go to source view there are scroll bars and when I go back to normal view there are scroll bars and the editor fits in the 175px height text box.

Not sure whether this is coco, ckeditor or me!

b

[cmb]

Hi B,

I haven't tested it yet, but I guess that it's CKEditor and the browser. When I developed Coco_XH I found the strange behaviour, that CKEditor didn't fit in a small newsbox area (about 200px). Only after clicking the resize handle the width of the editor was adjusted correctly. Later I found that it was an issue with Chrome (16?); all other major browser did handle the small area quite well.

I'll have a look at it later.

Christoph

[bca]

Tried Firefox and it is the same.

However it works OK with TinyMce once I added the code button to the toolbar.(although the bottom info line is cut)
In fact the fact that TinyMCE opens a pop up for code editing seems better that CKEditor

Thanks Christoph

B

[cmb]

Hi B,

In fact the fact that TinyMCE opens a pop up for code editing seems better that CKEditor

For small editors indeed. But alternatively you can switch to fullscreen mode when editing with CKEditor.

When in Coco mode the editor window cuts of the bottom of the editor view and there are no scroll bars.

It took me quite a while to reproduce this behaviour. The problem: when in WYSIWYG mode CKEditor seems to use a mininimum height of about 450px (the toolbar has 1 line). This can't be forced to be less, even with the third parameter of coco() set to e.g. '175px'. Now it seems, that your textbox set overflow:hidden (otherwise the editor will expand the textbox); you could set it to overflow:auto to display scroll bars (but that seems to be merely a workaround as editing with duplicate scrollbars might be somewhat demanding).

Christoph

[bca]

you can switch to fullscreen mode when editing with CKEditor

That is true. Had not looked for a maximise button only a full screen button.
Have edited the CKEditor init-sidebar to include the maximise button and it is all ok now.

Perhaps for a release in the future a way of using config to add or remove buttons from the toolbar. Obviously it would depend on what editor you are using and thereby gets a bit complicated

your textbox set overflow:hidden

True

b

[cmb]

Hi B,

Perhaps for a release in the future a way of using config to add or remove buttons from the toolbar. Obviously it would depend on what editor you are using and thereby gets a bit complicated

That's definitely nothing I'll do for Coco_XH (or any other plugin I might write in the future that uses an editor), as it would restrict the plugin to particular editors, or would require me to update the plugin for every single editor that will be released in the future. So the user has to edit his init_*.js file (note that you can copy one of the init_*.js files and rename them, e.g. to init_coco1.js, if you want to keep init_sidebar.js for another purpose, or to avoid it being overwritten with the next update).

But the authors of the editors might think about allowing the most common settings to be edited from the back-end. I did this for Codeeditor_XH, but will probably switch to the init_*.js files for the next release, as editing some JS config files shouldn't be a problem for users who prefer editing in HTML mode all the time.

Christoph