My Way ©MJH 1996-2016
TMG™ Outstanding Bugs ©MJH 2014-2016;

Modified January 31, 2017 4:54 pm

Final TMG™ Version 9.05
My List of Outstanding Bugs

On 29 July 2014 Bob Velke announced that development and sales of TMG™ would be discontinued. The following is my list of outstanding “bugs” which I have encountered and believe are still present in the final Version 9.05 of this software, and thus will remain unmodified.

NOTICE/DISCLAIMER: This document is not authorized or official TMG documentation. For official documentation of TMG see the excellent embedded “ Help ” facility within the program. I do not warrant in any way that this information is accurate or useful, and any use of this document is at the user’s own risk.

Introduction

What kind of program behavior constitutes a “Bug” is a matter of user perception. Some may consider a particular program behavior as intended design, an overlooked feature, or unavoidable consequences of improper user actions. Others may consider the program behavior an error, or even extremely unexpected, and thus label it a “bug”. The designation of “bug” for the following behaviors is strictly my perception. These “bugs” are roughly grouped by my identification of a Topic. They are then listed within each group in no specific order. As I intend to continue to use this software for some time, I have also tried to identify what I use or have considered as “work arounds” for each noted program behavior.

I strongly suspect this list is not exhaustive. It only includes those items which I have encountered, consider erroneous or extremely unexpected behavior, can reproduce myself, and thus have chosen to label a “bug”. If you have encountered some other program behavior which you consider a “bug” not included below, post exact step-by-step details on how to replicate it on the TMG-L Mailing List with your suggested “work around”. If I can replicate it I will include it in my list.

Table of Contents

Data Corruption

(Any sequence of normal actions which resulted in data corruption was always the highest priority for getting fixed. These traditionally were caught by beta testers and fixed before public release.)

• —None known—

Program Aborts

(Any sequence of normal actions which resulted in the program aborting was always a high priority for getting fixed. Thus there is only one known to remain, and it requires a very unusual sequence of user actions.)

Defining new embedded source with expanded title within an expanded memo aborts program

Data Entry

If Add Person is Husband, Wife, or Spouse, no Marriage or Divorce group tag added with no data

Attempting to uncheck the Date field in the Add Person Setup gives an error

Style Labels not used on Add Multiple People column headings

Add Multiple People will change existing Place Style without warning

Empty person shows in a filtered PE after copying a person

Add Multiple Witnesses using Search with Expanded Picklist selects at each keystroke

Some valid forms of Old Style date input are interpreted as irregular

Plus/minus character not recognized in date

Changing a tag’s Tag Type does not also change to the associated default style for that tag type

Changing a Parent’s Relationship Tag Type can change to Type with wrong presumed sex of parent

Changing Primary Name designation in MACHINE or UNIQWT collate sequence gives wrong sort

Entering duplicate ending sensitivity markers causes display and report problems

Entering text surrounded by unescaped brackets at the end of a sentence causes report problems

Escape characters do not always work in Place fields

Date format dd-mm-yyyy causes data entry problems editing Tasks

Adding or Editing a Task from a Repository limits setting the Task links

Field sequence when using the Tab key in the Citation screen changed

Empty split field parts which do not include a place holder character can cause unexpected output

Text Formatting

Embedded text formatting codes nested within a WEB code cause errors when ending editing

Text formatted as web code does not display in Sentence Preview or Item tips

Place fields with decimal or hexidecimal HTML codes do not output using Place Style

Exhibits

Exhibits cannot be Footnotes or Endnotes

Reports to HTML do not honor image exhibit centering or resizing Report Options

Highlights placed wrong on scrolled Image exhibits by Graphic editor

Between-sentence spacing issues with embedded text exhibits

Escaped brackets in text exhibits in reports output wrong

Exhibits do not display in RTF

Non-primary person exhibits not output in Journal report if only Primary events selected

Sources

Problems with Duplicate Source Element names in different Source Element groups in different datasets

The Filter condition of Override Ibid is ignored for a List of Sources report

Report output

Multiple Person exhibits in DIN not display in Word output

Selected name not used in LOE and LOW reports

Journal Report outputs some Name-Married narratives even if the Option is set to suppress

Journal Report outputs “unknown spouse” even if the Option is set to suppress

Journal Report outputs Primary name for first tag narrative even with a Selected Name

Text font does not reset after a citation when output to Word

Text font does not reset after font change in a Bibliography when output to Word

[+] Concatenation code prints if there is no preceding sentence

[:NP:] Code suppresses multiple citation references after the first

Unexpected Roman Numerals for Citation Reference Numbering

Full name of ID referenced people output in Short Footnote

Indent of text from LIND codes not ended in HTML report

Indentation wrong following LIND codes in any indented report

“Include memos from witnessed events” Journal Report Option does not work

Empty split memo variables do not give unknown value in sentences for Name tag group

[P] variable always outputs a pronoun in the narrative for tags in the Name group

Prepared date in report Researcher data does not use report option date format

Which Researcher data fields output depends upon other fields being selected

Using Accent colors in a Journal report produces wrong font for surname in Title and no color in an Individual Narrative

End of sentence period added even with [:NP:] code on ending text in Journal report

CENTER formatting does not work for text in HTML report

WEB formatted text with ‘&’ in URL does not work in HTML report

FGS Option for Blank line above and below Title gives no line below if Title is Centered

Reports to Formatted Text insert extra Carriage Return characters

Extra comma shows in reports but not in Sentence Preview

LOE does not honor the Place fields options

Place output in LOE has no separator commas

BMDB non-existent tags not included when Blanks for Missing Data selected

Journal report for Ancestors apparently produces one more generation than requested

Sensitive data in a Name always included in an Individual Narrative Index

Sensitivity markers in a sentence not removed

Children’s names do not honor Journal report Font style options

Modifying a report configuration while still within the Book Manager can cause problems

[Added 30 Sep 2015] Long report configuration pathnames cause errors for Report Destination to Screen Preview

[Added 16 Jul 2016] List of People report, “Marriage Group* tag; # of Citations” output is wrong

[Added 14 Nov 2016] Subsequent unique endnotes to the same source with same CD as first use the wrong template

[Added 31 Jan 2017] When using unique endnotes, CM text enclosed in sensitivity markers will always output

Chart output

Connection to single mother not shown on Ancestor Box Chart

Charts may output excluded data

Split Memo output may be incorrect in Charts

Text missing in Pedigree Chart when using Indexing

Endnote Header may be in the wrong place in Pedigree Chart

Selected Places always used for Place Output in Pedigree Chart

Setting Researcher information to “end of report” outputs every page of Pedigree Chart

Setting Chart destination to a file does not produce an output file

Other

Inconsistent GEDCOM Import of a Referenced Note

The GEDCOM Name part SPFX is skipped on Import

Error for built-in searching of web sites if the site changes

Text Editor Find Next not work with wildcards

Problems with merging datasets with Duplicate Tag Type names in different Tag Type groups

A Macro assigned to <Shift>+F10 will jump to the File menu after being executed

“# of Parents” filter does not work with numbers greater than zero

Filtered Simple Picklist does not re-filter after Add Person

If FTM file is imported into a New project, relationship tags are duplicated

Status indicator display for the Insert key is backwards

VCF Help does not work in WinVista and Win7

Excluding pairs only works in Check for Duplicate People if Show Excluded is checked

Merge candidates may show non-primary names for parents with name variations

Renumber People From value can change unexpectedly to zero

Soundex sorting does not group as implied by the title of the sort

Following a Restore which includes Layouts, the List of Layouts is not refreshed until close/re-open

The List of Recently Viewed People can unexpectedly include a random person which will affect who is the Focus or Previous person

Merging a dataset containing a Flag which does not exist in the receiving dataset will lose those flag values for the merged people

Data Corruption

No outstanding bugs are known which cause data corruption. Any sequence of normal actions which resulted in data corruption was always the highest priority for getting fixed. These traditionally were caught by beta testers and fixed before public release.

Program Aborts

Any sequence of normal actions which resulted in the program aborting was always a high priority for getting fixed. Thus there is only the one following known to remain, and it requires a very unusual, extended and complex sequence of user actions.

Defining new embedded source with expanded title within an expanded memo aborts program

To replicate this issue requires being nested deeply within a complex series of actions while attempting to add both a new tag and a new embedded source all at the same time. A sequence of actions which will cause the abort are:

• Add a new event tag

• On the Tag Entry Screen click the memo button to open the expanded Memo window

• Add a lengthy memo of multiple lines but leave the window expanded

• At the end of the text right click and select Embedded Citation

• In the Master Source List select Add.

• Choose and Select a Source Type

• Enter an abbrevation

• Click on the word Title to expand the title field.

• Add a lengthy title, 100 or so characters.

• Click OK to close the expanded Title window.

• Click OK to close the Source Definition screen

• Click to Select the new source from the Master Source List.

• Add a Surety value for the Embedded Citation.

• Click OK to accept the Surety.

At this point in my test the expanded Memo window closed and the program aborted. Restarting TMG and then opening the project showed that the event tag had been added to the person but the Memo was blank. The Source had been added, complete with its overly long Title, and that source now could be cited.

The abort appears to be caused by simultaneously having the Memo expanded while also expanding the Title field. There may be other cases where having two fields simultaneously expanded may also cause this abort, but I have not tried other combinations.

Workaround

Avoid having any two memo/text fields expanded at the same time. For example, I always recommend separately creating and saving new sources before citing them, and separately expanding and then collapsing fields as needed. Once separately created I cite the existing source, either directly or as an embedded citation.

Data Entry

If Add Person is Husband, Wife, or Spouse, no Marriage or Divorce group tag added with no data

In TMG HELP in the topic “Add Person Template” there is a NOTE:

If you put more than one tag type from the Marriage or Divorce group to the Add Person setup, it's the first one that will be added if no data is entered when a husband, wife, or spouse is added.

This does not match the behavior of the program. I believe HELP should say:

If you have only one tag type from the Marriage group in the Add Person setup that tag type always will be added even if no data is entered for that tag type. If you have more than one tag type from the Marriage group in the Add Person setup and no data is entered in any of these tag types, none of these tags will be added when a husband, wife, or spouse is added.

If any tag type from the Marriage group in the Add Person setup is added, and no data is entered in any tag type in the Divorce group in the Add Person setup, then no Divorce group tag type will be added. If any tag type from the Marriage group in the Add Person setup is added and there are multiple Divorce group tag types in the Add Person setup, only tag types from the Divorce group which have data will be added. Further if you answer ‘No’ to the first prompt, you may be prompted twice to create a Married Name when adding a wife or female spouse, once for the Marriage group tag type and once for a Divorce group tag type with data entered.

