Family Historian User Group

Has anyone else experienced weird behaviour when using Tab key to enter data?

for example
Press Add fact, select Census press <CR> and bottom of property box is populated with Census fact fields as expected
Question 1 - where does Insertion point go, as I need anotherTab to get it to the Date field!

Once in the Date field, I enter a date, press Tab and nothing happens (i.e. insertion point disappears again), press another Tab and insertion point returns to Date field, with date highighted , then it needs yet another Tab to get to Age field!

This is not restricted to Census facts, as a similar situation occurs when adding an Occupation fact

It would appear there are serious issues with the tab order!

Question 1 It selects the fact in the fact list.

I have not been able to reproduce your reported problem with the tab on the date field.

Neither can I (that's not repetition, it's constructive addition.. ). Entering a date then pressing the tab key moves the insertion point to the next data entry field, as expected. As far as I can tell, the tab order is correct throughout the Property Box. It is possible to change the tab order when designing the form, but getting that right is so basic that CP would routinely check such things before release.

Jane wrote: ↑

12 Aug 2021 13:15

Question 1 It selects the fact in the fact list.

I have not been able to reproduce your reported problem with the tab on the date field.

Ah, I see it now, but it would make more sense to place Insertion Point in first of the newly populated fields.

As for the second comment, I have just shut down and re-started FH and problem still persists for me, and is repeatable

Mark1834 wrote: ↑

12 Aug 2021 13:22

Neither can I (that's not repetition, it's constructive addition.. ). Entering a date then pressing the tab key moves the insertion point to the next data entry field, as expected. As far as I can tell, the tab order is correct throughout the Property Box. It is possible to change the tab order when designing the form, but getting that right is so basic that CP would routinely check such things before release.

Mark, which field does it go to after pressing Tab on date field? and how did you get to the date field in the first place?

In my case, after eventually getting to date field, when I press Tab, focus shifts back to the fact in the fact list (as Jane mentioned), another Tab brings me back to Date field then another Tab takes me onto Age field.

Your last comment is a bit redundant, as I'm fully aware that Tab order is pretty basic, that's why I raised the question in the first place

I too have been seeing this, very odd after entering a date, Tab has to pressed a couple of times to get back to the date field then is tabs correctly to age, address etc. This did not happen in previous versions and I cannot explain it.

OK - I don't do telepathy very well, so I'd rather tell you something that you already know than assume you know something that you don't...

Create the fact, so it is highlighted. Press the tab key to move the insertion point to the first data field, which is usually Date for an Event. Press tab to move between fields in the order on the form, or shift-tab to move in reverse order.

It sounds like the insertion point is moving backwards for the first data entry. What happens if you select an existing fact, and keep pressing tab?

Is tab order completely normal in other apps? If not, it might be a problem with your keyboard. Sticky shift key? Weak battery? Corrupted driver? Have you got another keyboard you could try?

Curious - two similar examples is quite a coincidence. Same questions to David. Is it intermittent, or consistent? All projects or just one? If it is an odd bug, the more information CP have to track it down the better.

It is consitent and doesn't appear on any other applications. I just did a test, added a death, entered a date, pressed Tab and the Fact became highlighted, pressed Tab again and the highlight moved back to the date then behaved normally. Not the end of the world, just a bit irritating.

Mark1834 wrote: ↑

12 Aug 2021 14:02

Create the fact, so it is highlighted. Press the tab key to move the insertion point to the first data field, which is usually Date for an Event. Press tab to move between fields in the order on the form, or shift-tab to move in reverse order.

Mark, that is what should happen, but as I said it ain't doing that.
After creating a fact, and entering a date, Tab takes me back to fact list (which is wrong!), further Tabs step through the fields as they should.
It also steps though field correctly for existing facts.

The bug seems to occur only during creation of a new fact, and in my case, is consistent and repeatable. As David has seen it too, it tends to rule out my PC so I'll raise it with CP, and see what they have to say.

As David has just said, not the end of the world, but to me, a little more than irritating, as it means one has to carefully note where cursor is before ploughing on, adding details.

Support ticket 345316 raised

For what it is worth, my Tab key behaves as expected.
After adding a fact the focus is on the new fact in the top pane of the Facts tab.
Hit the Tab key and focus moves to the first field in lower pane, usually Attribute value or Date.
Enter an Attribute value or Date value and hit Tab again to confirm the value and move focus to the next field.

It does not matter if Property Box is docked or floating, or whether the Source Citation window is open.

Does the problem happen regardless of the Date format entered? What if is just a year?

Does the problem happen with Attribute facts and their value field or only their Date field?

Also FWIW, my tab key works as expected (also not duplication but constructive confirmation).

