Terry Reigel

I understand that part, what I was not understanding was what you are suggesting be added. It sounded like you were suggesting several different things, some involving filtering and others involving including the relationship tag in reports. It's complicated by two factors. One is the fact that you cannot delete a person who is linked to another with a relationship tag. This is done as a safety precaution, to avoid accidently deleting a large number of people. I'd think a very valid "wishlist" item would be to provide a way to override this restriction. This would avoid the whole business of creating a temporary data set, moving the people to it, then deleting it. The second issue is that the idea of "related to just one branch" has no real definition. What does "related" actually mean? Is the second husband of the sister of the spouse of a forth cousin twice removed "related?" Is that husband's mother's second huband? Is his daughter's husband's parents? Some users actually do have such people in their data - I do. I thought for this purpose they were to be incluced, so I described a process to find them. I don't think TMG's relationship tag would regard any of these folks as "related. It's the same issue - users are apt to enter people who are linked to a line in ways that are not really considered "related" by any sort of relationship calculator. On your original post you suggested the definitions in my "Related-by" flag article worked for you. But note that they would not include the sorts of "relationships" I described above. The ability to include the existing Relationship tag in reports is a very different thing than the use of relationship information for filtering, as I said in my previous post in this topic. And, as I said, Second Site already does something like this, and I think this would be a very useful capability.

It's not at all clear to me what you are suggesting here. The Relationship tag and Kinship report produce a large number of relationships... 6th grand-uncle, 3rd cousin 6 times removed, etc. It sounds like you are suggesting, perhaps among other things, that there be a way to use these results to set a Flag. But Flags have only single characters, so translating the wide variety of relationships to understandable single characters seem daunting. Perhaps you have in mind some sort of mapping, since you suggest the "related-by" values I list on my site are suitable to you. I'd suggest that if they are, you must be in the minority, as I've never seen another article on the subject that uses the same set of values. Take a look at the other articles linked to mine to see the variety publicly offered - I suspect that the majority of less clamorous users who haven't published suggestions have come up with a much wider variety even than that. It seems to me that any system that would create flags from kinship analysis would have to have a complex set of user-controllable maps to determine the actual flag settings. A means to create a Relationship tag that could be included in reports does seem much more straightforeward. Second Site already includes this capability in it's output, which I find very useful in creating custom sites on CD for relatives. I set it to say how each person in the data is related to the person for whom I've created the CD.

Sorry, but I think you are wide of the mark. I don't think whether one accepts data without criticism or analyzes it to death has a thing to do with how you choose to enter sources in TMG. I create one TMG source per roll of census microfilm, which I think qualifies me as a "lumper," but I probably record more details from census records than 95% of all TMG users. The difference between creating many sources or only a few generic ones only has to do with whether you choose to record the details in the source definition or in the citation details field, and has nothing whatsoever to do with the level of analysis one applies to the data, or how much time one tends to apply to either data analysis or recording.

The easiest solotion is neither of these. Instead, go to the main page of this site, find the TMG page, then follow the link to the UK edition. There, download the "30-day trial" version and install it. Then unlock it with your TMG6 Unlock code. If downloading isn't feasable, then you can install the latest full version you have available, and upgrade from there. If that's TMG5, you have to upgrade to 6.0, then to the current version.

You're welcome, Ann. You have lots of options. The hard part is deciding which to use. BTW, are you really using TMG 5, as indicated by the fact that you posted in the TMG 5 forum? If so, I suggest you look over the list of new features in version 6 in the main section of this site. There are a number of new features that are quite useful if you are doing the sort of complex things you are talking about, including the ability to sort the order roles appear in the list of roles in the tag definition screens, the order witnesses appear in tags and the resulting reports, and the order of citations. Terry