If no tag type from the Marriage group will be added, and there are one or more tag types in the Add Person setup from the Divorce group, the first one from the Divorce group always will be added even if it has no data. If no tag type from the Marriage group will be added, and you have more than one tag type from the Divorce group in the Add Person setup and you enter data in any non-first Divorce group tag type, the first one always will be added even if it has no data. Further if you answer ‘No’ to the first prompt, you may be prompted twice to create a Married Name when adding a wife or female spouse, once for the empty first Divorce group tag type and once for the Divorce group tag type with data entered.

If you have more than one tag type in either of these two groups in the Add Person setup, any tag type with data entered will be added when a husband, wife, or spouse is added.

If no tag types in either the Marriage or Divorce groups are added you will not be prompted to create a Married Name when adding a wife or female spouse.

There are three bugs here. First is the failure always to add the first tag type among several in the Marriage group even if no data is entered in any tag type in that group. Second is always adding the empty first Divorce tag type when there is a different Divorce tag type with data. Third is sometimes having a double prompt for creating a Married Name.

Workaround

To ensure a tag is always entered from the Marriage group do one or the other of the following:

• Change the Add Person setup to include only one tag type in the Marriage group.

• If the Add Person setup has multiple Marriage group tag types, enter some data in any of those tag types which you desire be added, even just some temporary text in its memo.

Be aware that if you answer ‘No’ to the first prompt, you may be offered multiple prompts to create a Married Name. Answer all of them appropriately.

If no tag from the Marriage group will be added and the Add Person setup has multiple tag types in the Divorce group and you only enter data in a non-first Divorce group tag type, be prepared to delete the empty first tag type in the Divorce group.

Finally, in the description above, “first” among tag types means the tag type which has been moved “up” in the Add Person setup to be before/above any others of that same tag type group.

Attempting to uncheck the Date field in the Add Person Setup gives an error

When in the Add Person Setup, you can specify which fields for a Tag Type are included in the Add Person spreadsheet. The Date field is included by default. If you attempt to uncheck the Date field you are likely to get an error of “unrecognized phrase/keyword”. In most cases none of the options of Abort, Retry, or Ignore will allow the Date field to be excluded as a field for that Tag Type. However, there appear to be no other adverse affects from receiving the error message.

Workaround

For some Tag Types, but with no clear reason why some and not others, choosing the Ignore option when the error is displayed will uncheck the field and will remove it from the spreadsheet. However, the best alternative seems to be to never uncheck the Date field, leave it in the spreadsheet for all Tag Types, and simply leave that Date field blank if no value is desired in that field when adding the person.

Style Labels not used on Add Multiple People column headings

The Add Person Template setup screen for Add Multiple People allows specifying the style to be used for a tag type. However, the Add Multiple People spreadsheet column headings for entering data for that tag do not use the field labels defined for that style. Only the Standard labels are used.

Workaround

None, you must enter data based on the Standard column labels. However, the tag will be added with the specified style.

Add Multiple People will change an existing Place Style without warning

The Master Place List can contain a Place record previously entered which uses a Place Style different than the default dataset Style set in the Dataset Manager. If the Add Multiple People facility is used, and a Place is entered which is identical to an existing Place record which uses a non-default Style, when that person is added the Style of that Place record will be changed to the dataset default without any notice or warning. If Add Person is used to add new people one at a time and a Place is entered which is identical to an existing Place record which uses a non-default Style, a warning is given that the Style may be changed, and an option is provided to keep the existing non-default Style.

Workaround

If you are adding multiple people and they will have places entered which all should use a non-default Style, temporarily change the dataset default Style in the Dataset Manager. If only a few should use the non-default style, either add these people one at a time using Add Person, or do not enter the place in the Add Multiple People worksheet. Instead edit the tag(s) after adding the people. My preference is to remove the Place columns from the Add Multiple People template and edit/add them later.

Empty person shows in a filtered PE after copying a person

Filter the Project Explorer (PE) and select a person in that list. From the Add menu, select Copy Person. The PE list has errors and now includes a person with the name “Unknown”.

Workaround

There is no error in the project data, only in the display of the PE caused by filtering. Simply click on the PE "filter" button and click OK to re-filter. The PE becomes correct and the Unknown person is gone.

Add Multiple Witnesses using Search with Expanded Picklist selects at each keystroke

If the button for Add Multiple Witnesses is clicked for a tag, and the Expanded Picklist is being used, and if characters are typed into the Search box to find the first desired person, the first person found with each keystroke is selected as one of the Multiple Witnesses. For example if the Sort is set to Given name and if the user is looking for a “Josiah”, when they type ‘J’ the Search action will Select the first person with a Given name beginning with ‘J’ (e.g. “Jacob”), then when they type the ‘o’ the Search action will Select the first person with a Given name beginning with ‘Jo’ (e.g. “John”), then when they type the ‘s’ the Search action will Select the first person with a Given name beginning with ‘Jos’ (e.g. “Joseph”). Thus three people are already selected as Witnesses without any other action by the user, and before they scroll down to find the desired “Josiah”. No such automatic selections are made with Search if the Simple Picklist is used, or if no typing is done in the Search box.

Workaround

Either do not use Search when in the Expanded Picklist, or before using Add Multiple Witnesses select to use “Simple picklist” in Preferences | Program Options | Lists. Alternatively a method which uses Search in the Expanded Picklist but is more tedious is: type the first letter and immediately click on the name highlighted (which will now unselect it), then type the next letter and click on that highlighted person to unselect it, etc. When selecting Multiple Witnesses TMG HELP only recommends scrolling and <Ctrl> clicking on each separate name; or scrolling to the first name, clicking on it, scrolling to the last name in a group, and <Shift> clicking on the last name to inclusively select all names between.

Some valid forms of Old Style date input are interpreted as irregular

A few specific forms of Old Style dates which are specified in TMG HELP as valid are interpreted as irregular. These all appear to involve forms which have two dates, where one is Old Style and the other is not. Once successfully entered by using the accepted equivalent below, depending upon the Date Format set in Preferences | Program Options | General, some of these exact forms will actually be displayed as valid.

Workaround

The following are the only valid forms which I have found are incorrectly interpreted as irregular. The workaround is to enter their equivalent accepted input form.

Irregular

Accepted Equivalent

27 Aug 1635-27 Feb 1636/7

Bet 27 Aug 1635 and 27 Feb 1636/7

27 Aug 1635-27 Feb 1636/37

Bet 27 Aug 1635 and 27 Feb 1636/37

27 Aug 1635-27 Feb 1636/1637

Bet 27 Aug 1635 and 27 Feb 1636/1637

27 Aug 1635 or 27 Feb 1637os

27 Aug 1635 or 27 Feb 1637/38

27 Aug 1635 to 27 Feb 1637os

27 Aug 1635 to 27 Feb 1637/38

27 Feb 1635os-27 Aug 1637

Bet 27 Feb 1635/36 and 27 Aug 1637

27 Feb 1634/5-27 Aug 1637

Bet 27 Feb 1634/35 and 27 Aug 1637

27 Feb 1634/35-27 Aug 1637

Bet 27 Feb 1634/35 and 27 Aug 1637

27 Feb 1634/1635-27 Aug 1637

Bet 27 Feb 1634/35 and 27 Aug 1637

27 Feb 1635os or 27 Aug 1637

27 Feb 1635/36 or 27 Aug 1637

27 Feb 1635os to 27 Aug 1637

27 Feb 1635/36 to 27 Aug 1637

Plus/minus character not recognized in date

The Plus/Minus character in front of a date ('±', produced by holding down the Alt-key and entering 0177 on the numeric keypad) is specified in HELP as an equivalent to 'circa'. When used the character is simply stripped and ignored.

Workaround

Do not use this character even though specified in HELP. Use “circa” or “about” instead. If this character is in a file to be Imported, search for it prior to the import and replace it with “circa”.

Changing a tag’s Tag Type does not also change to the associated default style for that tag type

While some believe changing tag type should not also change to the associated default style, I consider this a bug. If the user has specified a default style (e.g. Place style for an event tag type, or Name style for a Name tag type) and the user changes a tag to that different tag type, I believe the style also should change to that new type’s default. For example, if <Ctrl>V is pressed to create a Name tag, and then before entering any data the Tag Type button is clicked to change to a custom Name tag type with a custom style, the Name style remains the Style of the default Name tag type.

Workaround

When creating new tags and the standard tag type and style is not desired, do not use the keyboard shortcuts; instead choose Add a Tag and select the desired tag type. That will create a new tag with the associated default style. When changing the tag type of an existing tag, note that the style is not changed and manually change it separately.

Changing a Parent’s Relationship Tag Type can change to Type with wrong presumed sex of parent

The problem can occur if a relationship tag for a parent of the focus person is selected where the parent and child are of opposite sex, and the Tag Type is attempted to be changed. If you select one of the child options shown, the tag type for the parent will be changed to a type for the sex of the child instead of the sex of the parent. For example, if you attempt to change the Relationship Tag Type for the Mother of a son, and select “Son-something” for the type, the actual tag type automatically selected for the Mother will be “Father-something” because the son is male. TMG will then indicate this tag type is inappropriate for the sex of the Mother.

Workaround

When changing the type of a parent’s Relationship tag, choose the appropriate parent tag type not the child tag type. In the example above, instead of choosing “Son-something” for the type, choose “Mother-something”.

Changing Primary Name designation in MACHINE or UNIQWT collate sequence gives wrong sort

Names sort correctly in the MACHINE or UNIQWT collate sequence as long as the Primary designation of their Name tags is not modified. However, if a non-Primary Name tag is made Primary while in either the MACHINE or UNIQWT collate sequence, the name from that tag now will incorrectly sort to one end of the alphabet of that name’s first letter while using either of these two collate sequences. Changed-designation Primary names sort to the end of that letter in MACHINE, and to the beginning in UNIQWT. Non-Primary tags always sort correctly. Even if a changed-designation Primary name sorts incorrectly in these two collate sequences, it sorts correctly when using any other collate sequence. The wrong sort affects both the Picklists and the Project Explorer. Neither Optimize nor Validate File Integrity has any affect on the sort. Setting a different Name tag to Primary will now cause the previous Primary name to sort correctly, but the name now Primary will sort incorrectly. Editing a changed-designation Primary name tag will cause it to sort correctly.

Workaround

Do not use the MACHINE or UNIQWT collate sequences. Alternatively if one of these sequences is necessary, and you change the Primary designation of any Name tag, immediately edit the Primary name tag in some way, then edit it back to its correct value. If you desire to change the Primary designation of a number of name tags, first change the project’s collate sequence to GENERAL, then change all the Primary designations, then change back to the desired collate sequence.

Entering duplicate ending sensitivity markers causes display and report problems

