A very common error (in my BK data) that is rather invisible until I encounter it later when adding marriages to people initially added as children, is that the already entered child, added long ago, was given the wrong gender accidentally. This can happen due to "unisex" prenaming which is so common now, but the frequency of this error goes far beyond that situation. A suggestion, John, although I have no idea if there is a coding way to implement it, is this. The current situation is that when entering a person or series of people for whom no automatic gender assignment is applied (it is automatically supplied, for example, in the case of entering a spouse or parent), and we might be typing fast, and not looking at the screen, when the window comes up to choose M, F, or U, and we either typed an ineligible character, typed the choice too lightly, or simply forgot to enter anything at all, the window remains there waiting for us to type on of the appropriate 3 characters, even though we have already starting to type the event line. Progressing along the event line, it accepts the first M, F, or U you type, sets the gender to that code regardless of reality, enters what we have typed (including the letter it also used to indicate gender) and continues on typing the event content correctly. The most common situation is for M & F, since the systems ignores the entry of any other keystrokes (including numbers), often quietly makes entries masculine if the very next event date is in March or May, or feminine if the date is in February. While this does not prevent all errors of this kind, it would help if the NEXT keystroke that the system detects after the "set gender" window comes up, unless it was an M, F, or U, would not clear the window, and not proceed to gather additional data. The best bet would be to force the entry to stop until the person clicks one of the check boxes that are showing (rather than a letter). What has to be done is prevent the system from adding gender based on the presence of the appropriate letters in the text that follows. Better that doesn't allow you past the required gender code. You would still be able to select the M, F, or U, rather than use the check box if that one of the codes were that VERY FIRST KEYSTROKE after the window came up. Paul J. Lareau

To Paul Lareau I will have the program beep if it is waiting for M F and you type some other letter first. That will solve some of your problem. However, if you type May or March it will see the M as Male. So if you see any dates of ay or arch then you will know to check to see if the person should be female instead of male. John Steed ----- Original Message ----- From: "Paul J. Lareau via" <[email protected]> To: <[email protected]> Sent: Tuesday, March 17, 2015 10:30 PM Subject: [BK] Initial Child Gender Assignment Typo >A very common error (in my BK data) that is rather invisible until I > encounter it later when adding marriages to people initially added as > children, is that the already entered child, added long ago, was given > the wrong gender accidentally. This can happen due to "unisex" > prenaming which is so common now, but the frequency of this error goes > far beyond that situation. A suggestion, John, although I have no idea > if there is a coding way to implement it, is this. > > The current situation is that when entering a person or series of people > for whom no automatic gender assignment is applied (it is automatically > supplied, for example, in the case of entering a spouse or parent), and > we might be typing fast, and not looking at the screen, when the window > comes up to choose M, F, or U, and we either typed an ineligible > character, typed the choice too lightly, or simply forgot to enter > anything at all, the window remains there waiting for us to type on of > the appropriate 3 characters, even though we have already starting to > type the event line. Progressing along the event line, it accepts the > first M, F, or U you type, sets the gender to that code regardless of > reality, enters what we have typed (including the letter it also used to > indicate gender) and continues on typing the event content correctly. > The most common situation is for M & F, since the systems ignores the > entry of any other keystrokes (including numbers), often quietly makes > entries masculine if the very next event date is in March or May, or > feminine if the date is in February. > > While this does not prevent all errors of this kind, it would help if > the NEXT keystroke that the system detects after the "set gender" window > comes up, unless it was an M, F, or U, would not clear the window, and > not proceed to gather additional data. The best bet would be to force > the entry to stop until the person clicks one of the check boxes that > are showing (rather than a letter). What has to be done is prevent > the system from adding gender based on the presence of the appropriate > letters in the text that follows. Better that doesn't allow you past the > required gender code. You would still be able to select the M, F, or U, > rather than use the check box if that one of the codes were that VERY > FIRST KEYSTROKE after the window came up. > > Paul J. Lareau > > > > > Remember - Use the Archives at > http://archiver.rootsweb.ancestry.com/cgi-bin/search > ------------------------------- > To unsubscribe from the list, please send an email to > [email protected] with the word 'unsubscribe' without the quotes in > the subject and the body of the message >

