Terry Reigel

I'm not sure of what you mean here. As the article says, "the setting of new default tag types, name styles, place styles, and source categories does not affect existing data sets in any way." So as far as existing datasets (including projects with only one data set) none of the UK-specific tag types, styles, or source categories will appear upon use of the UK edition. They will only be there if you follow a proceedure like that described in the article to copy them into it. Your custom sentences, which you created in the standard language, English(US), will remain in your data set. They work fine, as long as you continue to create your reports in that language. But, one of the features of the UK edition is that it switches your system to English(UK). That means: 1) That any new report definitions you create will use by default will use that language, so they will not see your custom local sentences. If you use your existing defined reports, which use English(US), or you purposefully choose that language, they will be seen. Or, you can copy them over into English(UK). 2) By default, all sentences you see will be those for English(UK), so any sentences you created in English(US) will not be visible unless you change them to that language. And, any new custom sentences will by default be entered in English(UK), so will not appear in any reports you create using English(UK). It's entirely possible to end up with your custom sentences mixed between English(US) and English(UK). You can deal with this by either a) changing back to English(US) and continuing to operate in only that language, or 2) copying all the custom sentences to English(UK) and afterwards working in that language. You're welcome. No, I have not moved a working Project from the US edition to the UK edition. But I've run quite a number of test projects in English(US), English(UK), and German, and understand quite well the behavior of sentences and other features when you change languages. What I'm telling you is not based on what I read on the WG web page. Nothing is lost, and it's all very predictable. TMG has some powerful features for managing language issues. But you can't switch languages casually. You need to understand the underlying processes and manage them to get the results you want. There's an article on use of languages on my website, but I'm afraid it's now outdated and incomplete. The one I've got under construction will be about 5 or 6 times as large, but it's still only about half done, sorry to say.

Actually, it does address that: "As noted above, the setting of new default tag types, name styles, place styles, and source categories does not affect existing data sets in any way. Those new defaults are only applied to data sets that are subsequently created." Basically, what it's saying is that converting to the UK edition does not mess with your exiting data. You have to decide which of the listed features you want included in your data, and use the proceedures described in that page to include them. Beyond that, if you have created custom sentences either for standard or custom tag types, or for local tags, those sentences will be in whichever language you were using at the time. That is, they will be in English(US) if you were using the standard edition. If you then change to another language - as you would by default if you moved to the UK edition, changing to English(UK) - Those custom sentences would not be visible, nor would they be used in newly defined reports set to English(UK). There are tecniques for copying the sentences between languages, and if you have created custom sentences, you would want to manage that if you change languages. Yes, as described in the page you reference, you can copy the custom tag types, styles, and source types so that both exist in the resulting project. What features would you think could not co-exist? What output would you expect to be different? Tag types, styles, source types, etc. are all project data, so if you exchanged projects that data would be available for output, provided you used the same source definition settings. The only possible complication I can see would be that the user of the US edition would have to have the language modual installed in order to set report to use English(UK), assuming that was the language used to create any customized sentences.

The regular Pedigree offers no choice in which tag types are included. The Compressed Pedigree allows you to choose from Birth, Marriage, Death, and Burial. The latter may do what you want. If there is no birth tag for some people, and you've used the default Baptism tag, which is in the Birth group, it should be marked as primary and will automatically appear in place of the missing birth tags. Another alternative might be the Ancestor box charts, which allow more flexibility in choosing which tag types to include.

Carol, be careful with this. GEDCOM provides for only a few two-person tag types. Only those tags recognized in the GEDCOM specs as "family" tags can have two people, and those two people must head a family - that is either be married and/or have children. Two-person census tags are allowed, provided the two principals are married or parents of children together. But even if they are exported, they may not import into another program. If you have other two-person tags (Living, Residence, Memo, Immigrated, Moved...?) verify that they are exporting. I expect if you have them that many will not export. For a fuller discussion on this sort of exporting issues, see Jim Byram's chapter on Exporting in GTMOOTMG.

To be more precise, you have a list of names - the Picklist is a list of name, not of people. If you have more than one name with the same ID#, that means that you have a person with more than one name. I agree that's very dangerous - you would loose nicknames, alternate spellings, etc. if they exist in the data. Sorry, no. There are no filter terms that compare the contents of fields as you would need to do this. I assume that you have already done too much editing or made too many additions to just delete the project and re-import? That would be the obvious solution. Do you know whether the two sets of data contain identical information, such and dates, places, and sources, about each person? Only if it does could you consider deleting the non-primary tags on a wholesale basis. You might be able to get some idea whether there are more than one different name for people by creating a List of names report, and sorting it my ID# - that way all the tags for each person would sort together, and you could examine the list to see if you find different names for the same person. You could limit the report to people with multiple names by using the secondary output of the List of People report to set a temporary flag for everyone with more than on name group tag.

Sounds like you want the CR before the first line of text in the Memo. You should be able to do that by putting the [:CR:] code in front of the Memo variable in the Sentence: <[:CR:][M]> You need to be in "Advanced Data Entry Mode" to see the Sentences. Go to Preferences > Program Options > Data Entry if you need to change that.

You can't do this one within TMG itself, but John Cardinal's TMG Utility will do the job. See here for more information.