[I do not actually consider this a bug, but erroneous data entry. But since the output is very unexpected, I have chosen to include this here anyway.] Data entered with two consecutive ending and un-escaped sensitivity markers will cause problems both in display and in reports. For example, if they are entered in a memo, the Person View Details will fail to display any text in front of those two markers, even if there are opening sensitivity markers somewhere in the preceding text. This loss of preceding text will also occur in reports where options are set to not output sensitive data.

Workaround

Sensitivity markers cannot be nested. If braces ‘{}’ are desired within text marked as sensitive, they must be escaped.

Entering text surrounded by unescaped brackets at the end of a sentence causes report problems

Text which is not the name of a TMG variable surrounded by unescaped brackets (e.g. “[bracketed text]”) can be entered in either a sentence template or a memo. If that text is placed such that there is other text in front of the opening bracket, but the bracketed text will output last for the tag, the space before the opening bracket will be removed.

Workaround

At least escape the opening bracket of any bracketed text which is not a TMG variable and will output last for that tag, (e.g. “\[bracketed text]”). Unfortunately note that there is a separate bug concerning using escaped brackets in a text exhibit so if the text is at the end of a text exhibit adding the escape character may not help.

Escape characters do not always work in Place fields

If the escape character ‘\’ is included as text as part of a Place field, some or all of the data in that field may be lost on output. The escape character and all text in the field will show on the screen and in the Master Place List. However if the Place record is used for a Repository address or a tag address, all text following an escape character, including the escape charater, may not be output. A second escape character later in the field may now allow subsequent text to output.

Workaround

[I have not tested all possible combinations to determine exactly what causes what text to be lost.] First, restrict the use of escape characters in Place fields to only escape those characters (such as the escape character itself) known to have special meaning in a Place field. Second, always carefully test the output of any Place record which contains an escape character.

Date format dd-mm-yyyy causes data entry problems editing Tasks

The Display date format can be set to “dd-mm-yyyy” in Preferences / Program Options / General. If this format is used and a new Task is added there is no data entry problem. But if an existing Task is edited, the empty date fields are automatically filled with “ - - ” which TMG interprets as an irregular date. Since the Research Log requires regular dates, the program will only allow you to Cancel the editing of the Task while the dates contain that text.

Workaround

If you use this date Display format, and intend to edit some existing Tasks, you could simply delete the “ - - ” text in each empty date field. That will change the date text to “__-__-____” which will be accepted as an empty date. If you intend to edit many existing Tasks, first temporarily change the date Display format to a format without dashes (e.g. to “dd Mmm yyyy”), edit the Tasks, then change the format back.

Adding or Editing a Task from a Repository limits setting the Task links

If you open the Master Repository List, Add or Edit a repository, open the Research Log from that Repository Definition screen, and then Add or Edit a Task, the linkage buttons for Person, Event, Source, and Repository are inactive. You are thus unable to add or edit non-Repository links to this Task. For all other ways to access a Task these linkage buttons are active.

Workaround

If you need to add or edit non-Repository links for a repository Task, edit the Task by directly opening the Research Log from the main window. Change the Focus to “A Repository” to show only tasks linked to repositories. Select the Task to edit and all linkage buttons now will be active.

Field sequence when using the Tab key in the Citation screen changed

Since the introduction in Version 9.0 of the ability to add a new source without leaving the Citation screen, plus the feature to preview the citation Full Footnote, the sequence of basic citation data entry fields accessed by successive pressing of the Tab key on that screen changed. While this is not a bug, this change has been confusing to existing users who became accustomed to the tab sequence.

In Version 7.04 through Version 8.08 the field sequence was:

Source #, + [add Source], light-bulb [Reminder], Citation Detail, Citation Memo, Reference, Sureties [in order 1 thru M], OK, Cancel, Help, camera [Exhibit].

It addition to putting Citation Detail immediately after Source # and adding the new features in the sequence, earlier Version 9 sub-versions differed by having various placements of Citation Memo and Sureties in the new sequence. To satisify user requests to put Sureties earlier, the final Version has the sequence:

Source #, Citation Detail, Sureties [in order 1 thru M], Citation Memo, Reference, OK, Cancel, Help, + [add Source], magnifying glass [Citation Preview], light-bulb [Reminder], camera [Exhibit], “Existing” radio button.

Workaround

For users who are accustomed to the different earlier tab sequence the alternatives are either to learn this final sequence, or to use the mouse to click to the data entry field desired.

Empty split field parts which do not include a place holder character can cause unexpected output

Several TMG fields can be split into multiple parts using double vertical bars ‘||’ which allow the individual parts to be referenced. Since Version 7 the TMG HELP has specified that empty split field parts should actually contain a single special character as a ‘place holder’. Sometimes, and only sometimes, the lack of such a ‘place holder’ can cause errors. The errors demonstrated are numerous and vary with the particular type of split field. One such error described in this document is: Split Memo output may be incorrect in Charts. Other errors, not more fully documented here, involve split citation details outputting the wrong split part, etc.

Workaround

To ensure proper behavior of empty split field parts, always include the appropriate single special character as a ‘place holder’. For more details, see the Workaround concerning the bug mentioned above, as well as the discussion of Empty Split Memo Parts in the Tag Sentence Details chapter of my on-line book.

Text Formatting

Embedded text formatting codes nested within a WEB code cause errors when ending editing

(See also: WEB formatted text with ‘&’ in URL does not work in HTML report)

The TMG WEB code consists of two parts: [WEB:]url;text[:WEB]. Although the HELP documentation warns against it, a user “can” add text formatting codes (e.g. ITAL, BOLD, UND) within the “text” part of a WEB code. This formatted text will output correctly in TMG reports. However, TMG also automatically adds COLOR codes to the text so that the TMG data entry windows will indicate that the text is a web link. When a sentence or memo field containing such text is edited later, the user added nested format codes prevents the COLOR codes from being completely removed, as can be seen if “Show formatting codes” is selected. If these partially remaining COLOR codes are not removed they will cause a TMG error when exiting the edit since the codes are no longer balanced.

Workaround

When editing any field which contained WEB text with nested formatting, always select “Show formatting codes” and remove the remaining COLOR codes before completing the edit. Since this really is a data entry error, a better alternative is to use multiple sets of TMG [HTML:][:HTML] codes to bracket the HTML command portions of the text instead of a single set of WEB codes, and thereby avoid the nested formatting and the errors which that causes. For an example of using TMG HTML codes to produce the same output as WEB codes, thereby allowing formatting codes within the text, see the Embedded Format Codes topic in the Tag Sentence Details chapter of my book describing My Way to customize TMG.

Text formatted as web code does not display in Sentence Preview or Item tips

Any text formatted with the TMG web codes of WEB , EMAIL , or HTML has display problems on the screen. If they would output as part of the sentence they do not display in the Sentence preview, and if they are part of the Memo they do not display in the tag Item tips. The start/end codes and all text within those codes are simply not displayed.

Workaround

View the actual sentence template or memo instead of relying on the Sentence Preview or Item tips. Although they do not display in these places, the report output produced is correct.

Place fields with decimal or hexidecimal HTML codes do not output using Place Style

TMG embedded HTML format marker codes can be used to insert some decimal or hexidecimal special characters. (For details and examples see the Special Characters topic in the “Data Entry” chapter of my on-line book.) If such marker codes are entered in a Place field, the report option for Places is set to Place Style, and the report destination is not HTML, then those place fields will not output.

Workaround

Unfortunately all known workarounds will affect all places output in the report. If that is not acceptable, then the output report file will have to be manually edited for places with such characters in a place field. If you do not use multiple Place Styles, you could change the report Places option to “Use selected place fields” for all Places and select the same fields as used in the default Place Style. Alternatively you could change the report Places option to “Use Short Place field” for all Places.

Exhibits

Exhibits cannot be Footnotes or Endnotes

Although available in Version 7.04, when the new report writer was completely rewritten for Version 8 the options for exhibits as Footnotes and Endnotes were announced as delayed. Those options were never implemented before development on the product ceased.

Workaround

None, all exhibits must be embedded.

Reports to HTML do not honor image exhibit centering or resizing Report Options

In Report Options on the Exhibits tab specify “Embedded”, “Center” both person and event exhibits with caption, and select “Resize image exhibits” but not for person images only. These options are honored for most report destinations and file types, but not for HTML file type output. None of the images are resized, and event images are not centered, although the person image and all captions are centered.

Workaround

If TMG HTML report output is desired then the HTML output file will have to be edited. This could be done either by manually adding and editing HTML commands or by using some HTML editor. My preferred alternative is to use SecondSite for all HTML output of TMG data.

Highlights placed wrong on scrolled Image exhibits by Graphic editor

Bug occurs in Graphic editor either for images too large to fit the editor screen, or when zoomed in on images so they don’t fit the editor screen. If, before drawing the highlight area, you use the slider to position the image so as to be able to add the marquee where you want it, the marquee is not added in the desired position. For example, if you have moved the image so that the top of it is visible, the marquee will be added below the desired position. It appears the marquee is being placed where it would be on the image if the image had not been scrolled.

Workaround

Do not scroll an image when editing. If the portion of the image desired is off the screen, then zoom out so that the portion is shown without having to scroll.

Between-sentence spacing issues with embedded text exhibits

Although output as footnotes or endnotes were options prior to the complete rewrite of the Report Writer for Version 8, only embedded text exhibits are available in the final Version. The text of an embedded text exhibit begins immediately after the narrative text of its tag. The sentence spacing which occurs between the narrative output of two tags always outputs after the embedded text exhibit, even if the text exhibit ends in a carriage return. In that case the between-sentence spacing would begin the next line before the start of the narrative of the next tag.

Workaround

If the text exhibit does not begin by forcing a new line, the text exhibit should begin with any desired spacing to follow the narrative of this tag. A text exhibit should always end with any desired punctuation as TMG will not add end-of-sentence punctuation after the text exhibit, only after the narrative which precedes the text exhibit. If the text exhibit does end with a carriage return, perhaps due to LIND or CENTER codes, a search/replace could be done in the word processor to find and remove occurrences of the exhibit’s ending carriage return and/or the between-sentence spacing on the following line.

Escaped brackets in text exhibits in reports output wrong

If square brackets are preceded by a backslash within a text exhibit, their output is incorrect (but different) for the three Report Destinations I tested (Screen Preview, RTF, and Word). Although different, all of the following cases are bugs since TMG should remove the backslash and leave the escaped square brackets.

• RTF—Both the backslash and the bracket characters are removed.

• Word—The backslash character is not removed.

• Screen Preview—Both the backslash and the bracket are removed.
In addition, the first word within the bracket is also been removed.
And the trailing space after the closing bracket is removed.

Workaround

Output to Word which at least leaves the text unchanged, then find all occurences of a backslash bracket pair and remove the backslash. Unfortunately note that there is a separate bug concerning using unescaped brackets at the end of text so leaving them unescaped may not be appropriate.

