Terry Reigel

Mike, When you look at the burials picked up in the audit report, are you saying that the date is blank in TMG when you look at the tag? But when you look at the GEDCOM the same burial now has a date from another tag?

This may seem silly, but did you look at those tags in TMG and verify that they were correct? If so, can you tell where the wrong dates came from in the GEDCOM? That is, which tags had right and wrong dates, and are the wrong dates obviously from another tag?

If you are actually getting run-on sentences, it's because of the way your tags are constructed, most likely by use of long sentences in the Memo field. But it sounds like the problem is not run-on sentences, but rather long paragraphs with many sentences. By default, the IN report puts everything about the person on a single paragraph. You can change that by editing the Sentence Structures to add line breaks. Open the sentences screen (requires Advanced Mode), place the cursor at the beginning of the sentence, and choose "Carrage Return" from the right click menu. It will add the code [:CR:] at the spot where the cursor was. You probably want to add two of them since the IN does not use indenting. If you literally want want a separate paragraph for each tag, you can add the CR codes to the default sentences in the tag type definition screen. But I'd not advise that - it creates very choppy narratives, worse in my opinion than excessively long paragraphs. Instead, for each person use the Preview report (button on the Reports toolbar) and decide where the breaks logically should go. Then open each tag that should start a new paragraph, and add the CR codes. Alternatively, you can create "new paragraph" versions of each common tag type you use, and choose that version where you want a paragraph break. Or, you can create "new paragraph" Roles for you common tags, and choose those roles. If you are interested in either of the latter ideas and need help doing it, please ask for details.

You say "style" but I think you are talking about editing the Sentence in the Tag Type - right? If I am correct in understanding that you changed the sentence in the Tag Type Definition screen, it should be changed in all existing tags of that type, provided that you have not changed the sentence in the individual tags. So-called "global" changes to the tag type do not override changes you have previously made in individual tags. My article on editing sentences my help. You remove "local" sentences by opening the tag and deleting the entire sentence. The default sentence is then applied.

You're welcome, Wal.

Importing is only reading and interpeting - nothing is done to the original file. On import, TMG reads the original file, then creates files in it's own format and copies the data there. Export, by contrast, by nature requires writing a file in another program's format. It's the creating a file in another's format that is supposed to be an issue. To my understanding, the "rights" issue if not entirely settled legally, but is at least clouded enough to warrent caution by a small company. In my view you have hit the issue directly. Wholly Genes' GenBridge technology, which is used by TMG to import data from other programs, has been offered for some time to developers of other programs. So far as I know, there is no other general purpose genealogy program using it, or any other method for data import other than GEDCOM. I am aware of a couple of specialty programs, such as those for PDAs, that do direct import, at least some using GenBridge.

Yes, everything is normal. First, a "child" tag and a "parent" tag are the same tag - just viewed from a different perspective. When you see it listed in the Child's person view it's labeled "Father" or "Mother" and when you see it in the parent's person view it's labeled "Son" or "Daughter." But when you open it, it's labeled as "Father" or "Mother". Parent/child tags do not have dates or places. They create the relationship only. When you see a date or place next to a child tag in the person view of the parent, that information comes from the primary birth group tag of the child. To edit that information, go to the child's person view and open the birth tag there. Parent/child tags do have Memo fields, but they are rarely used, and only print in reports if you specify specific options to do so. They should always have citations - that's what tells you how you know this child is the son or daughter of this parent. Citations are added if you use the Add Person screen to add a parent or child, and include a citation in that screen. But if you add the parent/child tag manually you have to manually add the citation.

I don't see that result - when I renumber the data sets, they seem to appear in the new order. Where are you finding that they are not?

There is general method for when you want to create any sort of report, but want to exclude people that the available report options don't exclude. You create a temporary Data Set that does not contain the people you want to exclude, then run the report from that Data Set. You create the temporary Data Set with the List of People report, setting the "Secondary Output" option to "create a new data set." You tell the LoP report on it's main page who to include in the temporary Data Set. You can do that with either the focus group, or with a filter. It doesn't matter if you include extra people, just so long as you don't include those you don't want in the report. For your direct line issue, a filter like: Is a Descendant of ID# 123 AND Is an Ancestor of ID# 456 END should work. Here the two ID#s are the persons at the two ends of the line. You might also want to check the "Then add spouses" box. If you need more details, please ask.

The problem exists in English as well - that's why there is the option. Various enhancements to deal with it have be suggested, but so far none has appeared. My solution is to set the report to use "in" because I find that is most often the correct one. Then, for cases where a different modifier is needed, like "at" or even "near," I modify the local sentence so that the becomes or -- the text before the [L] variable suppresses the preposition selected in the report output.

