* Testing Ancestral Sources v7.6.4

[NickWalker]

Updated this post on 26th Nov 2022 to reflect release of new test version v7.6.4 described below

Hot on the heals of v7.5 (released just over a week ago), I've produced another version for testing in advance of release.

New Features in v7.6 (Beta Test)

• The Census Source Conversion screen can now also be used to convert existing rich-text source text that doesn't have hyperlinked individuals into a version that does. This works by first converting the rich-text back into plain text and then taking it through the usual conversion routine. A few users requested this.
• There is now a new button and right-click context menu to insert a hyperlinked individual into rich-text.
• Web urls can now be pasted into rich-text source text and notes and should appear as hyperlinks. Double-click on the hyper-links to edit the URL and/or to change the display text.
• There is now a new Auto-text function =COMMAINDEX which will return a specifed item from a comma separated list. This could be used to access specific parts of a place definition which is something that Chris Read requested.
• Using the Customise option to change the font or colour scheme caused some data to disappear on the main screen (in particular the data in the census grid). This is now fixed.
• Fixed an issue reported by Peter Rollin where an error appeared when loading AS without a default project and with the option to show Custom IDs
• If a hyper-linked individual was double-clicked with a cell selected an incorrect name was shown. This has now been fixed.
• Peter Rollin spotted that the {INDIVIDUAL.CUSTOMID} didn't always show if included in the source title template. This is now fixed.

Regarding the first bullet point, to trigger the conversion of existing rich-text census sources into rich-text with hyperlinked individuals you need to untick 'plain text sources only' and then tick the 'No hyper-linked individuals only'.

Changes in v7.6.1 (Beta Test)

• Fixed a glitch with the conversion of rich-text without hyperlinks to hyperlink version where it didn't always line up the data correctly. Thanks to Bill Henshaw and Chris Read for reporting this.
• The =COMMAINDEX function will now also accept a negative index with -1 return the data after the final comma, -2 the data before that and so on. This was suggested by Mike Tate.
• Added a FULL sub-tag to PLACE and ADDR tags to return the untidied versions of the place/address as the Autotext Place/Address Tidy option can remove commas which then produces unpredictable results when using the =COMMAINDEX function.
• Fixed an issue where more unusual characters didn't always display correctly in rich text. Thanks to John Morrison for reporting this.
• If the Image Viewer option to "enter your own title" was selected by default it didn't enable the associated text box. This was reported by David Cooper and is now fixed.
• Made some improvements to resolve an issue reported by David Cooper where emboldening selected text produced unexpected results.
• Colin McDonald reported that deleting rows from the rich-text table can sometimes produce strange results. I'm hoping this is now working correctly within the limitations of the rich-text control I'm forced to use.

Changes in v7.6.2 (Beta Test)

• Fixed an issue reported by Bill Henshaw on the census source conversion screen where the rich-text box occasionally wrongly assumed a manual edit had taken place and turned off auto-text.

Changes in v7.6.3 (Beta Test)

• Fixed an issue reported by Bill Henshaw on the census source conversion screen where the rich-text box occasionally wrongly assumed a manual edit had taken place and turned off auto-text.

[/list]
Changes in v7.6.4 (Beta Test)

• On the source conversion screen, if things go wrong when saving the file this should now be handled better. This change was inspired by a problem reported by John Morrison.
• Colin Spencer reported a problem when running 7.6.3 on Crossover for Mac. I don't know why the error would appear and assume it is a Crossover issue, but I've trapped the error so hopefully it won't appear in future.

The 64 bit version is available to test here: Ancestral Sources v7.6.4 64 Bit
The 32 bit version is available to test here: Ancestral Sources v7.6.4 32 Bit

Please report in this thread any issues you spot or email me (nick at ancestralsources dot com).

[neil40]

Thanks again Nick

One thing that strikes me, perhaps a minor thing, with the Census conversion tool, is that once you select a Census to Convert, should you want to go back to the initial conversion tool screen, you can only close the tool and re-open it.
EG, you had Plain selected, select a census, but changed your mind and want to go back to select 'No Hyper-linked' you can't.
Unless I've missed something.
As I say, it's minor and easily re-opened.

[NickWalker]