Exhibits do not display in RTF

When Exhibits are specified to “Embedded” and output to RTF a picture box is displayed at the appropriate location in the report. However, the image is not displayed, but is simply a small x indicating the image file could not be found.

Workaround

This is not actually a TMG bug, but I am including it here since some users have believed it to be a bug. When viewing the RTF for the first time in some versions of Word the relative links in the RTF file to the images need to be updated. Use <Ctrl>+A to select the entire document, then F9 to update all the links. All images should now display.

Non-primary person exhibits not output in Journal report if only Primary events selected

The output of Person exhibits should be controlled by the options on the Exhibits tab of the Journal Report Options. If “Select Embedded” and “All images” are selected a person’s non-primary Person exhibits should be output. However, if the Events option on the Tags tab is set to “Primary events” only a person’s primary Person exhibits will be output.

Workaround

I know of no way to output non-primary Person exhibits in the Journal report other than to also output all events.

Sources

Problems with Duplicate Source Element names in different Source Element groups in different datasets

There are problems with having two identically named custom Source Elements in two different datasets in the same project if the two Source Elements have the same name but are in different Source Element groups .

First, creating a Source Element in a different dataset where the Source Element would duplicate the name of a custom Source Element that was previously created in a different dataset but in a different group is allowed, since Source Element names are supposed to be specific to their own dataset. But when you attempt to use this custom element TMG thinks it is in the other group as defined in the other dataset where this name was first created.

As an example, suppose I had already created a custom Source Element named [MJH] in the Source Element Group “Author” in dataset 1. Now I choose to create a custom Source Element also named [MJH] but now in the Source Element Group “Compiler” in dataset 2. TMG should and does allow this, giving no error. But if I try to create a Source template in dataset 2 which uses both the element [MJH] and the standard element [AUTHOR], TMG will give an error saying I am using two elements which are both in the Element Group “Author”. Even though editing and examining the element [MJH] clearly shows it is in the group “Compiler”, TMG thinks that named element is in the group “Author”.

Next, a project with a custom Source Element can be merged into another project which already has a custom Source Element with the same name but in a different group. TMG will give no errors for that merge. As an example, the two datasets mentioned above with their custom source elements could have started as two projects which were then merged. This will result in two datasets in the merged project which now exhibits the problem above.

However, the merge itself causes additional problems with any incoming Source Types and sources which use that same-named Source Element in the incoming project. Any incoming Source record which has data in the same-named Source Element will have that data moved to a separate Source Element whose name is the incoming same-named element’s Source Element group. As an example, if the incoming project had the [MJH] element in group “Author”, any incoming Source record using the [MJH] element would have the data that was entered for that element moved to an element named [AUTHOR]. But the templates using the custom Source Element are not modified to the new (group) names. Continuing the example, the [MJH] element would now be empty, but the template would still have the [MJH] element, so the data now is not in the right element to give the correct source output. Further, the existing Source Types using the duplicate names produce the error mentioned above when they are edited due to TMG being confused as to which Source Element group that same-named Source Element is in.

Merging two datasets with same-named elements within the same project does not have a problem. When merging the datasets any incoming identically named custom Source Element which is in a different group than the receiving dataset is renamed when merged into the receiving dataset by appending a digit, but this modified and now not same-named Source Element remains in its original group. As an example, the incoming dataset’s same-named element [MJH] in group “Author” will be renamed to [MJH1] in the receiving dataset but will remain in group “Author”. The modification of the Source Element name is also automatically done within the incoming Source Type templates using that element, and everything seems to work correctly in the combined dataset.

Workaround

When naming custom Source Elements in different datasets in the same project avoid duplicate names occurring in different groups. Prior to merging any projects examine custom Source Element names and change the names in one of the projects to avoid duplicating any element name in the other project.

The Filter condition of Override Ibid is ignored for a List of Sources report

The List of Sources report has a Filter condition of “Override Ibid” to filter based on one of the three Operator values of: Off, Same Source, and Same Source and [CD]. A Source Definition can set one of these three options on its Output form tab to control the Ibid output of that source. For any of the three Operator choices for this condition, the Filter returns all sources no matter how that option is set within the sources.

Workaround

I have not discovered any way to find sources with a specific setting of this option other than manually reviewing each source.

Report Output

Multiple Person exhibits in DIN not display in Word output

A person can have more than one Person exhibit which all should output in a report. If a Descendant Indented Narrative (DIN) report (also called a Decendancy Narrative) is output to Word the last exhibit linked to the Person is output as many times as there are linked Person exhibits. For example, if you linked 3 person images, the last will be output 3 times. The first 2 images will not be output. [While first reports suggested this bug only occurred with a DIN report and only when output to Word, other users have mentioned seeing this behaviour in other reports such as the Journal report. I have not yet tested other reports.]

Workaround

The simplest workaround is to ensure you only have one Person exhibit per person, which by default will be Primary. One user has suggested defining a custom “Photo” tag type in the Other group. He attaches all but the Primary person image as exhibits to that tag, sets a Sort Date later than all events for the person, and defines the tag sentence as: “Some photos of [P1] follow.” If you have multiple Person exhibits assigned to the same person, when producing a DIN report you could select PDF for the output. (Supposedly one also could output to RTF and then save as Word, but I am not able to get images to output to RTF. This may be my problem or a separate bug.) Finally one could manually change the exhibits in the Word document by replacing the duplicates with the desired images.

Selected name not used in LOE and LOW reports

List of Events and List of Witnesses have output options to show the “(Selected)” name for a tag. Choosing “Last, Given (Selected)” does output the selected Surname and Given Name, but also appends the Suffix separated by a comma with no space. Choosing “Given Last (Selected)” outputs the Primary Given Name and Surname only, and does not output the Selected name.

Workaround

If you wish either of these reports to output the Selected name on that tag, you must choose “Last, Given (Selected)” and accept the added Suffix field.

Journal Report outputs some Name-Married narratives even if the Option is set to suppress

There is a Journal Report Option on the Miscellaneous tab to “Suppress married names from text” which could be interpreted to suppress the narrative output from all Name-Married tags. But the report will only suppress the narrative text from Name-Married tags whose Surname field data exactly matches the Surname field of the Primary name tag of a spouse. A spouse is identified by being the other Principal in a tag in the Marriage group. (Note that Name-Married tags can be assigned to either or both of the Marriage group Principals, regardless of their SEX flag, and suppression will work for either Principal’s narrative.) Even if the Marriage group tag selects a non-Primary name tag for that spouse, the match is done against the Surname in the Primary name tag not the Selected name tag. For example if a wife’s Name-Married tag uses a hyphenated name of her maiden and spouse surnames (e.g. Jones-Smith), this Surname data will not match the spouse’s Primary name tag and this tag’s narrative will not be suppressed. Further, if a Name-Married tag exists but there is no Marriage group tag to identify the spouse, that tag’s narrative is not suppressed since there is no spouse’s name to match against.

Workaround

I do not consider this a bug, since this option is intended to only suppress the narrative output of some of the Name-Marriage tags. However I include it here since both the option title and the HELP description would cause users to believe that the option suppressed all Name-Married tags. To suppress all Name-Married tag narratives whether the Surnames match or not, a user instead can choose “Selected” for the Tag Types on the Tags tab of the Report Options and unselect the Name-Married tag type.

Journal Report outputs “unknown spouse” even if the Option is set to suppress

The TMG HELP topic “Journal Report Options: Miscellaneous” defines the “Include missing spouse” option on the Miscellaneous tab of Journal Report Options as controlling whether “and an unknown spouse” will be output at the end of the sentence introducing the list of children. For a person with children but no spouse the Journal report will always output this “unknown” text regardless of the setting of this option.

Workaround

In the word processor search for and remove the text for the unknown spouse.

Journal Report outputs Primary name for first tag narrative even with a Selected Name

If you select a non-primary name in the first tag to output in a narrative, that name is used on the first line of Individual Narrative, Ahnentafel, and Descendant Indented Narrative reports. But in Journals, the selected name is ignored, and the Primary name is always used.

Workaround

This is not really a bug since the Journal narrative for a person is designed to always start with the Primary name. However, as it is confusing I include this program behavior here. If the Selected name is desired for the narrative of the first tag, use the variable [P+] instead of [P]. Using that variable will cause the report first to output the Primary name in a sentence by itself. Then the first tag’s narrative will follow using the Selected name.

Text font does not reset after a citation when output to Word

For a report with sources set to Footnotes, after a font change in a citation the text font does not revert to the default for text set within TMG for that report when output to Word. Instead it reverts to the default for “Normal” text as defined within that Word document. If the report is output to RTF, Screen, or PDF, there are no problems with the fonts.

Workaround

Change the default font within Word for “Normal” to be the same as the text font you set as the default font for Text in the Report Options in TMG.

Text font does not reset after font change in a Bibliography when output to Word

For a report with sources set to Footnotes, after a font change in the Bibliography the text font does not revert to the default for text set within TMG for that report when output to Word. Instead it reverts to the default for “Normal” text as defined within that Word document. If the report is output to RTF, Screen, or PDF, there are no problems with the fonts.

Workaround

Change the default font within Word for “Normal” to be the same as the text font you set as the default font for Text in the Report Options in TMG.

Unexpected Roman Numerals for Citation Reference Numbering

Various circumstances can cause citation reference numbers to be roman numerals rather than arabic numerals. The following combination of Report Options is known to trigger this:

• Memos tab - Embedded option, and

• Sources tab - Endnotes, Unique not checked

[There were reports that roman numerals could also be caused by sending both source citations and the “Memos not included in the Sentence” to footnotes and that those two types of references would be output with different style numbers to distinguish them. My tests show them both using the same normal style numbers in the final Version.]

Workaround

If you have the combination of Report Options mentioned above, try changing one of them. If both source citations and memo notes are footnotes, check the setting on the Memos tag of Report Options. If you are sending your report to a word processor, change the Roman numeral format of citation references to the format you want within the word processor. For example, in Word bring up the Footnote and Endnote dialog box, click the Endnotes button and use the Number format drop down list to choose 1,2,3.

[+] Concatenation code prints if there is no preceding sentence

The [+] code is designed to concantenate this sentence with the sentence output from the previous tag. If no tag sorts previous to this tag for this person’s narrative report, the [+] code itself is output. Many would consider this user error, but some feel the program still should not output the code. However, the output of the code could be considered a good reminder and indicator that there should be a prior sentence which is missing.

Workaround

Ensure there is narrative tag output prior to any tag with the concatenation code. Double check by searching for [+] in the output.

[:NP:] Code suppresses multiple citation references after the first

If you have a tag with multiple citations, and the Sentence contains the [:NP:] code, only the first citation will appear in narrative reports.

Workaround

