Over-typing in some span/divs goes ... elsewhere

[kevinmcl]

I'd be obliged if some other Flare users would try a little test, to see if I'm the only one....

- create a topic with several paragraphs - enough to need scrolling,
- create/insert some expanding text in one of those paragraphs (I think it works with Drop-down as well, but it's reliable with expanding text)
- save and close
- re-open for editing in the Flare WYSIWYSG editor
- be in "insert" typing mode
- select a few words within the expanding text span
- start typing some replacement characters
- observe if the over-type works for only the first character, and the remaining characters that you type don't get inserted where the selected text was located.

If your insertion point jumps elsewhere in the document after the selected text is overwritten by just the first character that you type, please let me know that I'm not the only crazy one.

Note: Don't select and delete before typing new text. Just select and start typing.
For me, the select-and-overtype seems to work in body text and some other places, but if I try it in Expanding text (drop-down too, I think), then I get the jumping insertion point.

I'm using Flare 7.2 on Windows 7.

-kevin

[LTinker68]

If your insertion point jumps elsewhere in the document after the selected text is overwritten by just the first character that you type, please let me know that I'm not the only crazy one.

It happens to me sometimes in override mode outside of drop-down effects, so I don't think it's specifically related to those two conditions. It seems like it tends to happen after you open a topic and you try to double-click on text before having the cursor "active" in the window. It seems like after opening a topic you have to first click in the topic first to give it focus and place the cursor in the content, then you can double-click on text and replace it.

[kevinmcl]

Here is where I think the typed text went, after my insertion point jumped, unbidden. Scroll to see the yellow highlight and red "circles".

Flare_hidden_stray_text_viewed-in-browser.PNG

That's the published output, viewed in a browser.

But here (below) is what it looks like in the Flare WYSIWYSG* browser (I went to <t> text mode after I could NOT see the "eh" and the "o" in the formatted view... didn't help.

Flare_hidden_stray_text_viewed-as-text-in-Flare_editor.PNG

But here (below) is what it looks like in Notepad. I've highlighted the same section in all three captures, and shown with red shakey-circles where the bogus text lives.

Flare_hidden_stray_text_viewed-in-notepad.PNG

Hiding it like that is fiendish, don't you agree?
At NO time did I deliberately move my cursor to those two locations and type "eh" and "o" and somehow insert startbreak and endbreak tags surrounding them. Yet, there it is in Notepad. So, somehow Flare decided to do that.

To preclude the obvious questions, I added the words "Heinz Ketchup" to the text of step 10, before publishing again and taking all three screen captures, so there's no chance that I was looking at old source or old published output.

My question is why/how Flare inserts something that it can't (or doesn't want to) display in the WYSIWYSG editor.
OK, that's one of several questions, but it's even more disturbing than the question about why the cursor jumps erratically.

Now I have to go back and get that Ketchup stain out before customers see it...

- kevin

WYSIWYSG* - What You See Is What You Sorta Get