caretPosition removes <br> tags

[John Robin Dove]

Hi Clifton,
You may remember, some time ago, you helped me create colored link words dynamically in a text. There was a problem if the text included line breaks so I decided to replace line breaks with spaces. I have thought about this and I think that I would prefer to keep the line breaks as these may be important in reported speech, for example.
I use caretPosition to add a marker to the text and I have discovered that this causes all the <br> tags in the innerHTML to disappear. Can this be avoided, please? I have put an example here: https://www.mediacours.com/tb_examples/line_break/ and a zip here: https://www.mediacours.com/tb_examples/line_break.zip
Thanks for you time.
John

UPDATE
I have now found a way round this in the test app by doing this:
let txt = sharedActions.obj2.innerHTML;
txt = tbfunction_pgReplace("<br>", "~", txt, true);
sharedActions.obj2.innerHTML = txt;
tbfunction_caretPosition("myText2", 5, "", " ADDED ", false);
txt = sharedActions.obj2.innerHTML;
txt = tbfunction_pgReplace("~", "<br>", txt, true);
const fct = function()
{
sharedActions.obj2.innerHTML = txt;
}
setTimeout(fct, 100)
So far I have not been able to apply this to my program. I did not realise that ANY use of tbfunction_caretPosition results in the elimination of all occurrences of <br> in the innerHTML. Maybe this is an inevitable part of your system? I imagine you must be using the innerText and/or textContent properties. I'll try again and let you know if I solve the problem.

UPDATE 2
I now have a system that works in my program so, if you have more important things to do, don't worry too much about this. I was wrong about 'ANY use of tbfunction_caretPosition'.
For example: tbfunction_caretPosition("myText2", "home"); and let pos = tbfunction_caretPosition("myText", -1); leave the <br> tags in place but tbfunction_caretPosition("myText2", "end"); does not.

I must now do some more thorough testing to see if my workaround is reliable or not.
John

[Clifton]

Please try the latest PowerPac release which fixes caretPosition() and several anomalies found since I worked on this a while ago.

Current PowerPac release that fixes caretPosition() is v15.543.0.

Also, please note that ToolBook v9.0 does not properly convert fields to editable DIVs
unless you add a little JavaScript to the process.
All other versions of ToolBook work fine with the conversion process.

ToolBook v9.0 issues with converting editable DIVs:

1. After conversion, you cannot move the caret using the mouse.
2. After conversion, you cannot manually type into the field.
3. After conversion, you may not be able to keep inserted text selected. If it does get selected, you cannot deselect it.
4. After conversion, you cannot manually select text using the mouse.

Here is my experimental example of your <addContent> button XML code to fix ToolBook v9.0 issues AND to demonsrate advanced insertion capabilities with this release:

  <addContent>
      <function name="myClick" event="click" params="evt,undef,target,mX,mY,isShift,isCntrl" useTB="true">
          <![CDATA[
              //Add next two lines to make sure the editable DIV conversion works as expected
              var o = gTBo('myText2', 'objRef');
              o.onclick = o.onmousedown = o.onmouseup = o.onfocus = null;

              tbfunction_userProperty("myText2", "contentEditable", true, "set");  //Conversion now allows setting cursor position with mouse, etc.

              //Next lines make TWO insertions using regular expressions to find the insertion position; HTML insertions are in red and orange respectively
              tbfunction_caretPosition("myText2", /line t/ig, "afterFirst", "<span style='color:red;'> ADDED </span>", false);
              tbfunction_caretPosition("myText2", /line t/ig, "afterLast", "<span style='color:orange;'> WEE </span>", true);   //This insertion keeps the inserted text selected
          ]]>  
      </function>        
  </addContent>

This latest release adds even more abilities to manipulate content. However, it can still get confused when trying to add HTML tagged content to already added HTML tagged content (results in nested HTML code). Seems as though you are limited as to how many nested insertions you can make before the function fails to find the correct insertion location. However, my guess it that this will be a relatively rare usage of caretPosition().