Either have only one citation for tags whose sentence contains the [:NP:] code, or place the citations on the following tag whose narrative text will be concatenated to this tag due to the [:NP:] code.

Full name of ID referenced people output in Short Footnote

The TMG HELP topic “Source Definition: General” subtopic “Author / Compiler / Editor / Second Person / Subject” indicates these source elements expect one or more person’s names. The first and last names will be rearranged as required for footnotes/endnotes and bibliographies: Full footnote and endnote will be the full name starting with Given name. Short footnote will be Surname only. Bibliography will be Surname followed by a comma, followed by Given name. These source elements also accept a TMG ID number which will produce the name of that person. If an ID is used, the Full footnote, endnote and Bibliography are as expected, but the Short Footnote will output the entire name starting with the Given name.

Workaround

If the full name is desired in Short Footnotes this behavior may be useful. Otherwise, don’t use the ID number and enter the person’s name as text: Surname followed by a comma, followed by Given name.

Indent of text from LIND codes not ended in HTML report

For text marked with the TMG left indent LIND code, every block of text within those codes begins with the HTML code of:

<div style="margin-left: 3em;">

at the beginning of the line. There are never any </div> codes to end any of these indentations. This produces two bugs. First, any text following the indented text will also be indented, the indentation does not end. Second, if the indented text contains interior carriage returns, all lines of the following text are further indented at that point.

Workaround

Manual editing of the output HTML file is required. Search for any of the above beginning indentation codes and insert </div> at the end of each paragraph. Instead of producting HTML from TMG, my preferred alternative is to use SecondSite for all HTML output of TMG data.

Indentation wrong following LIND codes in any indented report

If you use the [LIND:]...[:LIND] codes to left indent any text, and that text is output in a report whose standard formatting uses any form of indenting, any text that follows for the same person does not use the correct margins but instead goes back to the page margin. This behavior began following the complete re-write of the Report Writer for Version 8. For example in the Descendant Indented Narrative (DIN) report, if the Options are to include event exhibits, and an embedded text exhibit contains text bracketed with LIND codes, any text following the LIND text, whether still within the text exhibit or for following tags for that person, begins at the extreme left margin rather than at the indentation of the current person's narrative. Indentation stays at the left margin until the beginning of the next person. The same problem of an end to appropriate indentation occurs if the LIND codes are used in a Memo and that text is output in any report using indentation such as a DIN.

Workaround

I know of no functional workaround other than to not use the LIND codes in either text exhibits or memos, which may not be practical for some users. Therefore correct indentation will have to be forced manually as post processing, and such manual actions will be dependent upon the specific word processor being used.

In Word the simplest way I have found to manually indent paragraphs following LIND text is using Styles. A set of "Quick Styles" can be created for each level of indentation by placing the cursor in a paragraph which is correctly indented for that level and using the Right mouse Styles menu item to save that paragraph style with a name appropriate to that level of indentation. Now place the cursor in any paragraph following LIND code text and manually assign the appropriate saved Quick Style to that paragraph. If you do this manual clean-up regularly, you could save a set of indentation styles to the standard Word document template which is used for new documents created by TMG. Then these styles would already be defined in the document for use.

“Include memos from witnessed events” Journal Report Option does not work

On the Memos tab of the Journal Report there are options which are all within the box for “Memos that are not included in the sentence”. If you have all of:

• a tag with text in the main Memo

• there is a person entered as a witness to that tag

• the sentence for that witness has no [M] variable or [Mn] split variable

• you run a Journal report that includes that witness person and a sentence for this person will output (i.e. is not excluded)

• “All events and witnessed events” is selected on the Tags tab of Report Options

• you do not check “None” for “Memos that are not included” on the Memos tab of Report Options

the main tag memo outputs for that witness in the manner specified for memos which are not included regardless of whether you chose to “Include memos for witnessed events” on the Memos tab of Report Options. Most users expect not checking this option would prevent both the Witness memo and the Main memo in the narrative for this witness.

Workaround

To ensure that the main tag memo does not print for a witness where this tag would print in a Journal report, include the special “zeroeth” main memo split variable as a conditional variable (i.e. <[M0]> where 0 is the digit zero) in the witness sentence. Alternatively use the Individual Narrative report which honors this main memo output option.

Empty split memo variables do not give unknown value in sentences for Name tag group

If the sentence for a tag in the Name group contains an unconditional split memo variable (e.g. [M2] not in conditional brackets) it does not output “an unknown value” when that memo part is empty. Instead it outputs the variable as text (e.g. “[M2]”).

Workaround