Yes, this was discussed some time back, but there was no change. The Ctrl-L, and the "Last viewed Person" button and menu command, all take you to the last viewed person as listed at the bottom of the View menu. Trouble is, that is actually a list of names and views, rather than being people and views. When you change the name of the current person, the new name becomes the current name, and the previous name (even though it's the same person) becomes the previous entry on that list. So when you go to the "last viewed person" its actually the same person.

Full response on TMG-L. Peter's got it - you can save more than 20 characters as long as you use a language other than the standard English(US).

You're welcome. I just tested by sending the LoP report to a text file, and the creation of a new project worked. Where did you send the report that didn't produce the new project?

Use the secondary output (click Options on the report definition) of the List of People report to create a new project containing just those people in the List of People. Then open that project, create a backup, and send the backup. Your correspondent would then Restore the backup. You select who is to be included by 1) assembling them in a Focus Group, 2) selecting them in Project Explorier, or 3) using a filter in the LoP report. Complex groups can be selected by setting up a custom Flag, then filtering on that. If you have difficulty figuring out how to get the people you want, let us know the problem and who you want and we can help.

Teresa, I think there would be a problem agreeing on just what that means. For example, just what does "related to" mean? Does it include spouses? Parents of spouses? Siblings of spouses? Step parents and their children? Half siblings? Etc., etc. And will others agree with your definition? Then what does "by 3 generations" mean? Back 3? Down 3? Up 1 then down 3, or if you go up 1 do you only then go down 2? If you go up 1 (your parents), then down 1 (your siblings), then do you go up 3 for the ancestors of your siblings' spouses? And again, will others agree with your definition?

No, it gives you the descendants of everyone who is selected. So when you have gathered a person and his or her ancestors, click the "Select All" button, then add Descendants for one generation. That gives you the siblings of your "subject" and of all the ancestors except the oldest generation. If you don't want the children of your subject, de-select that person and spouse before adding the Descendants. In the Focus Group there is no such thing as a single "subject." You may view the first person you put in the group as a "subject" but the FG doesn't care. As far as it's concerned, it's only a group of people. The "Add Others" operations always refer to whoever is selected in the Focus Group when you click the "Add Others" button. You can select one person, everyone, or any specific group, and add others related to them in the way(s) specified in the "Add Others" box.

Mike, Don't we have that now by adding descendants for one generation? You do have to take care about the youngest generation if children exist that you don't want to include, and the oldest if you have cut off the common ancestor. But I find it works fine for most cases. Or am I missing something?

That's right - if you want to "upgrade" your existing installation, you first need to go to 6.00. Then you can update that to 6.07 in a single step. Yes, you can uninstall TMG5 and install the current version, which is 6.07. But you cannot update the existing installation of 5.15 directly to 6.07.

I'd guess you have changed e-mail addresses since you bought TMG5, and are using the new address rather than the one you used then. You need to use the same name and e-mail address that you used when you purchased the program, as the unlock code is keyed to them. I assume that you have not purchased TMG 6 - but if you did that could be the problem - the unlock codes for versions 5 and 6 are different.

The whole intent of having separate Data Sets in a Project is to allow them to be kept entirely separate, so you can import an examine data from different sources without any possiblity of contaminating your working data. As a result you cannot link people in different data sets. Different data sets can have different, and conflicting, settings for tag types, source types, flags, styles, etc. so merging or moving people between them requires resolution of all those issues. See the section "Potential Conflicts when Merging Data Sets" near the bottom of my article on Merging for discussion of how this is done when merging Data Sets. Since people in different data sets cannot be linked, merging them makes no sense. You can always copy the person into the other data set and them merge them if you want.

I'd suppose it's because Probate always comes after death, and, just guessing, this keeps the tag from showing up in the audit report as a "after death event." The will is always written before death; probate always occurs after death. I'd think that's the reasoning.

You're welcome.

I'm afraid locked is locked - the flags are part of the data, and cannot be edited while the dataset is locked.

I'm afraid there is no simple solution. A feature to allow easy copying of custom source types has been suggested, but so far has not appeared. There is a work-around you might consider. You could create a dummy person, attach one source of each type to that person, then copy that person to the other data sets (provided they are in the same Project - if not, merging of projects would be required). This may not work if the custom source types have the same names as source types in the receiving data set. It might be easier to Merge the data first (or copy those people you want to keep), mark them with a Flag, then go through and clean up the sources using your custom sources. One issue around cleaning up the sources in received data -- many users would feel that you should not enter the sources in such a way that it appears you have seen them, when you have not. In my view, the most straight-forward way to enter such sources is to cite the received file as your source, then note that the author has cited such-and-such as a source. Trouble is, I don't know any workable way to do this except manually. An alternate might be to leave the sources as cited, but add some sort of note to each saying you haven't seen it but it was cited by so-and-so. That you could do by editing each source definition before to do the merge.

Yes, there is a way. If you construct a filter like: Memo Contains - You will get all events that contain a hyphen. If you check the option on the Miscellaneous tab to include excluded information, and add the Memo to the output columns, you can then search the report and find them. Finding them is much easier if you sort on the column containing the Memo (thanks to Jim Bryam for that trick). You would need to do this for each field where you use exclusion markers. You could create a multi-line filter to look for them all at once, but then you would need to include all those fields in the output to verify them. Unfourtunately, the filter "Begins with -" seems to be broken - it would be more useful. That has been reported.

I'm afraid there is no good answer. If you want to refresh the imported data, you have to keep it locked - because if you edit, the program has no way to know what to do with your edits when the new data comes in on "refresh." Of course, that means you can't add data because it's locked.

You're welcome, Rhonda. Terry

Rhonda, First, note that source citations are not applied to persons, but to individual tags - name tags, parent/child relationship tags, and event tags. Next, note that the only tag related to a child that appears on the parent's person view is the parent/child relationship tag. So, if you added a citation from the parent's person view, the only tag in which that citation could appear on the child's person view would be the parent/child tag. If you go to the child's person view and open that tag (double click on the "Father" label just under the child's name) I expect you will see the citation you added. If you want the citation to appear on other tags, like the child's name tag and the birth tag, for example, you must add them there as well.