I'm not entirely happy yet with the way this facility is selected with the check boxes - I added this fairly quickly last night and thought I'd rather get it tested and work on it while the testing continues. However, are you aware you can click the little down-arrow expand button once you've selected a source so you can change the filtering?

[ChrisRead]

Did a quick test of the RT Plain to RT Linked, and after figuring out the check boxes, it seems to work as expected. I now just have a four hundred or so census sources to convert but at least it should be quick compared to re-doing them all over again from scratch or manually updating the RT.

I think I have recalled where I wanted to use the COMMAINDEX at least initially. It was to extract the county from the place/address for headings of Parish register entries
i.e. Marriage Solemnized at .... in the County of =COMMAINDEX[2,{PLACE}]
I also had some others where I wanted to do similar.

[NickWalker]

Not necessarily helpful to you Chris but may be to others: If your places vary in the levels you use you could potentially do something clever with the IF function.

For example the following query will return either the 2nd or the 3rd item in the Place depending on which is the last. I've added the colours to show where the 3 COMMAINDEX functions are nested in the IF function.

=IF[=COMMAINDEX[2%{PLACE}]%=COMMAINDEX[2%{PLACE}]%=COMMAINDEX[1%{PLACE}]]

e.g. regardless of whether the place has been recorded as Eccleston, Lancashire or as Eccleston, Prescot, Lancashire it will return Lancashire.
The logic is: IF the 3rd element (index 2) of the Place has data in it then return the 3rd Element, otherwise return the 2nd element (index 1).

[ChrisRead]

Yes, I've used =IF in various places, to be 'clever' but was keeping it simple.

I've done some conversions now. The auto-next means it's even quicker at least for 1841. I have found an issue when I got to 1851. The conversion slips the birth location to the Infirmity column where the occupation is blank, even though the empty column is there as | |

The tool does at least allow quick shifting of contents back left a column, but I assume it's an oversight in the RT to Plain conversion or something, not had time to investigate and now have to go out for the day.

[NickWalker]

No problem I will do some testing later - I really did put this together very quickly last night so it isn't a total surprise that there may be glitches!

[David2416]

I have been testing the new COMMAINDEX function. Works well in the Source Title for 1891 Census.

I notice that the examples in Title Template Data References thread omit the % signs

So you could have =COMMAINDEX[0,{PLACE}] or =COMMAINDEX[1,{OTHER}], etc.

The slight issue is if there is nothing before the first comma:
Eg:
, Huntingdon Street, Islington, Middlesex, , England gives Middlesex Islington Huntingdon Street
but
22, Huntingdon Street, Islington, Middlesex, , England gives Islington Huntingdon Street 22

Am using =COMMAINDEX[3%,{PLACE}] =COMMAINDEX[2%,{PLACE}] =COMMAINDEX[1%,{PLACE}]

[NickWalker]

I notice that the examples in Title Template Data References thread omit the % signs

So you could have =COMMAINDEX[0,{PLACE}] or =COMMAINDEX[1,{OTHER}], etc.

Thanks - I'll correct that.

The slight issue is if there is nothing before the first comma:
Eg:
, Huntingdon Street, Islington, Middlesex, , England gives Middlesex Islington Huntingdon Street
but
22, Huntingdon Street, Islington, Middlesex, , England gives Islington Huntingdon Street 22

Am using =COMMAINDEX[3%,{PLACE}] =COMMAINDEX[2%,{PLACE}] =COMMAINDEX[1%,{PLACE}]

I can investigate any issues with this later and haven't really looked at your examples yet. But just to be clear, are you deliberately including the commas after the % in the COMMAINDEX commands and if so for what reason? And what would you expect the output to be in the 2 examples you give?

[lastejas]

Hi Nick,
This is not to actually do with the testing of version 7.6 but as you are releasing a new version could you possibly add "England and Wales" to the census region list as most of the earlier census are known as eg. 1851 Census of England & Wales ... rather than 1851 Census of England ... or 1851 Census of Wales ...

Thanks

[David2416]

I can investigate any issues with this later and haven't really looked at your examples yet. But just to be clear, are you deliberately including the commas after the % in the COMMAINDEX commands and if so for what reason? And what would you expect the output to be in the 2 examples you give?