Ensure that any (empty) split memo variable in a sentence for a tag in the Name group is within conditional brackets (e.g. “<[M2]>”.

[P] variable always outputs a pronoun in the narrative for tags in the Name group

The [P] variable used at the beginning of a new paragraph in a narrative outputs the Primary name for all tag types except tags in the Name group. For tags in the Name group [P] always produces the appropriate pronoun.

Workaround

To ensure output of the full Primary name use the variable [P+] in sentences of Name group tags.

Prepared date in report Researcher data does not use report option date format

Most reports have an option to choose the format of date output. Reports also have an option to include Researcher data, which can include a “Prepared date” for the report. The format for this “Prepared date” does not use the format chosen for dates in the report, which I consider a bug. It always uses the format set in TMG Preferences // Program Options // General // Date for on-screen date display. The choices for this format are more limited than report option date formats.

Workaround

Since the Prepared date is only one date in the entire report, the simplest workaround is to manually change it in the report. Otherwise temporarily chose a display format close to the format desired.

Which Researcher data fields output depends upon other fields being selected

While not exhaustive, selecting some combination of Name, Address, and Date for inclusion in the Researcher information affects whether other information is output. Using shorthand of NADPEW for the 6 elements Name, Address, Prepared Date, Phone, Email and Web site, the following occurs:

• Any other elements without N and without D — output NIL.

• NA plus any other elements — output OK.

• ND without A plus any other elements — output ND only.

• AD without N plus any other elements — output D only.

• N without A without D plus any other elements — output N only.

Workaround

Always select for output at least Name and Address to ensure getting any other fields. If you do not want either of these two fields in the report, delete them manually in the Word Processor.

Using Accent colors in a Journal report produces wrong font for surname in Title and no color in an Individual Narrative

If “Honor screen Accent color definitions” is checked on the Report Options “Fonts and Colors” tab, and the focus person of the report matches an Accent condition to be colored, in the Title of a Journal report the entire name will use the Accent color but the surname's font will be the font size specified in Report Options for surnames rather than using the font size specified for Titles. The given name will be the Title font. In an Individual Narrative’s Title the focus person’s entire name will use the font style and size for titles, but will not use the Accent color.

Workaround

Manually change the font size of the surname in the Title of a Journal report. Manually color the name (if desired) in the Title of an Indivudual Narrative report.

End of sentence period added even with [:NP:] code on ending text in Journal report

If the last tag which is output for a person in a Journal report contains text which does not end with sentence-ending punctuation, TMG will add a closing period even if the tag sentence contains the [:NP:] code which should prevent the added period. The [:NP:] code appears to work correctly in all tags which are not last, and in all reports other than the Journal report.

Workaround

Either be sure that the last tag for a person ends with sentence-ending punctuation, or manually remove the undesired added ending period from the report.

CENTER formatting does not work for text in HTML report

The TMG CENTER formatting code for text produces no HTML formatting code in a report output to HTML.

Workaround

Either manually edit the HTML output file to insert the HTML <CENTER></CENTER> codes, or use SecondSite for HTML output.

WEB formatted text with ‘&’ in URL does not work in HTML report

Text formatted with the TMG [WEB:]url;hyperlink-text[:WEB] codes whose URL contains an ampersand ‘&’ character does not work when a TMG report is output to HTML. The ampersand is converted by TMG to the HTML code &amp; which adds a semicolon. That semicolon now incorrectly signals the end of the URL and the start of the hyperlink text.

Workaround

Instead of the WEB codes, use the equivalent TMG HTML codes for any URL which contains an ampersand, e.g. [HTML:]<A HREF=“url”>hyperlink-text</A>[:HTML] My preferred alternative is to use SecondSite for all HTML output of TMG data which properly handles the ampersand.

FGS Option for Blank line above and below Title gives no line below if Title is Centered

On the General tab of the Family Group Sheet Report Options there are options for the Title for it to be centered and to add blank lines above and below the Title. If both are checked there is a blank line above, but not below. If Left Justified is checked both blank lines are output.

Workaround

Manually add a blank line in the Word Processor.

Reports to Formatted Text insert extra Carriage Return characters

If the File Type chosen for a Report Destination is either Text (ASCII, formatted) or Text (ANSI, formatted) extra Carriage Returns are inserted roughly every 280 characters. These do not occur in unformatted Text output.

Workaround

Review the Text output file and delete the extra carriage returns.

Extra comma shows in reports but not in Sentence Preview

Trailing commas output in reports from Location variables or PAR variables, but the trailing comma is not shown in Sentence Preview. For example, a tag sentence could have either the Location variable or one of the PAR variables immediately preceding a Memo variable, e.g. [P] graduated <[D]> <[L]><[M]> . When there is Location data and the first character of the Memo is a period, the Sentence Preview shows the period immediately appended to the Location with no trailing comma after the Location data. However, reports output a trailing comma after the Location data immediately followed by the period from the Memo.

Workaround

Construct sentence templates expecting that if anything follows a Location variable or a PAR variable a comma will be output before that following output. Do not rely upon the Sentence Preview, check the actual output in a report. If the Location or PAR variable is the last item in the sentence template, end of tag processing automatically will replace the comma with a period.

LOE does not honor the Place fields options

The Places tab on the Report Options for a List of Events has three options. Only the first option is honored, the other two options do not produce the output specified.

• Use place styles—The fields specified by the Place Style for the place record are output.

• Use Short Place field—If there is data in that place record’s “Short place” field, that data should be output. Whether or not there is data in a place record’s “Short place” field, the “Short place template” specified in Preferences // Current Project Options // Other is always used to select the fields for output.

• Use selected place fields—This option produces the same output as the first option. The fields selected are not the ones output; the fields specified by the Place Style for that place record are output.

See also the bug below noting the lack of comma separators for LOE place output.

Workaround

There is no workaround for an LOE to output the “Short place” data in the place record, nor to output fields based on the selected fields in the Report Options. The fields output will be based either on the Place Style or on the “Short place template” depending upon the option selected.

Place output in LOE has no separator commas

If “Place” is selected as an output column, in the List of Events (LOE) report there are no comma separators between the data which is output for each Location field. While this may be by design to save column width, since all other reports which output full Location separate the fields with commas I choose to label it a bug as it makes it impossible to determine in which field a piece of data belongs.

Workaround

If a particular Location field is of interest, output that field as a separate column.

BMDB non-existent tags not included when Blanks for Missing Data selected

When “Blanks for missing data” is selected, if Birth, Marriage, Death and Burial events are missing, dummy events with the blanks for missing data are not all added to some reports. None appear added to a Journal Report, and only Birth and Marriage are added to an Individual Detail report. [These blank events used to be added in Version 7.04 prior to the complete rewrite of the report writer.]

Workaround

Add any events with no data which are desired. These could be custom tag types defined in each of these four groups, and then the report could select whether to include them. This works for the Individual Narrative report, but a blank Birth tag is ignored in the Journal report.

Journal report for Ancestors apparently produces one more generation than requested

In the Report Options for a Journal report the maximum “Number of generations” to be output can be specified. If the direction for the report is set to “Descendants”, and there are more generations available than requested, the number of generations output will include the generation of the focus person. For example if the number is 2, only the focus person’s generation and the children will be output.

However, if the direction for the report is set to “Ancestors”, and there are more generations available than requested, the number of generations output does not include the generation of the focus person. For example if the number is 2, the focus person’s generation plus the parents and grandparents are output. Thus it appears that one more generation than requested is output for Ancestors since the focus person’s generation is not included towards the maximum count.

[It is not clear if this difference is appropriate, or whether counting the focus person’s generation should be the same in both directions. But since users have found this difference unexpected I choose to include it here.]

Workaround

When setting the option for the maximum “Number of generations” to be output in a Journal report recognize that the focus person’s generation is counted differently for Ancestors versus Descendants and set the maximum generations count appropriately.

Sensitive data in a Name always included in an Individual Narrative Index

Output of sensitive data should be controlled by the exclusion Report Options on the Miscellaneous tab for an Individual Narrative. However, if some data in a Name tag field is enclosed in sensitivity braces, that data will always be output in a Name index even if “Show sensitive data” is not selected, and the enclosing braces will always output even if “With markers” is not selected.

Workaround

When in the word processor choose the option to display all index markers. Search for braces within any index marker and remove the undesired text. Now (re)create the index using the modified markers.

Sensitivity markers in a sentence not removed

Data enclosed in sensitivity markers can be entered in a sentence template or in the tag memo. If “Show sensitive data” is not checked on the Miscellaneous tab of the Report Options, neither the data nor the markers will output from either sentences or memos. If the option is checked, both the data and the markers will output from sentence templates regardless of the setting of the “With markers” option. The output of the markers from the tag memo is correctly controlled by the “With markers” option.

Workaround

Do not use sensitivity markers in a sentence template. Instead include a conditional memo part and enclose the memo data in sensitivity markers.

Children’s names do not honor Journal report Font style options

The Journal report has a Report Option on the Fonts and Colors tab to set the font style for Surnames and Given names, e.g. Bold. The children’s names in the list of children following a person’s narrative does not honor that style. Those names are output in the style selected for Text.

Workaround

I know of no way to have the names in the list of children display a separate style other than manually correcting the style of all these names in the word processor.

Modifying a report configuration while still within the Book Manager can cause problems

The Book Manager can be used to run a series of report configurations. Editing one of the individual report configurations being run by the Book Manager, while the Book Manager is still running, has been reported to cause the program to lock up. As I do not use the Book Manager myself, I have not personally confirmed this behavior.

Workaround

Exit/complete the Book Manager actions before editing any one of its reports.

Long report configuration pathnames cause errors for Report Destination to Screen Preview

If the length of the full report configuration pathname, including the filename, but not including the period and extension name, totals greater than around 129 characters, and if the Report Destination is to Screen Preview, there can be problems. The exact maximum length which may successfully be used before causing errors seems dependent upon the version of the Windows operating system. Users of Win XP Pro SP2 (32-bit) have reported full pathnames to a maximum of 132 characters will work. Users of Win 7 Pro (64-bit) have reported a maximum of 129 characters works. Configuration pathnames up to the maximum appear to work regardless of the Report Destination. Full pathnames longer than the maximum appear to work when the Report Destination is to a File type, such as Word or RTF. Report configuration full pathnames of length greater than the maximum fail to produce output if the Report Destination is to Screen Preview. Further, if the full pathname is even longer the program can produce significant error messages with this Report Destination.

Workaround

Either restrict the length of full report configuration pathnames to a maximum of 129 characters (the shortest maximum reported so far), or do not specify a Report Destination of Screen Preview for reports with longer configuration names. One workaround to allow longer filenames is to store the configuration files in a folder with a shorter pathname, such as a folder directly under the root of the disk drive, and change the folder which is set in the project’s Preferences for configuration files to that folder. While the maximum total will still be in effect, this will allow longer, more descriptive, configuration filenames. [Note: this error has been tested and demonstrated with List of People and Journal reports, and is assumed to be an issue with all report types sent to Screen Preview.]

List of People report, “Marriage Group* tag; # of Citations” output is wrong

In a List of People report if you set an output column to “Marriage Group* tag; # of Citations”, the output is wrong. This should list the number of citations to the Primary tag in the Marriage Group. However, the number will be the same for all people regardless of the number of citations. It is not clear what number is being used, but is often simply ‘1’ for all people.

Workaround

First, if the filter conditions for the List of People are complex, run that filtered List of People report, but use the Secondary Output Report Options to set a Flag to ‘Y’ to identify only these people. Then use the List of Events report instead and filter conditions such as:

( Principal1... || flagname || = Equals || Y ||   OR

  Principal2... || flagname || = Equals || Y || ) AND

  Tag Type Group is ||   || Marriage || AND

Note carefully the parentheses which are needed when you ‘OR’ two conditions. In the output columns include “Number of Citations” along with any other information of interest. This will list all tags in the Marriage Group which also match any additional filter conditions. Because it will do that it would probably be a good idea to also output the Tag Type Label. If you wish the output to be exactly what would have output from the List of People report, you can restrict the output to only those tags which are Primary by using the additional filter conditions of:

( Principal1... || Primary Marker is || On ||   OR

  Principal2... || Primary Marker is || On || )

Again note carefully the parentheses which are needed when you ‘OR’ two conditions.

Subsequent unique endnotes to the same source with same CD as first use the wrong template

If the Report Option for Sources selects “Unique Endnotes” and the citations and source templates include both Citation Details [CD] and Citation Memos [CM] then some subsequent unique endnotes for the same source can use the Full Footnote template, rather than the Short Footnote template as expected and described by TMG Help.

In the discussion below which mentions the "first" unique endnote or "subsequent" unique endnotes of the same source, the definition of "first" and "subsequent" is based on the order that the endnotes are produced within the report, not the order of the tags for which they are citations in the Details screen. For example, some report options place BMDB tag output before other tags. Those BMDB tags will produce endnotes in narratives before other tags with earlier Sort Dates. The “first” citation to a given source in the TMG Master Source List will use the Full Footnote template for that unique endnote. “Subsequent” citations for the same source but which have uniquely different text in the [CD1] and/or [CM1] from any previous citation to that source will be considered to be uniquely different citations and should use the Short Footnote template for these subsequent unique endnotes.

There is a remaining bug associated with any subsequent unique endnote where the [CD1] is the same as the [CD1] in that source's first unique endnote. Those subsequent unique endnotes which have that same [CD1] but (by definition) have a different [CM1] will use the Full Footnote template instead of the Short Footnote template as specified in Help. This improper use of the Full Footnote template is only based on these endnotes having the same [CD1] as the first and is not affected by their order among other subsequent unique endnotes for that source with different [CD1] .

All subsequent unique endnotes where their [CD1] is different than the [CD1] in that source's first unique endnote will use the Short Footnote template as specified in Help. The Short Footnote template will be used whether these subsequent unique endnotes have the same or a different [CM1] as that source's first unique endnote.

Workaround

Either do not choose the “Unique Endnotes” report option if multiple citations to the same source would have the same Citation Detail as the first endnote but could differ only by the Citation Memo. Otherwise manually use the word processor to edit the format of subsequent endnotes to the same source which use the Full Footnote template after the report is generated.

When using unique endnotes, CM text enclosed in sensitivity markers will always output

If the Report Option selects both “Endnotes” and “Unique” for the output of sources, and the citations and source templates include Citation Memos [CM] which contain text surrounded by sensitivity markers, then the sensitive text and their markers will always output regardless of the setting of the Report Options on the Miscellaneous tab concerning sensitive data. These options concerning sensitive data are correctly honored for the Citation Detail [CD] , and honored for Citation Memos [CM] using any other choice for the output of sources.

Workaround

Either do not choose the “Unique Endnotes” report option if any Citation Memos [CM] contain text surrounded by sensitivity markers. Otherwise manually use the word processor to search for sensitivity markers (“{}”) within the Endnotes and remove any undesired text.

Chart Output

Connection to single mother not shown on Ancestor Box Chart

If you produce an Ancestor Box Chart where a person has only one parent recorded, then the connection line from parent to child works as expected if that parent is the father. But if that one parent is the mother, then the connection line from child to the mother is omitted.

Workaround

Edit the chart in Visual Chartform and add the missing connection lines. To aid in finding these children, use a List of People report with an appropriate filter like:

# of Fathers || = Equals || 0 || AND

# of Mothers || = Equals || 1 || END

Charts may output excluded data

Some charts have a Chart Option on the Data Types tab to allow specifying specific split Memo parts (e.g. Memo1) as output for a type of person. There is also a Chart Option on the Other tab to select whether to show excluded and/or sensitive data. In all cases setting these options to not output data with exclusion markers is not honored. The markers and text are always output. --BUG--

[I have verified this behavior in the Ancestor Box, Descendant Box, and Hourglass charts.]

Workaround

If a specific memo part of a tag type is selected for output, either accept the output of excluded data or ensure that the text of all tags to be output of that type has no exclusion markers of any type, single or double excluded or sensitivity, in the selected memo part. The text and the exclusion markers will always output. Otherwise as there is no text search capability in VCF, the Chart will have to be carefully visually reviewed for such exclusion markers and the text and markers manually deleted.

Also note the following bug report which describes how memo parts not selected for output can sometimes still be output with their text and exclusion markers regardless of the exclusion options.

Split Memo output may be incorrect in Charts

Some charts have a Chart Option on the Data Types tab to allow specifying a specific split Memo part (e.g. Memo1, or Memo3, etc.) as output for a type of person. If the entire Memo is empty there is no issue. If the Memo is not split (only has text in the first memo part subfield) there is no issue. If the required placeholder character is entered in every memo part intended to be empty there is no issue. (The required single placeholder characters for the various split memo parts are described in the Workaround below. For details of empty split memo placeholder characters, see the Empty Split Memo Parts topic in the “Tag Sentence Details” chapter of my on-line book.)

Otherwise if the Memo has multiple split parts some of which have text and some are completely empty of text (not even their placeholder character), what data is output from the entire Memo for a selected memo part depends upon whether the split memo part selected to be output is Memo1, or a later part.

[I have verified this behavior in the Ancestor Box, Descendant Box, and Hourglass charts.]

If Memo1 is to be output:

• If there is any ordinary text in the first memo part subfield the output correctly contains only that text regardless of whether there are other split memo parts and whether any of them are selected for output.

• If Memo1 contains only its special Tab placeholder character, it will be treated correctly as empty.

• If there is no text of any kind in Memo1 (not even only its Tab placeholder character) but there is text in some other later split memo part, the entire Memo text containing all memo parts is output as Memo1, and the separation codes of two double bars are replaced with a semicolon followed by a space. The Memo1 line is now treated as non-blank. --BUG--
Since only Memo1 was specified, no other part of the memo should be output. Those memo parts not selected but now output may contain data with exclusion markers, which will be output along with their markers. This Memo1 line will be output even with the option to Remove blank lines, or the option to use Blanks for missing data, as Memo1 now is treated as non-blank.

• If the text in Memo1 consists of any form of exclusion markers (single dash, double dash, or sensitivity braces), as mentioned in the bug above the Memo1 text is output with the exclusion markers regardless of the Chart Option settings on the Other tab to select whether to show excluded and/or sensitive data. Memo1 is now treated as non-blank. --BUG--

If any memo part after the first is selected to be output:

• If Memo1 is empty (not even having only its Tab placeholder character) no selected other memo part is ever output regardless of the contents of that or any other memo part. As the entire Memo is contained and output in the Memo1 line, all other memo parts are considered blank. --BUG--

• If Memo1 is non-empty (including having only its Tab placeholder character or having text with exclusion markers) but the selected other memo part (or any earlier memo part) is truly empty (not even its space placeholder character), that other memo part may not be considered blank even if it is empty. Whether empty or not the text output may be from some other memo part not even selected, and whatever text is output may also include a single leading vertical bar. --BUG--

• If Memo1 is non-empty (including having only its Tab placeholder character or having text with exclusion markers) but the text in the non-empty other selected memo part consists of any form of exclusion markers (single dash, double dash, or sensitivity braces), as mentioned in the bug above the memo part text will be output along with the exclusion markers regardless of the Chart Option settings on the Other tab to select whether to show excluded and/or sensitive data. Further that memo part line is treated as non-blank. --BUG--

Workaround

First, any split memo part subfield which is intended to be treated as blank should contain its placeholder character. This should be done for all split memos in TMG, but must be done for any memo whose memo parts are to be output in these charts to avoid this bug.

Existing projects may have some memo subfields which were entered completely empty, lacking their necessary placeholder character. The TMG Utility “Other / Find and Replace” feature can be used to globally insert the appropriate placeholder character into whatever empty memo parts require them. Details about using the TMG Utility to insert these placeholder characters are described in the Empty Split Memo Parts topic in the “Tag Sentence Details” chapter of my on-line book. Ensuring all memo parts intended to be treated as empty contain their appropriate single placeholder character will avoid all issues with this bug.

The single placeholder character required for the first memo part subfield is an actual ASCII Tab character. This character can only be entered within TMG by using Alt + 0009 on the numeric keypad. Having only this placeholder character in the first memo part will ensure this memo part is treated as blank by the chart options (such as removing the blank Memo1 line if that Miscellaneous option on the Other tab is chosen). Further since Memo1 is now non-empty, the entire Memo with all subfields is not output as Memo1.

The single placeholder character required for all memo parts after the first is a single ordinary space character. Having only this placeholder character will ensure this memo part is treated as blank by the chart options (such as removing that blank memo part’s line if that Miscellaneous option on the Other tab is chosen). Further since that memo part is now non-empty, subsequent memo parts will output their own text correctly.

If all empty memo parts do not contain their placeholder character, the chart must be carefully visually reviewed to manually remove unwanted memo text or manually insert any desired memo text which did not output.

For more details, and ways to globally insert these placeholder characters, see the discussion of Empty Split Memo Parts in the Tag Sentence Details chapter of my on-line book.

Text missing in Pedigree Chart when using Indexing

[I do not use indexing in my charts, so have not verified this bug.] If indexing is included with a Pedigree Chart some text for some lines may not appear in the output due to the included indexing codes causing line wrap which hides the wrapped text.

Workaround

Either do not use indexing, or reveal formatting codes in the Word Processor and manually modify the placements of codes in the affected lines.

Endnote Header may be in the wrong place in Pedigree Chart

If Sources are set in a Pedigree Chart to Endnotes (unique or not), and there is enough data missing to not fill the last chart page, the Endnote header will appear at the bottom of the last chart page instead of at the top of the Endnotes. This can occur with both 4- and 5-generations in Print Preview and PDF. The heading will output correctly at the top of the Endnotes in Word and RTF.

Workaround

Review the output in Print Preview to determine if there will be a problem when outputting to PDF. If so, do not output that Pedigree Chart to PDF, but output to Word and convert to PDF.

Selected Places always used for Place Output in Pedigree Chart

For a Pedigree Chart in the Report Options on the Places tab there are three options for Places: “Use place styles”, “Use Short Place field” and “Use selected place fields”. Regardless of the option selected, the currently selected place fields (even if grayed out) are always used to determine the Place output for this report. For example, if specific data is entered in a Master Place Record in the “Short place” field, and “Use Short Place field” is selected Report Options, that data is not output in this report. If “Use place styles” is selected, the style assigned to that Place in that tag is not used.

Workaround

You can specify which place fields are used with the option for selected place fields, but neither the Short Place data nor Place Styles will be used in this report. If that different data is desired, the text will have to be manually modified with find/replace in the Word Processor. Alternatively use the Compressed Pedigree report which will honor the selected Places option for output.

Setting Researcher information to “end of report” outputs every page of Pedigree Chart

While the Report Option to output the Researcher information “At the end of the report” works for most report types, that information is output at the bottom of every page of a Pedigree Chart report. It appears that the program is treating each chart as a separate “report”.

Workaround

If the output is only desired at the end of all the charts, the extra output could simply be deleted in the word processor. For a Pedigree Chart report with lots of pages, the simplest method seems to be to run the report once with the option “At the end of the report” and copy the Researcher report text. Then run the report again with the option of “None” and paste the copied Researcher text at the end of the document.

Setting Chart destination to a file does not produce an output file

The report destination for a chart can be either “View in Visual Chartform” or “Save to” a file using file types of bmp, jpg, or vc2. Regardless of the file type chosen, no file is created. A VCF window blinks open and then closed, and there is no errror message.

Workaround

Choose the report destination of “View in Visual Chartform” and when the chart opens in that program use its Save feature to save the chart as the file type vc2. I know of no direct way to produce a bmp or jpg file type.

Other

Inconsistent GEDCOM Import of a Referenced Note

There are two GEDCOM structures defined for including a NOTE within various GEDCOM structures: a direct NOTE structure and a referenced NOTE structure. The GEDCOM 5.5 standard specifies that within any structure where a NOTE is permitted, either or both of the two NOTE structures may be used. TMG Import appears to handle a direct NOTE structure correctly except within a PLAC structure where the import warns it is skipped. TMG Import of a referenced NOTE structure produces a variety of results depending upon which GEDCOM structure the reference to the NOTE is within. A GEDCOM referenced note exists so that the same note can be referenced by multiple GEDCOM structures. An example of a GEDCOM referenced note is:

1 BIRT

2 DATE 07 NOV 1952

2 NOTE @N123@

-----

0 @N123@ NOTE Referenced not

1 CONC e with concatenation

Results of tests of GEDCOM import for both NOTE structures within all types of GEDCOM structures follow:

• INDIVIDUAL_RECORD (@<XREF:INDI>@ INDI ...)
no import warnings
Direct NOTE imports correctly as a separate "Note" tag
Referenced NOTE imports correctly as a separate "Note" tag

• EVENT_DETAIL (within one of the defined events or within EVEN/TYPE)
no import warnings
Direct NOTE is correctly entered in event's Memo
Referenced NOTE is only partially imported:
text on referenced NOTE line not imported, data lost --BUG--
but text on following CONC line imported correctly into the event's Memo

• PLACE_STRUCTURE (PLAC ...)
import warning for both NOTE structures that they are skipped
note is not entered as comment in Place record
(While I believe it should be imported, at least a warning is given, so no bug.)

• PERSONAL_NAME_STRUCTURE (NAME ...)
no import warnings
Direct NOTE is correctly entered in Name tag Memo
Referenced NOTE is not entered in Name tag Memo, data lost --BUG--

• SOURCE_CITATION (SOUR ...)
no import warnings
Direct NOTE is correctly entered in Citation Memo
Referenced NOTE is not entered in Citation Memo, data lost --BUG--

• SOURCE_RECORD (@<XREF:SOUR>@ SOUR ...)
no import warnings
Direct NOTE is correctly entered in Source Definition comments
Referenced NOTE is not entered in Source Definition comments, data lost --BUG--

• SPOUSE_TO_FAMILY_LINK (FAMS @<XREF:FAM>@ ...)
no import warnings
Direct NOTE imports correctly as a separate "Note" tag
Referenced NOTE imports as a separate entirely empty "Note" tag
It correctly creates a separate tag, but since it is empty data is lost --BUG--

• FAM_RECORD (@<XREF:FAM>@ FAM ...)
no import warnings
Direct NOTE imports correctly as a separate "Note" tag with both spouses as Principals
Referenced NOTE imports correctly as a separate "Note" tag with both spouses as Principals

Workaround

Most bugs occur with a referenced NOTE. Thus pre-processing a GEDCOM file and removing all referenced NOTEs by duplicating the NOTE text where ever its reference occurs seem the best workaround.

The GEDCOM Name part SPFX is skipped on Import

The GEDCOM Specifications 5.5 defines a surname prefix name piece using the SPFX tag in its Name Structure. TMG exports its PreSurname name tag part to this GEDCOM tag. Even when the Import option “Read NPFX/GIVN/SURN/NSFX names” is selected, TMG GEDCOM Import does not recognize this GEDCOM name piece tag and gives a warning in the Import Log that it is skipped .

Workaround

The warnings will need to be matched to the people in the GEDCOM file and the skipped PreSurname data manually entered in their Name tags.

Error for built-in searching of web sites if the site changes

The TMG “Search the Web” feature has a list of sites to search. The web commands to search each site is hard-coded in TMG. If the site changes how it is searched, the TMG feature breaks.

Workaround

There is no workaround within TMG as this is hard-coded in the program. The only alternative is manual searching of the changed site.

Text Editor Find Next not work with wildcards

On the TMG Tools menu is a Text Editor. If <Ctrl>F is pressed when editing a file in this Text Editor, a Find window opens which includes an option to use wildcards. If the option is selected and the search finds the first match, pressing Find Next will not proceed to the next match. The cursor must be placed past the first match to then find the next. If the wildcards option is not selected Find Next will automatically proceed to the next match without moving the cursor.

Workaround

If using wildcards, manually move the cursor past the first match before pressing Find Next or <Ctrl>G.

Problems with merging datasets with Duplicate Tag Type names in different Tag Type groups

There is a problem with merging two datasets where an identically named custom tag type exists in each dataset, but in different tag groups. Following the merge the two same-named tag types will be merged to one tag type, and thus any tags of the duplicated name in the sending dataset will have their group changed to the tag type group of the same named tag type in the receiving dataset. For example if a tag type named “XYZ” was in the Address group in the sending dataset, and there was a tag type also named “XYZ” in the receiving dataset but in the Marriage group, all “XYZ” tags in the sending dataset will now become tags in the Marriage group in the combined merged dataset.

Workaround

Review the names of all custom tag types, and ensure that there are no duplicate names in different tag type groups. Change the name in one of the datasets to avoid the duplicate names.

A Macro assigned to <Shift>+F10 will jump to the File menu after being executed

A Macro assigned to <Shift>+F10 has an added behavior not shown with macros assigned to other keys. Pressing <Shift>+F10 enters the macro text but also immediately jumps to the File menu. However, if you click back into anywhere else on the screen, <Shift>+F10 will now work again (and jump to the File menu again). This appears to be an unavoidable interaction between Visual FoxPro and ActiveX controls used by TMG.

Workaround

Either do not use <Shift>+F10 for a macro, or immediately reposition the cursor following its use.

“# of Parents” filter does not work with numbers greater than zero

A filter of “# of parents” “equals” 0 or “does not equal” 0 works. But using any number other than zero for either condition does not produce the correct result. In most cases it either selects all names or none. This bug has been verified in both the Project Explorer and List of People report, and is likely to be present anywhere this filter is used.

Workaround

Use compound AND/OR filters based on combining the conditions “# of fathers” and “# of mothers” with appropriate numbers for each.

Filtered Simple Picklist does not re-filter after Add Person

If the Simple Picklist is being used, and it is filtered, and a person is added, when the Simple Picklist is again opened it is not filtered.

Workaround

Click the Filter button. The previous filter conditions will still be in place. Click OK to refilter. Otherwise, use the Expanded Picklist which will automatically refilter (twice!) when a person is added.

If FTM file is imported into a New project, relationship tags are duplicated

Create a New project. In that project Import a FTM file to populate the new project. All primary parent/child relationship tags are duplicated as non-primary tags. This causes numerous problems in various reports such as a Descendant Chart.

Workaround

Instead of first creating a New project and then importing, from the initial Welcome screen choose the Import option to directly import the FTM file into an empty project. If TMG is open, close the current project, then choose the Import option on the File menu to directly import the FTM file into an empty project.

Status indicator display for the Insert key is backwards

The TMG status bar includes an indicator to display the current status of the Insert/Overwrite mode. The display is backwards. The text “INS” is unlit when in Insert mode, and lit when in Overwrite.

Workaround

The text is showing the status of the mode, but must be interpreted backwards.

VCF Help does not work in WinVista and Win7

Since the separate VCF program has not been updated to be compatible with the latest Windows operating systems, the old VCF HELP files will “fail to launch” in either WinVista or Win7.

Workaround

The appropriate add-in program which can deal with these old .hlp file types must be downloaded from Microsoft and installed. Be sure to select the correct WinHelp update version (x86 or x64) to download. The add-ins can be found at:

• WinVista: http://www.microsoft.com/en-us/download/details.aspx?id=5143

• Win7: http://www.microsoft.com/en-us/download/details.aspx?id=91

Excluding pairs only works in Check for Duplicate People if Show Excluded is checked

When working with a list of Merge Candidates produced from Check for Duplicate People, if the “Show excluded pairs” option is not checked then attempting to select a pair to exclude them does not work. The confirmation warning about excluding the pair is shown, but when Yes from the warning is chosen the pair are not checked and the pair still show in the list.

Workaround

When selecting pairs to exclude, first check the “Show excluded pairs” option. As long as that option is checked, pairs may be selected and excluded as desired. Once all pairs have been selected, then uncheck the “Show excluded pairs” option to restrict the list. If further pairs are to be excluded, first check the “Show excluded pairs” option, exclude them, then uncheck that option.

Merge candidates may show non-primary names for parents with name variations

When using the tool to Merge Two People, the relationship tags for the parents are shown in the list of tags. If a parent has multiple Name-Variation tags, one of those tags is always the one used to display the parent’s name in the relationship tag regardless of which tag is set as the Primary name of the parent. Therefore the name displayed may be from a name tag which is not marked Primary.

Workaround

I can find no workaround. It is not clear to me why a particular Name tag is the one always used to display the name. When merging people be aware that the name showing for a parent may not be the name tag marked Primary for that person.

Renumber People From value can change unexpectedly to zero

While the program operates as designed and I don’t consider this a bug, some users have found the “From” value in the Renumber People option to change unexpectedly to zero. When the Tools / Renumber People window first opens, “From” is set to the current person’s ID number, and “To” is set to one number greater than the largest in-use ID number. In the “From” field if the the Picklist button (binocs) or F2 is pressed to open the Picklist window and the Picklist is then cancelled with no person selected, the “From” number unexpectedly changes to zero. The current person’s number is lost. Some consider this a bug.

If, while the “From” number is zero the cursor is placed in the “To” field and F2 is pressed, the window labelled “List of Unused ID” is opened but it unexpectedly does not contain unused IDs as it normally would do. It contains consecutive ID numbers starting with one. You are permitted to select an ID number in this list which is actually in use. The program will not let you renumber to an ID in use and when attempting to exit gives the warning “There is already a person with an ID number of nnn. Please choose an ID number that is not already in use.”

If you attempt to exit the Renumber window with either F9 or clicking OK while “From” is still zero, the program will not permit a “From” ID number which is not in use and warns you to “Please select the person that you want to renumber”.

Workaround

In the “From” field if the Picklist is opened and then cancelled without selecting a person, observe that the field is changed to zero. Either be sure to select a person from the Picklist, or ensure that the “From” field contains an ID number of an existing person. Be sure “From” has a valid number before pressing F2 in the “To” field.

Soundex sorting does not group as implied by the title of the sort

The titles of the Soundex sorts in both the Picklists and Project Explorer imply that a 3-level sort will be performed:

1) surname soundex code 2) given name 3) birth date

