Problem in IE with Toolbarlocation set to Out

Thanks for the quick update - will continue to test, but it seems to be working now (in a single toolbar setup - see below).

For a test comparison, I ran the old HTML example 10 agains the new one from last night's build.

In the old version (2.43) the example 10 (loaded in IE7 by itself - not from the samplelist), would load correctly the first time - then if you refreshed the browser, all but the top row of buttons was hidden.

In this new build - it loads correct the first time, then if you refresh the browser you see it hide all but the first row of buttons - then the toolbar refreshes and displays all the rows.


There is one small problem that I have found though:

I allow the user to switch between a Basic and an Advanced toolbar "on-the-fly". The Basic is one row of buttons tall, the Advanced is three rows.

As the code works right now, if I load the Advanced toolbar first - then switch to the Basic toolbar, it works and I can freely toggle between the two - but the space occupied by the xToolbar DIV remains the same. This is a minor annoyance and certainly something I can live with.

However if I load the Basic (one row) toolbar first - then switch to the Advanced toolbar (three row), then only the top row is displayed.

I tried setting the height of the xToolbar DIV when I switch toolbars as a workaround, but once the Basic toolbar is loaded as the first toolbar, FCKeditor seems to remember (and reuse) that height.

Since the normal mode of operation would be to start with the Basic toolbar and let the user enable the Advanced one if need be - there appears to be no way to accomplish this.

I tried leaving the toolbar set to Advanced during the create - then resetting the toolbar after the initialization by calling my function in FCKeditor_OnComplete, but that does not appear to work (you briefly see the Advanced toolbar, then the Basic appears and the DIV collapses and stays that height).


BTW - the syntax I am using to switch toolbars is:

function tbBasic()
{
  var oEditor = FCKeditorAPI.GetInstance('FCKeditor_1') ;
  oEditor.ToolbarSet.Load( 'Basic' ) ;
}

function tbDefault()
{
  var oEditor = FCKeditorAPI.GetInstance('FCKeditor_1') ;
  oEditor.ToolbarSet.Load( 'Default' ) ;
}

If this is not the correct way, please advise.

If I am doing it right, then it would be nice if the editor would resize the DIV as needed if it is set to Out when loaded.

I'll let you know if I run across any other issues.

Thanks again!

MD

I have found one major problem with the new fix from the nightly build.

If a HTML page with that code in it is loaded into any Windows desktop application (such as TopStyle and also in a desktop application that we are building), the fix is causing that program to lose focus and drop behind other applications.

If it is the only desktop application running then this does not happen.

It also does not happen in IE - only other applications that have a built-in browser in them.

Obviously this is not acceptable behavior - and in our case it is an absolute show stopper for using this configuration since everytime a page is loaded our application would lose focus.

Perhaps we can get a tweak on the fix (or advice on how/where to do it ourselves).

Thanks!

MD

BTW - I was going to file a ticket on this, but when attempting to do so I got this error:

TICKET_CREATE privileges are required to perform this operation

Thanks!

MD

alfonsoml wrote:That behavior might be related to the changes to try to make the editor respect the focus settings in the config. If you use a toolbar inside the editor and the problem still persists then for sure it isn't related to the ToolbarLocation configuration.

I tested that.

If I place the toolbar inside the editor - it behaves as expected when the HTML page is loaded in a desktop app.

If the ToolbarLocation is set to outside the editor - then the problem returns.

The way the changes are now renders the editor useless in a desktop app with the toolbar set outside the editor.

Hopefully there is a better solution.

Thanks!

MD

alfonsoml wrote:The page that explains how to file bugs already mentions that you must log in before creating or commenting on bugs (to prevent spam at least a little): http://dev.fckeditor.net/wiki/Bugs

Turns out I was wrong.

This got rid of the last set of problems - but the original is back.

I have opened a ticked (#1017) on it.


MD