Create a fact -- focus is the fact that was created (which doesn't seem odd to me). Tab then steps through the fact fields in order.

tatewise wrote: ↑

12 Aug 2021 14:41

For what it is worth, my Tab key behaves as expected.
After adding a fact the focus is on the new fact in the top pane of the Facts tab.
Hit the Tab key and focus moves to the first field in lower pane, usually Attribute value or Date.
Enter an Attribute value or Date value and hit Tab again to confirm the value and move focus to the next field.

It does not matter if Property Box is docked or floating, or whether the Source Citation window is open.

Does the problem happen regardless of the Date format entered? What if is just a year?

Does the problem happen with Attribute facts and their value field or only their Date field?

The problem occurs with both events and attibutes (e.g. Census and Occupation) regardless of date format used. (e.g. 1891 or 5 Apr 1891) ( I initially thought it a problem with autohotkey, but have since discounted that, as it also happens when I type full date in myself)
The problem seems to occur when tabbing from the date field only, when cursor is taken back to fact in fact list. Tab behaves normally from then on stepping through fields as expected.

I've noticed this behaviour recently and it is very annoying. When entering Birth, Baptism and Death facts manually on the facts tab, I would normally enter the Date, tab to Age, tab to Place, just two keystrokes. Now I enter the Date, tab, and the highlight has gone up to the Fact. Tab again, back to the Date, tab to Age, tab to Place - four keystrokes and it throws the routine right out. Oddly it does not happen when entering Burial details, where there is no Age field, although it does happen for Birth where the Age field is greyed out.

I'm pretty sure this is a new thing, not a V7 thing.

Just had a remote session with Simon, and we 'Think' we know the cause, but not necessarily the answer.

In my FH, I had disabled the Age field of the Birth fact, which seems to cause the problem. Enabling this Age field and tabbing works as per normal.

Simon has gone away to see why, but for those with the problem, the quick solution is go to Tools, Fact Types, and Edit the Birth fact and in the Fields Required ensure the Age field is ticked.

It works for me, and explains why most of you don't see the problem, as I suspect they already have this field ticked.

Could I ask those with the problem, confirm they had also disabled the Age field for the birth fact.

UPDATE: Simon has found the problem, and the fix will be included in next up date- Thank You Simon

I had disabled the Age field, having ticked it tabbing seems to normal. I always thought it a bit daft having an Age field for a birth, as by definition it has to be zero, Age applies for birth registration though. Thank you for dogged research to pinpoint the cause.

This problem claims to be fixed in FH v7.0.8.2 that is currently being trialled.

Age at Birth is a recurrent topic and supports the GEDCOM requirement for values Infant and Stillborn.

From memory Age at birth caters for the special case of Stillborn so isn't really daft

tatewise wrote: ↑

08 Sep 2021 09:14

This problem claims to be fixed in FH v7.0.8.2 that is currently being trialled.

Is it still being trialled or is it released? You can download it from the FH website under Downloads and is called "Latest Free Update", and is listed on the V7 updates page. I'm never quite sure how CP treat releases!

It's being trialled via a 'soft release' process - available if someone downloads it but not publicised except to people who had reported bugs that it fixes. If there's nothing spectacularly wrong with it it will eventually become visible if you check for updates.

dewilkinson wrote: ↑

08 Sep 2021 07:58

I had disabled the Age field, having ticked it tabbing seems to normal. I always thought it a bit daft having an Age field for a birth, as by definition it has to be zero, Age applies for birth registration though. Thank you for dogged research to pinpoint the cause.

I agree, wholeheartedly, but it is part of Gedcom definition, as Miketate said, to cover for stillborn birth. Personally I think it wrong, as stillbirths are covered by the death at age 0. Whichever way you look at it, everyone is aged 0 at birth, (unless you can prove otherwise ), so field is rather redundant, and I fail to see why it was included in Gedcom definition in the first place.

Nevertheless, that is the reason Simon included the age field for births, i.e. to comply with Gedcom!

Somebody can die at age 0 but not be Stillborn. I recently discovered an aunt of whom that was true - born alive died within an hour. She would recorded as died age 0 not Stillborn and I am very certain that hour made a huge difference to her parents

Stillborn is death before or during birth not age 0

I'd agree with Helen - in English & Welsh practice (and presumably over the rest of the UK?) it is not correct to refer to death in relation to a stillbirth as the child never lived. From 1927 on, there has been a stillbirth registration process in England & Wales (at least) (thanks to MJ Ashby for that).

Having said that, note that there are many caveats - see viewtopic.php?f=32&t=12883&p=63140 where I mention a US Death Certificate labelled as a still-birth. Apparently equivalent terms in other languages may also have subtle differences, as I found out in the FamilySearch GetSatisfaction forum where Scandinavian(?) priests were more concerned about whether baptism had happened rather than the child had drawn breath.

AdrianBruce wrote: ↑

08 Sep 2021 13:25

it is not correct to refer to death in relation to a stillbirth as the child never lived.

Well they did live in the womb, and sometimes it's possible pinpoint the time when the unborn child died. But we conventionally measure age from the time of birth, so we avoid the nonsensical idea of a negative age at death by calling it a stillbirth.

From 1927 on, there has been a stillbirth registration process in England & Wales.

And prior to that date there was no requirement to register either a birth or a death in the case of stillbirths. This means that sometimes there are noticeable 'gaps' in the dates of birth of successive children in a family which no amount of searching in birth or death indexes can explain. And sometimes (one of my great-grandmothers is an example) the cause of death of a woman indicates that she died from complications in childbirth but we can only conclude that the child was stillborn because there is no record of the child. The introduction of the registration of stillbirths not only acknowledged that the parents had experienced a significant event but also made family history research easier. So yes, I think there is a good justification for including stillbirth in the Gedcom spec.