[greentechieParticipant]

OK, so it failed when I entered the link using the “link” button to enter the link, but worked when I justed pasted it into the text.

[greentechieParticipant]

This is the text of the link. It was removed from my post, although the HTML looked correct: http://jsfiddle.net/greentechie/1vrLmrko/5/

[greentechieParticipant]

That Fiddle link is still wrong, hopefully this one will be correct:

I have now tested Microsoft Edge too. All browsers lose formatting when “Set Rich Text” button is clicked twice. Edge correctly displays val() of editor following setMode, where Firefox fails.

Clicking “Set HTML” twice corrupts text by changing it into a text version of the actual HTML. This happens in Firefox, Chrome and Edge.

[greentechieParticipant]

PS: I notice that my last message was slightly corrupted by my use of a pre tag, sorry.

PPS: The behaviour in my fiddle, where the formatting is lost, is the same in Chrome but the alert message works in Chrome, but fails in Firefox.

[greentechieParticipant]

Hi Peter,

Thank you, I have re-read all of your responses.

If I understand you correctly then the

 tag with the ID of "sourceText" is always going to contain the user text, so that is accessible through string parsing. I was not sure how much of the returned text was dependant upon the browser, hence my worry that I could not reliably parse the result.

It would be useful to have a "mode" property or "getMode" function, so I know when I need to parse the text. Although I could test the result text for the "sourceText" ID, it would seem useful to have some way of reading the current mode of the editor.

I feel a little frustrated that there has been no acknowledgement that there is an issue with the "setMode" function. Why does it lose the formatting, as in my example, and why does it prevent the next statement executing as also in my example?

If setMode worked as expected there would be no need to do any special parsing on the result.

Best Regards,
Jamie

[greentechieParticipant]

Hi Peter,

It will be difficult to use string slicing if I don’t know what text I am removing, due to it varying by browser.

The way around this issue is to change the editor back to “rich text mode” (WYSIWYG) before saving the text, which would solve the problem.

This brings me back to my original problem!

Here is a fiddle I have made to demonstrate :-

The fiddle starts in WYSIWYG mode with the text “New <b>Value</b>”, so “Value” is in bold.

If I click button “Set Rich Text” (which is the current mode) then all formatting is lost! Is this intentional?!

If I click “Show Value” then the value is displayed, but if I click “Set Rich Text + Show Value” then the mode changes (or loses formatting) but the alert message is never executed! Yet the code is the same as buttons “Set Rich Text” and “Show Value” combined. Is this what you expect?

I can get everything working with TinyMCE, but I’ve had a jqWidgets Developer License for three years now and I’m trying to make this consistent with the other components I’m using.

I like the look of jqxEditor, but I don’t see how I can ever use it if there is no way to reliably get what the user typed?

Best Regards,
Jamie

[greentechieParticipant]

PS: For some reason the fiddle link was removed. It is : http://jsfiddle.net/jqwidgets/zxaRL/

[greentechieParticipant]

Hi Peter,

I’m just looking at the fiddle example for val() at and if I change the HTML to :-

$('#editor').jqxEditor({
    height: 400,
    width: 800,
    theme: 'energyblue'
});

$('#editor').val("New Value");
$('#editor').jqxEditor('setMode', true); 
alert($('#editor').val());

… then the message I get is “<br><pre style=”height: 100%; margin: 0px; outline: medium none; display: block;” id=”sourceText” contenteditable=”true”>New Value”.

But if I change to code to $('#editor').jqxEditor('setMode', true); then the message says “New Value”.

Are you saying that this is expected behaviour? If so how to I use the editor to allow the user to make use of both modes?

Best Regards,
Jamie

[greentechieParticipant]

Hi Peter,

I don’t think I understand.

If the user enters “<div>Hello World</div>” in the “HTML mode” of jqxEdtor is there any way for me to read the contents as “<div>Hello World</div>” instead of “<br><pre style=”height: 100%; margin: 0px; outline: medium none; display: block;” id=”sourceText” contenteditable=”true”><div>Hello World​</div>”?

Or do I have to change the view back to “rich text” mode before I can read the contents correctly?

Best Regards,
Jamie

[greentechieParticipant]

PS: By “HTML editor mode” I mean clicking on the “</>” button in the jqxEditor.

[greentechieParticipant]

Hi Peter,

I am not referring to what the form submits. The submit button displays an alert message and that is what shows the contents of the editor.

I think the fact that there is a form involved is confusing things. I did start with an editor in a form (actually fully in the form) and the original problem was as described in my first message.

I only needed to change the mode due to what I believe is a bug.

Please can we start again and just assume a simple web page with a jqxEditor and a single button that displays the editor.val() in an alert message. When the editor is in “rich text” mode the button shows “<div></div>”. When the editor is in HTML editor mode the button displays a completely different message.

Please ignore the form in the fiddle example, as in this case it is just acting as a button, and you will see the same behaviour. I am not referring to what is submitted by the form, but what jQuery returns as the val() of the editor.

Thanks,
Jamie

[greentechieParticipant]

Hi Peter,

If you click on the </> button in the jqxEditor component, then hit submit the message I see displayed in all browsers is as I described. If I hit submit in the default view it says “<div></div>”.

Please try going into HTML display/edit mode before clicking submit and see what you get. This seems like a bug to me.

Thanks,
Jamie

[greentechieParticipant]

Hi Peter,

Thanks, but when I change to the HTML mode in the editor the text returned is still …
<br><pre style="height: 100%; margin: 0px; outline: medium none; display: block;" id="sourceText" contenteditable="true"><div>​</div></pre>
… not …
<div></div>

Is this not a bug?

Best Regards,
Jamie

[greentechieParticipant]

Hi Peter,

Thanks again, but the user needs to style the text size/colour/font etc. They may also want to edit the HTML.

Sorry for the confusion, but when I said “raw text” I meant the just actual HTML, without additional tags.

I would like to just use the jqxEditor in the form, without any extra code, but if the user looks at the HTML view as they hit submit I get all the extra tags, like “

", which get saved to my DB and lose all the formatting the user created.

Is there a different function that will will return just "<div></div" for an empty text string, regardless of which mode the editor is in, without all the extra tags that val() returns?

Thanks,
Jamie

[greentechieParticipant]

Hi Peter,

Thanks for the reply. Where did you place the DEBUG=True code to see the extra details?

I know that the post method does not succeed, as I was not expecting it to on the fiddle page. My test was only to see which statements executed.

But as removing the line “$(‘#editor’).jqxEditor(‘setMode’, false);” allows the rest of the code to succeed, which displays the contents of the editor in the alert, does that not mean there is an issue with the statement in question?

It would be even better for me if there was a way to get the correct raw text from the editor widget, regardless of which “mode” it was in. Then I wouldn’t need to change the mode.

As it stands the text returned in that fiddle example when in rich text view is :-
<div>​</div>

But if the editor is in HTML mode the val() method returns :-
<br><pre style="height: 100%; margin: 0px; outline: medium none; display: block;" id="sourceText" contenteditable="true"><div>​</div></pre>

Best Regards,
Jamie

[Author]

Posts