1) surname soundex code 2) given name 3) death date

1) given name soundex code 2) surname 3) birth date

1) given name soundex code 2) surname 3) death date

While such 3-level sorts are expected and appropriate, the actual TMG sorts are an inappropriate 4-level sort:

1) surname soundex code 2) surname 3) given name 4) birth date

1) surname soundex code 2) surname 3) given name 4) death date

1) given name soundex code 2) given name 3) surname 4) birth date

1) given name soundex code 2) given name 3) surname 4) death date

Introducing this second level of sort destroys grouping by the “other” name within a soundex code.

Workaround

There is no workaround to make the Picklists and Project Explorer group appropriately within Soundex code. The only alternative I can find is to run a separate List of Names report filtered for the desired people. That report can include separate output colums of: Soundex for either given or surname, the given and surname, and the ID. That report can then be sorted by whichever columns are desired. Such a separate report can then be used to correctly group and identify the people of interest.

Following a Restore which includes Layouts, the List of Layouts is not refreshed until close/re-open

Doing a Restore which includes Layouts, the layout files in the Backup are restored to disk, but the Menu item of View / Layouts does not include the restored layouts.

Workaround

If you close TMG and then re-open, the list is fully propagated from the restored files.

The List of Recently Viewed People can unexpectedly include a random person which will affect who is the Focus or Previous person