No, it's really not that hard. It can be done pretty easily with the focus group. Here's what I would do: 1. First, I assuming you want to keep a copy of the data set that includes these spouses and their ancestors. So start by creating a copy of the Project, using the File > Copy Project command. Then, do the following steps on either the Copy or the Original. 2. You need to "cut off" links from the two key persons back into the family you want to keep, so the following steps don't get the "keepers" included. Do that as follows: - Go in turn to the Person View of each of the two spouses you want to "unlink." - For each of them, click on the name of each Father at the top. Click the [ * ] button, or the "*" key, to remove the primary status of the tag. Say Yes to the prompt. Do the same for the Mother. Note that the parent/child tags now move into the main list of tags instead of being in the top box. This "breaks" the parent/child relationships. 3. Make sure the Focus Group is empty. Then right-click on the names of the four parents of the two key persons in any view, and select "Add to this person to the Focus Group." This puts the four of them in the FG. 4. In the Add Others box, check Ancestors, Descendants, and Spouses. Set the number of generations for Ancestors and Descendants to a number greater than the number of generations in your data. 5. Click the Select All button to select everyone already in the FG, then the Add Others button to add the the Ancestors, Descendants, and Spouses of those selected (note that since you "broke" the connections to your "keepers" in step 3 above, they will not be included). 6. Repeat step 5 several times, each time clicking Select All, and then Add Others. As you do, note the number of names in the group at the upper right corner of the FG screen. When it stops increasing, you have found all the family members you want to remove. 7. I'm assuming you actually want to keep the two "key person" spouses themselves. If not, add them manually to the FG now. I'm also assuming you don't want to keep the parents of these to spouses. If you do, manually remove them from the FG now. The FG should now include everyone you want to delete from the Data Set - that's the hard part. 8. Open Data Set Manager, from the File menu. Click on the Add button to create a temporary data set, and give it a name, like Junk. Click Close to close the DSM screen. 9. From the Edit menu, choose Move. On that screen, select "Move all the people inthe current Focus Group," then below that, as the "To data set," select your newly created "Junk" data set. Click OK to complete the move. Everyone who was in the FG is now moved to the Junk data set. You probably want to return to Data Set Manager and delete the Junk data set now to totally delete them.

You're welcome, Ann. Very true. I'd suggest creating a simple "Test" project from scratch, with maybe only one or two persons. Then you can go to it to see what the default sentences and roles are and compare with your imported project to see what is different. I'm not an UFT expert, but one issue I understand is that it added the parents automatically to the text generated by the marriage tag. TMG does not - you have to put the [PARO] variable that was removed by the import back into the sentences. Or, use the [RPAR:Bride] and [RPAR:Groom] variables if you prefer. That would be very useful if it worked, but, as you found, it doesn't. You have to use the individual role variables, and add appropriate text, as you are working on. And, as you found, it can become very difficult to get a structure that works with a wide variety of different roles. No, you cannot nest variable inside conditionals - only one variable is allowed in a set of conditionals. Using more gives strange results. That's my theory, though there are some users (mainly a few ex-UFT users, so far as I know) who try to create very complex sentences that accomodate a large number of roles. You might look at Teresa Elliott's website for some example of some she uses. In my view these never work all that well, and you keep having to add new roles to cover newly found situations. I think it's better to keep to the more common situations and create custom local sentences, or put the variables in Memo, to deal with less common cases. That's my recommendation. Or, take advantage of the fact that sentence variables work in memos. Create some "all-purpose" roles (I use Role1, Role2, Role3 - very imaginative, right?) then put the variables and connecting text in the memo. TMG adds a final period, but doesn't double up if you already have one, so it doesn't really matter. Not so far as I know. As a practical matter, the limit is the how many to can keep straight in your head, and construct workable sentences for. I see a couple of issues. The first is the one you've already found - you can't nest conditionals, and thus there is a problem with the "Other members..." phrase. My suggestion is to deal with it by creating a separate HoH role for a household with no other members. It would be simple - no other roles. Then, use this one when there are other members, and remove the "Other members..." phrase from the conditionals since it would always apply. You've delt with the single or multiple members of each group with the "(s)" method. If you want, you could create separate roles for single and multiple cases - a Son role and a Sons role, for example. Of course this would generate even more roles. You use the first name form for all the roles. This makes sense for the children of the HoH, but less so for the others who will not share the same surname. I'd use the [R:rolename]form for the others. I'd suggest you consider joining the TMG-L mailing list for more opinions on questions of this type. It's a pretty busy list, but there are lots of knowledgable, helpful people on it. Many of them do not regularly respond here, so you get a narrower set of suggestions here.