Fortunately in my case having the wrong gender is an uncommon problem. I think the reason it has happened is because if one clicks anywhere near the gender boxes of an unmarried individual it will change the gender without question (bk6). So one just bumps along knowing that George is a male. George eventually marries Jane and they have children. Then I print a report saying that George is the mother and Mary is the father. I think that once the gender is set that it should not change without having to confirm the change. Jerry On Tuesday, March 17, 2015 10:31 PM, Paul J. Lareau via <[email protected]> wrote: A very common error (in my BK data) that is rather invisible until I encounter it later when adding marriages to people initially added as children, is that the already entered child, added long ago, was given the wrong gender accidentally.  This can happen due to "unisex" prenaming which is so common now, but the frequency of this error goes far beyond that situation.  A suggestion, John, although I have no idea if there is a coding way to implement it, is this. The current situation is that when entering a person or series of people for whom no automatic gender assignment is applied (it is automatically supplied, for example, in the case of entering a spouse or parent), and we might be typing fast, and not looking at the screen, when the window comes up to choose M, F, or U, and we either typed an ineligible character, typed the choice too lightly, or simply forgot to enter anything at all, the window remains there waiting for us to type on of the appropriate 3 characters, even though we have already starting to type the event line.  Progressing along the event line, it accepts the first M, F, or U you type, sets the gender to that code regardless of reality, enters what we have typed (including the letter it also used to indicate gender) and continues on typing the event content correctly.  The most common situation is for M & F, since the systems ignores the entry of any other keystrokes (including  numbers), often quietly makes entries masculine if the very next event date is in March or May, or feminine if the date is in February. While this does not prevent all errors of this kind, it would help if the NEXT keystroke that the system detects after the "set gender" window comes up, unless it was an M, F, or U, would not clear the window, and not proceed to gather additional data.  The best bet would be to force the entry to stop until the person clicks one of the check boxes that are showing (rather than a letter).    What has to be done is prevent the system from adding gender based on the presence of the appropriate letters in the text that follows. Better that doesn't allow you past the required gender code.  You would still be able to select the M, F, or U, rather than use the check box if that one of the codes were that VERY FIRST KEYSTROKE after the window came up. Paul J. Lareau Remember - Use the Archives at http://archiver.rootsweb.ancestry.com/cgi-bin/search ------------------------------- To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message

That should be: George is the mother and Jane is the father. On Wednesday, March 18, 2015 8:57 AM, Jerry Rolow <[email protected]> wrote: Fortunately in my case having the wrong gender is an uncommon problem. I think the reason it has happened is because if one clicks anywhere near the gender boxes of an unmarried individual it will change the gender without question (bk6). So one just bumps along knowing that George is a male. George eventually marries Jane and they have children. Then I print a report saying that George is the mother and Mary is the father. I think that once the gender is set that it should not change without having to confirm the change. Jerry On Tuesday, March 17, 2015 10:31 PM, Paul J. Lareau via <[email protected]> wrote: A very common error (in my BK data) that is rather invisible until I encounter it later when adding marriages to people initially added as children, is that the already entered child, added long ago, was given the wrong gender accidentally.  This can happen due to "unisex" prenaming which is so common now, but the frequency of this error goes far beyond that situation.  A suggestion, John, although I have no idea if there is a coding way to implement it, is this. The current situation is that when entering a person or series of people for whom no automatic gender assignment is applied (it is automatically supplied, for example, in the case of entering a spouse or parent), and we might be typing fast, and not looking at the screen, when the window comes up to choose M, F, or U, and we either typed an ineligible character, typed the choice too lightly, or simply forgot to enter anything at all, the window remains there waiting for us to type on of the appropriate 3 characters, even though we have already starting to type the event line.  Progressing along the event line, it accepts the first M, F, or U you type, sets the gender to that code regardless of reality, enters what we have typed (including the letter it also used to indicate gender) and continues on typing the event content correctly.  The most common situation is for M & F, since the systems ignores the entry of any other keystrokes (including  numbers), often quietly makes entries masculine if the very next event date is in March or May, or feminine if the date is in February. While this does not prevent all errors of this kind, it would help if the NEXT keystroke that the system detects after the "set gender" window comes up, unless it was an M, F, or U, would not clear the window, and not proceed to gather additional data.  The best bet would be to force the entry to stop until the person clicks one of the check boxes that are showing (rather than a letter).    What has to be done is prevent the system from adding gender based on the presence of the appropriate letters in the text that follows. Better that doesn't allow you past the required gender code.  You would still be able to select the M, F, or U, rather than use the check box if that one of the codes were that VERY FIRST KEYSTROKE after the window came up. Paul J. Lareau Remember - Use the Archives at http://archiver.rootsweb.ancestry.com/cgi-bin/search ------------------------------- To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message