* GEDMatch Fact text problems

[Gowermick]

I am using Janes Gedmatch fact, and want to show %age as reported by Ancestry

This works fine for 'Normal' %ages, but entering less than 1% as <1% won't work, as the < is treated as an ignore symbol

i.e, Using <1% 24cM 2 Segs, fails to show anything.

I know it is to do with way LUA treats text, but is there any way round it? (I tried <<, but that don't work )

Do I have to use Less Than 1%, or is there a way to get < to print/display

[tatewise]

Try using the \ escape character.

Where exactly is your <1% text?
Which field is it in and where are you displaying it? Diagrams, Reports, etc?
You know all those details but we don't so are guessing a workaround.

Why are you mentioning LUA? That only applies to Plugins.

[Gowermick]

Mike,
Jane’s query that accompanies this fact, extracts the text and displays it in the resultset table!
When I use the <, nothing displays. I’ll try the \ escape character when I’m back on my PC. ( I was using the extra < as an escape, but obviously it didn’t work )

NB. I only mentioened LUA because I thought FH was written in LUA. Only reason I could think of to prevent < being treated as normal text!

[ColeValleyGirl]

The underlying format for rich text notes relies on the < and > characters, hence they need escaping.

[tatewise]

Unfortunately, the FH Note Window help page does not mention the \ escape character needed for special characters like < and is only mentioned in the Plugin API help for Rich Text Syntax. So how are users meant to know how to include literal special characters? IMO that omission should be reported to CP.

FYI: FH is written in Microsoft Visual C++ and only Plugins use LUA.

[ColeValleyGirl]

FYI: FH is written in Microsoft Visual C++ and only Plugins use LUA.

Perhaps worth mentioning that the standard language packs installed with FH of course use Lua; and so do some of the standard reports.

[Gowermick]

I’m not complaining, but why did CP feel the need to introduce another Language? What is wrong with wrinting plugins in C++? I would suggest that C++ has a greater userbase than LUA

[ColeValleyGirl]

Lua is very commonly used for user-written 'plugins'/'scripts'/ (or whatever another programme calls the equivalents.) Plus, it's much more light weight than C++, and doesn't need to be compiled, which rules out C++ (Who is going to ship a C compiler with their programme? Not Calico Pie, I suspect ). And, for non-programmers who don't come with any heavy-weight programming language baggage, it's probably easier to learn...

[Gowermick]

Try using the \ escape character.

Where exactly is your <1% text?
Which field is it in and where are you displaying it? Diagrams, Reports, etc?
You know all those details but we don't so are guessing a workaround.

Why are you mentioning LUA? That only applies to Plugins.

Thanks Mike, \ worked a treat

[tatewise]

FYI: FH is written in Microsoft Visual C++ and only Plugins use LUA.

Perhaps worth mentioning that the standard language packs installed with FH of course use Lua; and so do some of the standard reports.

I presumed the term Plugins includes Standard Plugins, Language Plugins, Report Plugins and Source-Driven Data Entry Plugins (which you forgot to mention) that are all mentioned in Special Plugin Types within the How to Wite Plugins help pages.

[ColeValleyGirl]

I didn't forget to mention anything. I pointed out that some standard elements of Family Historian (i.e. elements installed by the FH installation process) are now coded in Lua. They may use the plugin architecture, but they aren't per se plugins.

[ColeValleyGirl]

Just returning to the original question:

"Jane’s query that accompanies this fact, extracts the text and displays it in the resultset table!"

An ordinary query displays the < without a problem:

Screenshot 2022-09-13 133750.jpg (41.79 KiB) Viewed 862 times

So in theory a user never needs to know about the escape characters? So I wonder why it's necessary in this case...

Updated: the issue seems to be in GetLabelledText.

[Gowermick]

Helen, good point.
I have never had to consider ‘Rich Text’ special characters before, and as far as I was concerned Jane’s query was just extracting my plain text. One for CP perhaps?

[ColeValleyGirl]

Agreed, Mike L. Will you report it or shall i?

[tatewise]

Yes, =GetLabelledText(...) works fine with fully formatted Rich Text Notes that automatically escape any explicit < character.

The problem is when =GetLabelledText(...) operates on unformatted Note text and that text contains a Rich Text control character such as < that should be treated as plain text, but is treated as Rich Text so the subsequent text is discarded.

[Gowermick]

Agreed, Mike L. Will you report it or shall i?

Oh well, if you insist

Ticket 114495 has been created

[Gowermick]

CP accepts there is an error, and will fix it on next update