The default tag sentences do no mention Witnesses in the narrative for the Principals - they are only mentioned in their own narratives. You can, however, customize the Principals' sentences to mention the Witnesses in any way you choose. Typically, the sentence would be designed to say something about what role they played in the event. If you need help with that, describe what you would like to see and we can suggest appropriate changes. Individual narratives do not mention the names of parents. Ancestry and descendant reports are designed to show those relationships, but not Individual narratives. Some users prefer the Individual Narratives, however, and want to include the parents names. This can be done by modifying the sentence of the birth tag to add the variables for the parents, but that means they are also included in ancestry and descendant reports, where they become redundant. Perhaps a better solution is to create a custom tag that gives the parents names - that way you can include that tag in Individual Narratives, but exclude it from other types of narratives. If you need help with either of these points, just ask.

What I was suggesting was to "filter" on that relationship. You haven't described exactly how the two groups are defined, so I can't give specific suggestions, but here's the idea: 1. In the Focus Group, add the "key" person to an empty FG. Select that person, and use the Add Others feature to add that person's ancestors or descendants, depending on just who you are trying to collect. Then, Select All, use Control-click to unselect the key person, and add spouses or ancestors/descenants, repeating until you have everyone you want to collect. The exact proceedure depends on the nature of the group you want to assemble. 2. Filters - you can't use filters alone if the group is much more complex than "Is an ancestor of..." or "Is a descendant of..." - you need to create a temporary flag, and repeatedly seek out ancestors, spouses, descendants, etc, until you have the correct group marked with the flag. Then filter on the flag itself. If you could describe 1) either the group you want to keep, or the group you want to exclude, in terms of how they are related to a key person, and 2) how that person is related to others you want to exclude or keep, we can suggest a specific proceedure.

Deleting a group of people is a pain. You have to delete all the relationship tags first. There are two better ways: 1. Identify who you want to keep in the Data Set (using the Focus Group, selecting then in the Project Explorer, or by use of Filters). Then, use the secondary output feature of the List of People report to create a new data set or project that contains only those people. Then work with that new data set or project. 2. Identify those you want to get rid of, create a temporary Data Set in the project, then use the Move People command (Edit menu) to move them to the temporary Data set. If you want, you can then delete that data set. If you need more details on either process, just ask.

If you enter an ID# in the Name - ID# field it will be used rather than the Name - Other field, as you discovered. The solution is to remove the ID# from that field, and leave the name as you prefer to see in the the Name-Other field.

Yes, you can create a list of such people, or filer the Picklist to display only them. In either case, a filter like this should work: Birth Group... Year >Is greater than 1799 ANDBirth Group... Year <Is less than 1811 ANDSurname =Equals JONES END If you have multilple birth tags for some people, you may or may not want to restrict the Birth Group terms to the primary tags by checking the box in front of those lines.

Many users have missed it. Whether it's a large tab or not depends on the width of the screen used for all the tabs - in some cases there isn't room for the last tab on the first row, so it moves to the second row, and being the only tab on that row, takes the whole width of the screen. If you make the screen a bit wider it moves to the first row and becomes the same width as the others.

As Vera says, that's covered in some detail in my new language articles. The short answer is that the upgrade replaces the translation tables - the list of phrases TMG uses mainly to display all the screens in your choosen language. Those tables also control some of the standard phrases use in reports, things like "children of ... were," names of months, automatic pronouns and prepositions, etc. So, you need to be concerned only if you have edited those phrases, using the File > Language > Customize command. Or, if you have created your own new "Language." The article talks about how to deal with that case. If you have not made any edits to the translation tables, you should allow the updates in order to receive the updated translations from the program update. Tags and Sentences are part of your Project data, and are not involved with the translation tables which are updated when you do a program update. So you don't need to worry about the updates causing any problems with them.