When entering data or changing the focus to some other person an error can occur in the list of Recently Viewed People causing one or more random people to be entered at the top of the list. That list is viewable at the bottom of the “View” menu. This erroneous list will affect many actions which are based on the program knowing who is the current Focus person, or who “was” the Previous person. As just a few examples:

• attempting to return to the “previous” person using Ctrl+L may cause an unexpected person to be the focus person

• pressing Ctrl+F12 to add an exhibit to the “current” person may add the exhibit to an unexpected person

• Tools / Renumber People may have an unexpected “current” person in the “From” field

• a new or changed tag may not be added to the currently displayed focus person but to the person the program believes, based on the erroneous list, is the current focus person

Although reports of this error were rare, users randomly encountered this error for several years across several Versions. However, no repeatable sequence of actions which would cause an erroneous list was ever determined, so the bug remains in the final Version.

Workaround

If you observe a problem possibly caused by this bug, first review the list of Recently Viewed People in the View menu. If there are unexpected people, manually force some known people into the top of the list by changing to a couple of people via their ID number. Either click the “GoTo” menu button and enter a known ID number or press Ctrl+I to enter a known ID number. Do not use any other method to change focus to known people, such as double-clicking on names. Do this to add at least two or three known people to the top of the list. Now review the Recently Viewed People list to be sure the top of the list contains these people. Some users also recommend exiting and restarting TMG at this point. Only after forcing some known people to the top of the Recently Viewed People list should you attempt to correct any consequences which may have occurred due to the random people in the list. That correction should include checking what may have occured to those random people’s data. Do not use the Recently Viewed People list itself to change focus to any of the entries below these known people.

Merging a dataset containing a Flag which does not exist in the receiving dataset will lose those flag values for the merged people

The bug occurs when merging datasets and the sending dataset has custom Flags where the receiving dataset does not have Flags of the same name. TMG will automatically create Flags of those names and defined values in the receiving dataset, but all people in the receiving dataset, including the merged people will have their values set to the default value for those created Flags. The merged people will lose their sending dataset values for those Flags. This bug was first introduced in Version 8. In Version 7.04 the values were retained for the merged people.

Workaround

For any Flags which exist in the sending dataset but not in the receiving dataset, first create those Flags with the same names in the receiving dataset. While not necessary, it also would make sense to create these new same-named Flags with the same values and definitions as the sending dataset. However, as long as the same-named Flag exists in both datasets, each merged person from the sending dataset will retain their flag value even if that value is not defined for that same-named Flag in the receiving dataset.


Disclaimer

I am not affiliated in any way with TMG™, its company Wholly Genes, Inc., or its primary author Bob Velke. I am simply a satisfied user of this software package.

Since development of this software has ceased I have constructed this document for my own use.

If others find this document useful, so much the better. I do not warrant in any way that it is accurate or useful, and any use of it is at the user’s own risk.

This document was composed with Adobe® Framemaker® using its hyperlink and HTML conversion features.

©MJH Consulting, 2014-2016. All rights reserved.