[SOLVED] Problem with some characters in a combobox editor
lazarus / 49-FPSpreadsheet

----------------------------------------------------------------------
fmolina · 2020-12-29 11:42

Hi,
This topic is related to:
.https://forum.lazarus.freepascal.org/index.php/topic,50554.msg369196.
html#msg369196
and
https://forum.lazarus.freepascal.org/index.php/topic,50514.msg368772.h
tml#msg368772

Comboboxes work correctly, but in a particular one the items are
'--.,<,≤'; when I click in the cell, the list drops down correctly,
but when the '<' item is selected and one moves to another cell,
nothing remains in the cell. This is surely due to the fact that '<'
is the start of html tags. But if the list of items is
'--,'+'&lt;'+'≤' I get the '<' shown correctly after the selection,
but in the drop down list I see '&lt;' verbatim displayed. How can I
solve this, can I use some event to catch the case of '<' to replace
it by '&lt;'? Tried with OnValidateEntry but does not seem to work.
Thanks

----------------------------------------------------------------------
wp · 2020-12-29 12:04

Can you show code how you implemented the combobox for the
fpspreadsheet grid? A compilable example would be fine.

----------------------------------------------------------------------
fmolina · 2020-12-29 13:41

Here you are. Please look at the two first cells of column 1. In the
first, when one selects '<' the cell is not changed. In the second,
'&lt;' is displayed in the list.

----------------------------------------------------------------------
wp · 2020-12-29 19:04

Thinking over this issue again I find that replacing the '<' by &lt;
was a bad idea because this string is written into the file rather
than the '<', and this will look strange, when the file is opened in
Excel or Calc. Similarly when you open a file written by Excel/Calc
which has a '<' in one of its cells (or '< 1', or similar) there will
be a display problem because of the incomplete html. Maybe it was a
bad idea at all to introduce html for the individual character
formatting ("rich text" in Excel words)...

There is still a workaround: I think it should work when the html
analyzer does not return an empty string when the input string is
invalid html, but takes the string literally. This way the '<' should
remain as it is.

I checked it and it is working. But I did not yet do too much testing,
probably there are sideeffects which must be fixed...

If you do not use fpspreadsheet trunk you can fix your version easily.
Load unit fpshtmlutils.pas and find the procedure HTMLToRichText. In
the "try" block insert the code marked below
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i begin 
ARichTextParams := nil;  analyzer := TsHTMLAnalyzer.Create(AWorkbook
as TsWorkbook, AFont, AHTMLText + '<end>');  try   
analyzer.PreserveSpaces := true;    analyzer.Prefix := APrefix;   
analyzer.Exec;    APlainText := analyzer.PlainText;     // HTML text
has an error --> take the input text literally    if (AHtmlText <> '')
and (APlainText = '') then    begin      APlainText := AHtmlText;    
ARichTextParams := nil;      exit;    end;     nrtp :=
Length(analyzer.RichTextParams);  ....
In method TsHTMLAnalyzer.TagFoundHandler() there is another
modification: Add this "else" branch to the "case" instruction:
Code: Pascal  [Select][+][-]window.onload = function(){var x1 =
document.getElementById("main_content_section"); if (x1) { var x =
document.getElementsByClassName("geshi");for (var i = 0; i   ....   
'/': case NoCaseTag[3] of           'B': if (NoCaseTag) = '</B>' then
ProcessFontRestore;           'D': if (NoCaseTag) = '</DEL>' then
ProcessFontRestore;           'E': if (NoCaseTag) = '</EM>' then
ProcessFontRestore;           'F': if (NoCaseTag) = '</FONT>' then
ProcessFontRestore;           'I': if (NoCaseTag = '</I>') or
(NoCaseTag = '</INS>') then ProcessFontRestore;           'S': if
(NoCaseTag = '</S>') or (NoCaseTag = '</STRONG>') or                 
 (NoCaseTag = '</SUB>') or (NoCaseTag = '</SUP>') then
ProcessFontRestore;           'U': if (NoCaseTag = '</U>') then
ProcessFontRestore;         end;  else      FPlainText := FPlainText +
ActualTag;  end;end;
With these modifications you can also enter strings such as '<first
name>, <last name>' or  '<>1', they are displayed correctly by Excel.

----------------------------------------------------------------------
fmolina · 2020-12-29 22:30

Thank you!
I will do some checking. For me, should not be a problem because this
will never get into a file. But it is interesting the problem. Perhaps
can be solved in the future by somehow marking or tagging the html
cells. Just a first thinking.

----------------------------------------------------------------------
fmolina · 2020-12-30 12:44

Hi,
Sorry, but something has gone wrong. Teh <end> tag is appended to '<'.
See image attached. I am also attaching the modified source file, 
just in case.

----------------------------------------------------------------------
wp · 2020-12-30 13:32

How does the <end> tag get there? What did you type into the cell?

----------------------------------------------------------------------
fmolina · 2020-12-30 21:02

I did not type anything. Just selected the '<' in the combobox and
clicked in another cell

----------------------------------------------------------------------
wp · 2020-12-30 22:26

OK, there were several cases in which the changes of the previous
commit were not seen. It is fixed now (but there may still be some
more issues...)

 I assume that you don't use svn. It is probably the easiest solution
if you pick up the latest version of the fpsHTMLUtils unit from the
internet (https://sourceforge.net/p/lazarus-ccr/svn/HEAD/tree/componen
ts/fpspreadsheet/source/common/fpshtmlutils.pas) and copy it over your
version - I hope that the trunk version is compatible with yours;
therefore, you should make a backup copy of your file before copying,
just in case that sometheing goes wrong.

----------------------------------------------------------------------
fmolina · 2020-12-31 00:28

It works for me now. However, my use at this time is limited to the
combobox; not sure if there are other problems. If I find some I will
report. Thanks and Happy New Year!

----------------------------------------------------------------------
wp · 2020-12-31 13:20

No, the issue was not related to the combobox, it occurred also when
simply typing some text with reserved html characters. A Happy New
Year to you, too.