You're welcome. I used to use split memos to provide memo text for Witnesses, but now that the Witness memo is available for this purpose, don't need it for that. So now use it only rarely for complex tags with complicated events. I don't think I have any tag type with a split memo in the default sentence. Rather, I use it only for tags that I customize with a local sentence for special purposes. On the other hand, I use split CDs all the time. It helps when you want to use more generic sources but still get the "proper" format in endnotes. For some examples see my articles on split CDs.

Your copy and paste of the memo text helped... The problem is the character you are using for the bars - you are using a letter "L" - the character you need to use is the bar character, which appears in different places, but on many keyboards is above the \ character, either above or below the enter key. On the key it ususally is shown with a break in the middle, like two hyphens arranged vertically. There should be no space between the two bars.

You're welcome.

I can't tell from our post where you are using the variables and bars. In the Memo field, you create the segments by dividing the segments with the double bar: this is the first segment||this is the second||this is the third In the sentence you use the variables [M1], [M2], [M3], etc. So your sentence might read like: [P] went [M1] on <[D]> <[M2]><[L]> <[M3]> if you wanted three segments for example.

You could use something like a Family Group sheet, with the options "BMDB events when missing," "Blanks for missing data," and "Space for unknown children" checked. You could send the reports to Word, and e-mail that. But if they are truly computer uncomfortable, detaching, editing, and re-attaching the files will be a problem. I'd think you might be better off printing it as a Text file and copying it into the body of an e-mail. That's obviously a big challenge for 3-400 relatives, but I'd think your chance of getting responses are much better because they could click Reply and add the changes. Not that I know of, but you might want to check out the TMG list on RootsWeb - TMG-L. It's a conventional e-mail list, and has lots of experienced users actively responding. In my view, it's a better forum for "what's the best way to..." type questions do to the wider base of active users. Details are here.

Assuming you are trying to build the ToC in MS Word, there is an option in Word that you need to change. Here's how: - Use the Insert > Indexes and Tables menu to open the Indexes and Tables screen, then go to the Table of Contents tab. - Click the Options button, and on the screen that opens, at the bottom, check the "Table entry fields" box. Note that Word resets this option, so you need to do this each time you create another ToC. - OK out and your ToC will be built where you had the cursor in the text.

There are a couple of places that might go wrong here. First, in the "Print to" box of the report definition, the file type should be one of the "Word for Windows.." options in order to create a report in Word format. If not, fix that. Next, in the file name box below that, the file name should end in .DOC -- this is what tells Windows it's a Word file. If not, fix that. If those are all right, the file being created is actually a Word file, but Windows is opening it in the wrong application (TMG creates the file, then tells Windows to open it, and Windows decides what the correct application is.) To test, open Word manually, find the file, and open it in Word. It should do this just fine. If so, the problem is that Windows has the wrong application associated with the ".DOC" file extension. You will have to fix that in Windows, not in TMG. Do that by opening Windows Explorer, and on the Tools Menu choose Folder Options. On that screen, go to the File Types tab, and scroll down the list to find the DOC file type. The difficulty is that in Windows98 they are listed by a name of the application, rather than the extension, so it may take some hunting to find it. Clicking on each one will cause the extension for that file type to appear in the area below the list. Once you find the DOC file type, click the Edit button, and then click on Open in the list of operations below. Then click Edit again, and you will see the name of the program that Windows is using to open this file type. It should be Winword.exe, but apparently is not. To fix it, click the Browse button and navigate to find the Word file. Sorry this is so complex - this has all gotten easier in WindowsXP. Get back if you have difficulty with the proceedure.

Good to hear it's somehow fixed.

Changing Language does not have any impact on the date format - that's controlled by the Preferences setting, as you discovered. If you choose a date format in which the months are in alpha, rather than in numbers, you can edit the alpha text for the months in Languages. Likewise, if you specify that days of the week are to be included, those can be edited in Languages. But so far as I know, you cannot change any other aspect of date formats in Languages.

You're welcome, Buzz.

The filter will produce the same number of people in any case. But since the Project Explorer is actually a list of names, not a list of people, you will get a different number of names depending on which types of names you specify with the radio buttons.

I get all people in 6.05.000 as well. I don't understand why you are getting a different result.

Thanks, Arman. Now I understand. No, you can't currently do that. However, it would have limited utility. The Focus Group necessarily is a list of ID#'s, since that is the only way to reliably identify persons. So it could only be used by someone with the exact same people with the same ID's. For practical purposes, that means they have a copy of the same project. The FG is currently saved as part of the set of data tables that make up the project. So if you send someone a backup, they get the saved FGs. But there is no easy way to "refresh" with new FGs unless the recipient has kept the data set locked, which is generally not a viable approach.

The reason the occupation doesn't show is that it's not included in the Sentence. Normally the occupation is written in the Memo field. So the Sentence should be: [P] [M] || [P] [M] The standard Occupation tag also include the date, so if you wanted that, it would be: [P] [M] || [P] [M]

You're welcome, Jeff.