In the future, I may look at expanding caretPosition() to automatically unnest HTML code caused by adjacent insertions. However, this can get complicated!
 

[Clifton]

Glad it is working!

Try adding this folder to the exclusions list:
"C:\Program Files (x86)\PGSD ToolBook Plugins\PowerPac"

Hopefully that will cause MS Defender to just ignore that directory.
 

[John Robin Dove]

Ah! You must have seen my earlier post which I have now deleted. After the initial success with the test app, I got a bit carried away and tested the update on a text that has no <br> tags and, of course, there were no problems. But using a text containing a line break, in my current project, I still get the same error i.e. my marker character ˆ (chevron) is always wrong by 2. It should be ˆword but it's wˆord. I must try and find out what the difference is between the test app and my program. There is improvement because now the <br> tags are not disappearing as they were previously.

[Clifton]

Not sure how you are calculating the insertion point, but it is usually best to use regular expressions rather than simple words or phrases.
The more unique the phrase, the more accurate the calculated result will be.

Example:

   var cPos = tbfunction_caretPosition( "myField", /some unique word or phase/g, "beforeFirst" );  //cPos = calculated caret position

Locating position in a field with <br> tags (line breaks) can change the dynamics. Regular expressions will always account for exactly where you want to be. Of course, regular expressions may have to be more complex than the example above to yield consistent results in blocks of text with similar words or phrases.
 

[John Robin Dove]

You are absolutely right. The calculation of the insertion point is causing the error. I'll try and fix it but it will probably take some time...
UPDATE
Not yet fixed but I have a plan. I hope to adjust the insertion point by finding out how many line breaks there are between the start of the text and the start of the word. For each <br> the insertion point needs to be incremented by one. It may work. It may not. I'll try again tomorrow.

[John Robin Dove]

Hi Clifton,
I think I may have solved the problem. Please have a look here: https://www.mediacours.com/tb_examples/paras/ and I have put a zip here: https://www.mediacours.com/tb_examples/paras.zip. There may well be some remaining bugs. I have not had time to test it enough yet but it looks promising.
John

[Clifton]

I am working on yet another enhancement to caretPosition() which will allow insertions at any point in the HTML tree while still being able to calculate the cursor position accurately. The enhancement may or may not be useful to you, but would be important to round out how this is supposed to work. One advantage of this enhancement is that it should ensure caretPosition() can GET and SET the cursor position in nested content accurately.

BTW: Your example is working nicely!
 

[Clifton]

Just uploaded PowerPac v15.543.6.
This version is able to handle unlimited nesting of HTML in editableDIVs using caretPosition(). It is also considerably more accurate at finding and setting insertion points regardless of HTML code that may exist in the editableDIV.

This version may work better in your application. However, you may not be using it to its fullest extent to notice the upgraded features. Either way, let me know how it goes.

One thing to keep in mind is that when added HTML to an editableDIV, you should begin your tagged code with <div> or <span> tags. You can embed other tags inside these parent tags, but your HTML code should start with the parent tags. Also, do not forget to fix the quirky behavior of ToolBook v9 fields when converting them to editableDIVs. You should also set the display style of the field to "inline-block" with this function:

   var o = gTBo( "myEditableField", "objRef" );
   o.onclick = o.onmousedown = o.onmouseup = o.onfocus = null;
   o.contentEditable = true;   //Same as tbfunction_userProperty( "myEditableField", "contentEditable", "true", "set")
   tbfunction_pgStyleObject( "myEditableField", "display", "inline-block" );

I would also recommend adding at least a paddingLeft style to the editable field as it makes the contents a bit easier on the eyes. (Just an opinion, that's all.)
 

[John Robin Dove]

Hi Clifton,
Thanks for your reply. The new version is better but it still does not seem to be able to cope with multiple line breaks in a text. I shall need more time to test it properly. Unfortunately I don't have much time at the moment so it may be a day or two before I can give you a definitive answer.
John

UPDATE

just noticed that with the new version the test app I sent yesterday no longer functions. the values sent by tbfunction_caretPosition("myText2", -1); are anomalous.