I'm evaluating kendo.ui.editor for use embedded in an iOS app (js loaded locally into UIWebView).
A requirement is to use a native toolbar instead of the HTML-toolbar provided by Kendo.
The native toolbar needs to reflect the content of the text at the editing position (just like the html toolbar does),
and therefore I need to be able to query the editor for attributes about the text at the cursor position.
Things like "is the text bold", "what is the font and font-size", ...
I can't seem to find any methods to query this information in the documentation at http://docs.kendoui.com/api/web/editor.
What I'm looking for is basically the equivalent of TinyMce's queryCommandState (http://www.tinymce.com/wiki.php/api4:method.tinymce.EditorCommands.queryCommandState).
How can I query the kendo.ui.editor about it's state ?
Thanks.
8 Answers, 1 is accepted
This functionality is currently unsupported. However, since such a method sounds reasonable (and its implementation comes cheaply with our current code), it will be introduced in the next internal build later today (the state method):
var editor = $("#editor").data("kendoEditor");
console.log(editor.state("italic")); // logs true or false
Alex Gyoshev
Telerik

I have tested the state-method, and it seems to only give the correct result when there is a selected range of text.
When there is no selection, and the cursor is placed inside an italicised word, the result is 'false'.
I can see that the toolbar of the editor I am writing this message in is capable of indicating italics when the cursor is moved into and out of an italicised word...
How can I achieve the same ?
Thanks.

Here is a few more items to my wish list...
The current implementation of the state() method seems to only work for boolean properties like "bold", "italic" etc.
It would be nice to have it work also for properties like "fontName", "fontSize", "foreColor", "backColor", which currently return a true/false answer.
If the state-method is not going to give useful answers for the above properties,
what would be the recomended way of determining the fontname+size and fg/bg colors of the text at the cursor position ?
Thanks again.
> When there is no selection, and the cursor is placed inside an italicised word, the result is 'false'.
Thank you for reporting this, it has been fixed for the next internal build.
> It would be nice to have it work also for properties like "fontName", "fontSize", "foreColor", "backColor", which currently return a true/false answer.
Indeed, it would be nice. This is also included in the next internal build.
Regards,
Alex GyoshevTelerik

I have just tested the 2013.2.925 internal build, and it seems to give usable output - apart from one bug (more about that in the end of this message).
Here is the output from querying the state-method using 2013.2.925:
bold = false // returns true or false
italic = false // returns true or false
underline = false // returns true or false
strikethrough = false // returns true or false
subscript = false // returns true or false
superscript = false // returns true or false
backColor = inherit // returns 'inherit' or a html hex colour code
foreColor = inherit // returns 'inherit' or a html hex colour code
fontName = inherit // returns 'inherit' or a string containing font name
fontSize = inherit // returns inherit or XXpx
insertOrderedList = ul // returns current list type: 'ol', 'ul' or empty string (no list)
insertUnorderedList = ul // returns current list type: 'ol', 'ul' or empty string (no list)
justifyLeft = // returns empty string if not explicitly left-justified. I.e. also empty for default left-justified text.
justifyCenter = // returns empty string if not explicitly center-justified.
justifyRight = // returns empty string if not explicitly right-justified.
The 'justify' states seem to return the HTML-tag that the justification is attached to, for example 'p'.
Now for the advertised bug report:
The last character(s) in a formatted span does not seem to be reported correctly.
For example, I have the following in an editor:
<p><span style="color:#ff0000;">Features include:</span></p>
(Raw html, The editor displays "Features include:" in red text).
When the edit cursor is placed after the colon, and in-between the 'e' and the colon, querying foreColor returns 'inherit'.
It is first when the edit position is between the 'd' and the 'e' that foreColor returns the correct '#ff0000'.
Likewise, when on the end of a line inside a list, querying insertOrderedList will return empty/no-list.
Thank you for reporting these, they have been fixed for the next build.
Do you find the return values useful? As you have listed them, they appear a bit inconsistent, but make sense for each of the tools. Do you think that we need to change them to a more consistent format?
Regards,Alex Gyoshev
Telerik

Thanks for fixing stuff - I'll give the next build a spin tomorrow morning.
As for the return values for the individual tools, I agree they make (reasonable) sense in the context of each tool.
Without documentation for the return values, it took a little to figure out what for example a 'p' return from 'justifyLeft' meant...
but that would be easily fixed with a little documentation ;-)
As for the return of 'inherit' for some tools, I think this will work for my use-case,
where I can get by with displaying something like 'default' or similar when for example fontName equals 'inherit'.
It would probably be more useful if the return value was the actual/resolved value... or if there was another way of resolving what 'inherit' would mean for each tool.
Querying 'insertOrderedList' and 'insertUnorderedList' I think will always return the same result, namely one of ['', 'ol', 'ul'].
Maybe there should be a query for current-list-type, instead of the two 'insert*List' variants...
That is no big deal - the current implementation will do the job (I know to query only one of them by now).
As for the justify-queries, I think I will need to treat the return value as a boolean, and do something along the lines of:
if state('justifyRight') != empty then I have right-justified text
else if state('justifyCenter') != empty then I have centered text
else I have left-justified text.
... in order to cope with having default left-justified text.
But all in all, I think the current implementation fulfills my needs.
I'll get back with some test results in the morning.
/M.

I have tested thing on internal build 2013.2.926, and all state variables seem to work as expected.
Thanks for fixing stuff as they where found.
/M.