Hello,
I have a WebHtmlEditor control (11.1) on my page and when using Design view and typing a url or email address it is auto converted and rendered (underlined).
When typing into the HTML view, the same does no happen (which is as expected), however, the URLs and email addresses are initially underlined and appear clickable when they aren't.
Moving to the Design view and then back to HTML removes the styling (again as expected).
I therefore have 2 questions:
1. Is there a way to prevent the automatic styling of URLs and email addresses in the HTML view?2. Is it possible to disable automatic converting in the design view and force users to use the toolbar icon?
Thanks
Hello Warwick,
If you need any further assistance with the matter, please do not hesitate to ask.
Since we only target Internet Explorer, I suspect we only need the Style part of the fix and not the script part? Assuming this is correct (which seems to work) this doesn't entirely satisfy my requirement.
I need the automatic colouring and underlining to be prevented when in HTML view, but not in Design View. As far as I can see, the suggested fix 'corrects' the automatic styling in both views.
Is there a way to only apply the style to the HTML preview element and no the Design view element? As far as i could tell, these were using the same htmlEditor_tw element.
Alternatively, is there a way to know which view is currently being shown and modify the css style accordingly?
Hi,
Thank you steps. Now I undertood what you refer to. Similar "friendly" replacement of text by link-object is used in almost all Microsoft products/editors and I am in doubt that is possible to disable that feature using public properties.Building of that object happens not by typing actual text of address, but by typing Space or Enter at the end of that text. So, existing text can be converted to "link-object" by Space. That "build-object" functionality can be toggled by obscure combinations of BackSpace/Space characters at the end of address-text.
To get around, I do not recommend to use css classes, but to process keypress-with-delay or keyup events, check for A object(s) and remove it(them).The underlined text may appear for awhile and disappear. I hope that end-users may live with that. In that respect the keypress is preferrable, because end-user may press and hold Space key and the A object will stay until end-user releases key. Below is example to implement.
<script type="text/javascript"> function WebHtmlEditor1_KeyPress(oEditor) { if (oEditor._html && oEditor._ie) setTimeout(function() { var div = oEditor._elem; if (div.getElementsByTagName('A').length > 0) div.innerHTML = div.innerText; }, 5); }</script>
<ighedit:WebHtmlEditor ID="WebHtmlEditor1" runat="server" ...> <ClientSideEvents KeyPress="WebHtmlEditor1_KeyPress" /></ighedit:WebHtmlEditor>
Thanks for the quick response, but unfortunately, this workaround doesn't work.
1. In Design View enter the following address: www.warwickicsystems.com2. Switch to HTML view and the correct markup will be present3. Still in HTML view enter the address on a new line4. The original markup is now removed - not good
Since our application is designed to allow them to use either view this will cause an issue.
You are correct. When I tested last my codes, then I tried only space/backspace keys and only one line of content. I forgot that Enter key is not processed by keypress event and that innerText might not work well, if explicit new lines are created within HTML view.
I replaced keypress by keydown and replaced over-simplified innerText by fixing real DOM objects (which is what I intended to do before).
I also added "speed-up" condition to process only low keys. You may replacekeyCode < 33by something like(keyCode == 32 || keyCode == 13)or if autoformat will happen with other keys, then corresponding keyCodes can be added to that condition.
<script type="text/javascript"> function WebHtmlEditor1_KeyDown(oEditor, keyCode) { if (oEditor._html && oEditor._ie && keyCode < 33) setTimeout(function() { var elems = oEditor._elem.getElementsByTagName('A'), i = elems.length; while (i-- > 0) { var a = elems[i]; a.parentNode.replaceChild(document.createTextNode(a.innerHTML), a); } }, 5); }</script>
<ighedit:WebHtmlEditor ID="WebHtmlEditor1" runat="server" ImageDirectory="~/images/htmleditor/"> <ClientSideEvents KeyDown="WebHtmlEditor1_KeyDown" /></ighedit:WebHtmlEditor>
Thanks for the reply, but this too unfortunately has some issues with it:
1. In HTML view type www.google.com2. The auto-styling is prevented (good)3. Then add (without any spaces) a <p> tag, ie: www.google.com<p>4. Now add (again without any spaces) www.google.com, ie: www.google.com<p>www.google.com5. Add a space to the end of the line (or a line feed)This now gets converted to www.google.com<p>www.google.com
There is also an issue using the mouse:
1. Add www.google.com to the first line of the HTML view2. Add a couple if line feeds3. Remove the m from the end of com and re-add it4. Now click anywhere inside the control
The auto-style returns. This disappears with the next keypress though.
Since this is inherent to the way IE is handling DIVs I suspect all workarounds will have these issues. I think this needs to be addressed as part of the controls foundation code - if possible.
In the first scenario you could you could use innerText instead of innerHTML in Victor’s code, in order to prevent the encoding of characters:
function WebHtmlEditor1_KeyDown(oEditor, keyCode, oEvent) {
if (oEditor._html && oEditor._ie && keyCode < 33) setTimeout(function () {
var elems = oEditor._elem.getElementsByTagName('A'), i = elems.length;
while (i-- > 0) {
var a = elems[i];
a.parentNode.replaceChild(document.createTextNode(a.innerText), a);
}
}, 5);
And here is a possible workaround for the second case you described:
document.onclick = function () {
var elems = iged_getById("WebHtmlEditor1")._elem.getElementsByTagName('A'), i = elems.length;
This should prevent the auto-styling in these particular scenarios.
If you have any further questions, please do not hesitate to ask.
Hi Warwick,
If you find any other issues with this matter, please let me know.
Thanks for the replies. The latest workarounds still had an issue when clicking outside the control if on the design view. I added similar code to first workaround, ie: oEditor._html && oEditor._ie and it seemed to work correctly.
This still needs to go through our QA process but hopefully everything will be fine.
Thanks.
Please let me know if you have any other concerns.