|
|
Rank: Newbie
Groups: Member
Joined: 3/1/2011
Posts: 7
|
Hi, I need to switch from my current HTML Editor for our CMS and I'm evaluating EO, namelly the HTML Editor. I can't seem to put a custom toggle button to work. Here is the aspx code of the editor:
Code: HTML/ASPX
<eo:Editor ID="Editor1" runat="server" ToolBarSet="Full" EmoticonSet="">
<CustomHeaderTemplate>
<eo:ToolBar ID="HeaderToolBar1" runat="server" Width="300px" ClientSideOnItemClick="EOEditorHTMLToolbarClickHandler">
<Items>
<eo:ToolBarItem CommandName="ParagraphMode" ImageUrl="~/images/toggleparagraphmode.gif" ToolTip="Toggle paragraph mode" AutoCheck="true" />
<eo:ToolBarItem CommandName="Bold" ImageUrl="00101011" ToolTip="Bold" />
</Items>
<NormalStyle CssText="padding:3px 4px; border-style:none; cursor:hand; " />
<HoverStyle CssText="padding:2px 3px; border: #335ea8 1px solid; background-color: #c2cfe5; cursor:hand;" />
<DownStyle CssText="border: #335ea8 1px solid; padding:3px 2px 1px 4px; background-color: #99afd4; cursor:hand;" />
</eo:ToolBar>
</CustomHeaderTemplate>
</eo:Editor>
I also have the javascript block:
Code: JavaScript
function EOEditorHTMLToolbarClickHandler(Toolbar, ToolbarItem, Submenu)
{
var pushed = ToolbarItem.getPushed();
alert("click. present state:" + pushed);
if (ToolbarItem.getCommandName() == "ParagraphMode")
{
ToolbarItem.setPushed(!pushed);
return false;
}
return true;
}
For the "ParagraphMode" button, it's state is always "true"... I cannot seem to change it! And graphically it only appear highlighted when the mouse is over the button. I'm I doing something wrong? Thank you in advance José Proença searchmarketing.pt
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi, Please try the following steps: 1. Change CommandName="ParagraphMode" to CommandArgument="ParagraphMode". This means the toolbar button no longer has a CommandName value. This is important because as long as the button has a CommandName, the editor will "take it over" and ignore your setPushed call; 2. Add an onload handler to your document's body element:
Code: HTML/ASPX
<body onload="init_toolbar()" ...>
...
</body>
Code: JavaScript
function init_toolbar()
{
//Delay the call
setTimeout(function()
{
//Get the toolbar
var toolBar = eo_GetObject("HeaderToolBar1");
//Enable the toolbar item
toolBar.getItem(0).setDisabled(false);
}, 10);
}
This enables the first toolbar button (change the index "0" to another number if it is not the first button). This is necessary because the Editor will automatically disable all commands that does not have a command name; 3. Change your EOEditorHTMLToolbarClickHandler to call ToolbarItem. getCommandArgument instead of ToolbarItem.getCommandName since CommandName is empty now. This should work for you. Please let us know how it goes. Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 3/1/2011
Posts: 7
|
Thank you for your fast response. It sure is a big plus of your package!! Now for the change you suggested. I've applied all your directives, debugged step-by-step to see if everyting is as expected, but it does not work. The result is the same: its getPushed() always return true. The only thing that worked as you expected is that the button appears disabled at first, and then it becomes enabled. The code for your verification:
Code: JavaScript
function EOEditorHTMLToolbarClickHandler(Toolbar, ToolbarItem, Submenu)
{
var pushed = ToolbarItem.getPushed();
alert("click. present state:" + pushed);
if (ToolbarItem.getCommandArgument() == "ParagraphMode")
{
ToolbarItem.setPushed(!pushed);
return false;
}
return true;
}
Code: HTML/ASPX
<eo:ToolBarItem CommandArgument="ParagraphMode" ImageUrl="~/images/toggleparagraphmode.gif" ToolTip="Toggle paragraph mode" AutoCheck="true" Disabled="false" />
Maybe I should use a completely custom toolbaritem ?
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
You are very welcome. Try to remove AutoCheck="true" and Disabled="false" from your toolbar item. Those two are unnecessary.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 3/1/2011
Posts: 7
|
I've managed to put it to work, although I have much more so say about this. In a few hours I will return to this topic in the forum to develop further.
thank you.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
No problem. Please feel free to let us know.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 3/1/2011
Posts: 7
|
My last answer was posted before I saw your advice on AutoCheck and Disabled, and you were right.
"Disabled" was a remnant of my experiments. But removing AutoCheck did the trick.
I've also concluded one more thing.
Adding Pushed=True to the ToolbarItem makes the button start in the selected state.
But, setting Pushed=False, makes the button start in "undefined" state.
I think this is odd and unexpected.
Adding disabled=false to the ToolbarItem should prevent adding that code to enable the button initially. In fact this code is not practical. You see, the code I've shown was made for debugging purpose. The Html Editor will be inserted in a CMS system with very complex control loading. Your html editor will be loaded by one or more Page.LoadControl() inside two or more nested update panels. Even if it were possible, less-than elegant solutions would contribute the CMS system being more error prone.
I think your solution, namely, the non-pre-defined commandNames being also processed internally is very awkward. Using commandArgument to pass the command name is also an indicator of a poor solution, in my perspective.
In fact, I've discovered that returning True or False from the ClientSideOnItemClick function controls further processing of the command, which is the expected behavior on an command processing hook function.
So all this seems like a work in progress solution, to me. I would like to know what is your perspective on this matter.
Meanwhile I have to go for the custom toolbaritem solution. In this solution I guess that I have to provide all from scratch to put a two-state button to work, afterall redoing what you have done with the ToolBarItem object! Or is there any other solution?
Many thanks!
José Proença
searchmarketing.pt
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
ztp wrote:I think your solution, namely, the non-pre-defined commandNames being also processed internally is very awkward. Using commandArgument to pass the command name is also an indicator of a poor solution, in my perspective. I agree with you on this one. Custom commands was implemented but most people only needs it to trigger their custom action. The issue only become apparent when you also need to check/uncheck the button. I believe the cleanest way for us to address this is issue to change our code so that custom commands are ignored (or provide some kind of "UpdateButtonState" callback) by our Editor. ztp wrote:In fact, I've discovered that returning True or False from the ClientSideOnItemClick function controls further processing of the command, which is the expected behavior on an command processing hook function. Yes. This is the designed behavior. ztp wrote:Meanwhile I have to go for the custom toolbaritem solution. In this solution I guess that I have to provide all from scratch to put a two-state button to work, afterall redoing what you have done with the ToolBarItem object! Or is there any other solution? Custom toolbar item is great for "normal" solutions, but you may run into issues with pushed state again. The reason is unless the toolbar knows what style should be applied in "pushed" state, it will try to apply "hover style" on top of the "pushed style". If you can wait for a few days, we should be able to give you a newer build with a "cleaner" solution through setPushed. That might be a better solution for you. Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 3/1/2011
Posts: 7
|
eo_support wrote:
If you can wait for a few days, we should be able to give you a newer build with a "cleaner" solution through setPushed. That might be a better solution for you.
Thanks!
Athough I have much more customizing to do, if you do that, I'll buy it before ending my tests!!!!! I'll can't go wrong with you! many thanks
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Good to hear that. We will try to provide you an update build as soon as possible.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Hi,
We have posted a new build that would ignore custom toolbar items. Please see your private message for the download location.
Your original code will work fine with the new build except that you need to remove AutoCheck="true", which is no longer necessary.
Thanks!
|
|
Rank: Newbie
Groups: Member
Joined: 3/1/2011
Posts: 7
|
Works perfectly!!
I'll start the purchase procedure asap.
Many, many thanks!
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,194
|
Glad to hear that! Please feel free to let us know if you need any help.
|
|