You're welcome, Phil. Terry

Yes, at least two ways. First, on Step 5 of the Export Wizard, there is an option to "Suppress details on living people." If you choose this option, people whose Living Flag is set to Y or ? will be named, but none of their details (that is birth dates, etc.) will be included. If you want living (or any other set of) people totally excluded, it takes a couple of additional steps. Here's how: 1. Open the Project Explorer, and click the Filter (funnel) button. 2. On the filter screen, enter: LIVING = equal N END Click OK to close the Filter screen. 3. In the Project Explorer, you will now see only those who are marked as living with the Living flag. Using standard Windows techniques, select everyone ... click on the top person, scroll to the bottom person, and hold Shift while clicking on the last person. 4. Now open the Export wizard, and at Step 4, choose "Selected people in the Project Explorer." Both methods depend on correct settings of the Living Flag. By default it's set to ?, but TMG automatically sets it to N if you enter a Death tag, or if there is a Birth tag with a date which would make the person older than the assumed lifespan set in Preferences (110 years by default). You can manually change the flag to mark others as not living if you choose.

From the Help article on entering names in source definitions: The name of the author/compiler/editor in the form "Last, First Middle." Multiple authors are separated by a semicolon. When printed, the first and last names will be rearranged as required for footnotes/endnotes and bibliographies. Because commas are used to separate last and first names, you cannot use them elsewhere. Wholly Genes, Inc.

You might look at my article on accents for some ideas. Generally, it's better to create flags and use them for accents, rather than the filters like "is an ancestor of" because this allows the screen to re-draw more quickly as you move from person to person. Also, you can create much more complex accent systems, as described in the article. However you cannot create accents based on the relationship to the current focus person - the accent has to be based on a fixed relationship or flag. Look at the ideas in the article and see if something there doesn't suggest a solution for you.

Well, yes, but I've glossed over the part about setting it to Y for everyone you do want to include. It that's everyone currently in the Project, or just about, the easy way is to first create the Flag with Y the default - that sets it to Y for everyone already there. Then edit the flag and change the order so N is the default - that make N the default for everyone you add. If you only have a few now entered you want to be set to N, you can do that manually. If there are more, you should use the secondary output of the List of People report to set it for them. The challenge will be to tightly define your criteria so you can create a filter that does what you want.

You don't say how you are building your website, but both Second Site and GEDOM exports can be controlled by flags. So you can create a custom flag, and use that. If you set the default condition of that flag to N, it will be set to N for each person you add. Then exclude everyone with the flag set to N.

I'm afraid there's no variable for the date of birth. The Descendant Intended Narrative does not include spouse events. But the Journal does, if you change to Custom format on the General tab of Options, then check "Include spouse events" on the Miscellaneous tab. You might see if that would work for you.

You are right - you get exactly as many FGSs as there are people. But what I said was you would get twice as many as you want. But of course I was assuming that he would want one sheet per family, not one per person. Perhaps I should have stated that.

You're welcome. Terry

I see the same issue with a large number of people. It worked for me with 600 people, but I got the error you did with 1200. I'll report that. But there are ways to get around it. First, I'd note that you will get twice as many FGSs as you want by choosing "All people"... each parent will appear in one as focus person and in another as spouse. Also, you will get FGSs for children who have no children, and already appear on their parents' sheets, which wouldn't seem too valuable. I'd suggest you first cut the number in half and more with a filter like: SEX = M AND# of children Is more than 0 END Note that this will omit any female parents without known spouses, and any single persons with no parents, spouses, or children. If your data contains those you could either get them manually or create a more complex filter to capture them. If it still fails, I'd suggest limiting the ID# range to a number small enough to make it work. You could put an AND at the end of the above and add a term like: ID Number Is Less than 600 END then run again changing Less then to More than.

Well, that would be because by long-standing convention in genealogy, a "Family" is two parents and their children. So two marriages means two "families." TMG does automatically generate both Family Group Sheets when you specify a person with two spouses. But in any case, I don't see what this has to do with the issue Jim posted.