Thanks for your reply Nick.
Those commas after the % are unintentional (I'd worked from the example in Title Template Data References thread and then spotted the % above. I have now corrected that.

So my template code is now:
=COMMAINDEX[3%{PLACE}] =COMMAINDEX[2%{PLACE}] =COMMAINDEX[1%{PLACE}]

Entering as PLACE Barrack Cottage, Green Lane, Great Ilford, Essex, , England

I would want the result to be Essex Great Ilford Green Lane which is what I get using the above,

but if I omit Barrack Cottage and entering PLACE as , Green Lane, Great Ilford, Essex, , England
(Place now has a leading comma - putting a space before the comma doesn't help.)

I get England Essex Great Ilford whereas what I want is Essex Great Ilford Green Lane as above.

It's great that I can now paste in an active weblink in notes.

Thanks David

[tatewise]

Nick, regarding =COMMAINDEX[n%Place] the n currently counts from left to right.
Would it be useful for negative values of n to count from right to left, rather like the FH =TextPart(...) function?
So, =COMMAINDEX[-1%Place] would return the last comma-separated part and =COMMAINDEX[-2%Place] the penultimate part.

You could go one step further and make it just like =TextPart(...) and have two numerical parameters that define the start and quantity of parts. For consistency, it might be better called =TEXTPART[n%m%Place]

Or it could be generalised along the lines of the FH =Section(...) function, and allow the separator to be a parameter too.

[NickWalker]

Hi Nick,
This is not to actually do with the testing of version 7.6 but as you are releasing a new version could you possibly add "England and Wales" to the census region list as most of the earlier census are known as eg. 1851 Census of England & Wales ... rather than 1851 Census of England ... or 1851 Census of Wales ...

Thanks

The problem is that the templates are different for Wales and England as there is a language column, e.g. in 1901, etc. so the countries need to be different.

If you're concerned about what is being displayed in a source title or the autotext then a formula could be used for this that says "if the country is England or the country is Wales then display England and Wales, otherwise display the country":

=IF[=OR[=EQUALS[{COUNTRY}%England]%=EQUALS[{COUNTRY}%Wales]]%England and Wales%{COUNTRY}]

So if you put this in place of the {COUNTRY} in the auto-text template or the source title then it should display correctly for you. Ask if you're not sure.

[NickWalker]

Nick, regarding =COMMAINDEX[n%Place] the n currently counts from left to right.
Would it be useful for negative values of n to count from right to left, rather like the FH =TextPart(...) function?
So, =COMMAINDEX[-1%Place] would return the last comma-separated part and =COMMAINDEX[-2%Place] the penultimate part.

You could go one step further and make it just like =TextPart(...) and have two numerical parameters that define the start and quantity of parts. For consistency, it might be better called =TEXTPART[n%m%Place]

Or it could be generalised along the lines of the FH =Section(...) function, and allow the separator to be a parameter too.

Thanks Mike, I'll have a think about this. I had considered the 'generalised' idea in your final sentence but I decided to keep it simple as the use cases all seem to be related to commas and I couldn't really see where else it might be used. I do have some plans for a future project I have in mind which might require me to include Loops. It's been an interesting project over the years to develop my own programming language as part of AS!

[neil40]

I'm not entirely happy yet with the way this facility is selected with the check boxes - I added this fairly quickly last night and thought I'd rather get it tested and work on it while the testing continues. However, are you aware you can click the little down-arrow expand button once you've selected a source so you can change the filtering?

Aha, no I didn't. Thanks for that.

[lastejas]

I think I have recalled where I wanted to use the COMMAINDEX at least initially. It was to extract the county from the place/address for headings of Parish register entries
i.e. Marriage Sol emnized at .... in the County of =COMMAINDEX[2,{PLACE}]
I also had some others where I wanted to do similar.

This would not give the correct value as the text used in the original document is not the County Name, ie Cheshire, Lancashire, Yorkshire etc it should be Chester, Lancaster, York etc.

[NickWalker]

I think I have recalled where I wanted to use the COMMAINDEX at least initially. It was to extract the county from the place/address for headings of Parish register entries
i.e. Marriage Sol emnized at .... in the County of =COMMAINDEX[2,{PLACE}]
I also had some others where I wanted to do similar.

This would not give the correct value as the text used in the original document is not the County Name, ie Cheshire, Lancashire, Yorkshire etc it should be Chester, Lancaster, York etc.

As I repeatedly say, the auto-text can only ever make a good attempt at generating a transcription automatically. It almost always needs to be edited before you save it. However, It would be possible to have a series of nested =IF functions that would look for these special cases if you wanted to.

[lastejas]

I understand fully that Autotest is only making a best quess and that editing will nearly añways be required to fine tune. I was just commenting that what Chris said would not give the correct result.

Re the Region question I was only trying to match up AS with FH7 which has England and Wales as one of the default regions in the Census Template. I appreciate your solution offered for the Autotext but I think I will continue to do it manually.

[David2416]

Personally I find AS does an excellent job, and the last few releases have enhanced that. I am very grateful for it.

I always review the created source and facts and make adjustments if necessary. Sometimes it is often not.

[ChrisRead]

I think I have recalled where I wanted to use the COMMAINDEX at least initially. It was to extract the county from the place/address for headings of Parish register entries
i.e. Marriage Sol emnized at .... in the County of =COMMAINDEX[2,{PLACE}]
I also had some others where I wanted to do similar.

This would not give the correct value as the text used in the original document is not the County Name, ie Cheshire, Lancashire, Yorkshire etc it should be Chester, Lancaster, York etc.

Yes, I'm aware there are variations such as County of York, but I can live with with it being Yorkshire in the transcription as I'm not after perfect, just close enough to be reasonable without the need for lots of post-auto text editing. In practice, I can capture most things with the auto-text templates I've done with close facsimiles of the various register styles. Given I almost always have the original image in the source media it's not an issue as I can look at that anyway if needed.

[lastejas]

Ok I'll stop being pedantic, but I thought "Text from Source" was supposed to be a true transcript of the document not an interpretation, my mistake. Subject Closed.

[johnmorrisoniom]

Just discovered a problem that has existed a while (Since at least 7.0.3)

I have several relatives with the name Cæsar ??? when entering or converting a census the autotext looks alright in AS but ends up in FH as C???. The same name in the source title is OK though

Back to ver 7.6 when converting RTF sources to link names the columns all get shunted 1 place left so the name header is actually over the relationship column. It doesn't happen every time though. EDIT Seems to happen on sources created with AS 7.0.3, but not on sources created with 7.0.4

It is not a major problem to sort out though.
I've converted about 50 this afternoon, only another 380 RTF sources to go, leaving about 3560 lain text sources to do.

I could probably go faster , but I am double checking images at the same time and found a couple of incorrect image links at the same time.

[ChrisRead]

A quick check, but is the Fit button on converted (Unlinked RT to Linked RT) supposed to re-fit the grid, as it appears to do nothing at present. Or at least it seems so as there are some quite wide columns with blank space generated, and I thought they'd get shrunk a bit.

I just checked, and it seems a Fit does occur when you shift columns (i.e. due to right slipped birth place on blank occupation). The Where Born column does not appear to be shrunk as much as I'd have expected.

[NickWalker]

A quick check, but is the Fit button on converted (Unlinked RT to Linked RT) supposed to re-fit the grid, as it appears to do nothing at present. Or at least it seems so as there are some quite wide columns with blank space generated, and I thought they'd get shrunk a bit.

I just checked, and it seems a Fit does occur when you shift columns (i.e. due to right slipped birth place on blank occupation). The Where Born column does not appear to be shrunk as much as I'd have expected.

Hi Chris. You may need to adjust the Tools->Options->General Settings - source text->Column Width Adjustments. The font and the font size that is set in the Tools->Customise can potentially be very different to that set for the default rich text font (which defaults to the FH settings) so the column adjustment % can compensate for that. Try 9%.

[NickWalker]

Ok I'll stop being pedantic, but I thought "Text from Source" was supposed to be a true transcript of the document not an interpretation, my mistake. Subject Closed.

I think it's all down to our own preferences. I know some people like to make the transcript as exact a possible but for me I want it to reflect the data in the source but I don't personally, for example, bother changing Latchford, Cheshire to Cheshire, Latchford if that's what it says in the original source because it doesn't make any difference to the data recorded. But if it said FS, I'd record the occupation as Female Servant and then change it to FS in the transcript because it's of interest that it was recorded that way. If I want to see exactly how everything was written I've got the image linked to do that.