TMG™ Outstanding Bugs ©MJH

My Way Customizing TMG™; Index

TMG™ Outstanding Bugs ©MJH 1996-2021;

(Content modified: February, 2021)
This site works better with Javascript enabled.
Michael J. Hannah, Los Ranchos, NM.

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.

The categories are somewhat arbitrary on my part but may help narrow your search.

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.

Unfortunately I strongly suspect the 115 “bugs” I have identified over time are not exhaustive.1 They only include those items which I have encountered, consider erroneous or extremely unexpected behavior, can reproduce myself, and thus have chosen to label a “bug”. If some other program behavior is encountered which is considered a “bug” not included below, please post exact step-by-step details on how to replicate it on the relocated 2 TMG-L Mailing List with a suggested “work around”. If I can replicate it I will include it in this list.

(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.)

(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.)

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.

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:

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

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.

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.

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

“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.”

“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.”

1) Failure always to add at least the first tag type among several in the Marriage group even if no data is entered in any tag type in that group.

2) Always inappropriately adding the empty first Divorce tag type when there is a different Divorce tag type with data.

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.
—or—

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

Be aware that if ‘No’ is chosen to respond to the first prompt to create a Married Name, there may be offered multiple such prompts. 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 data is only entered in a non-first Divorce group tag type, be prepared to delete the empty first tag type in the Divorce group which will be added.

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.

When in the Add Person Setup, which fields can be specified for each Tag Type to be included in the Add Person spreadsheet. The Date field is included by default. If the Date field is unchecked an error of “unrecognized phrase/keyword” is likely to be raised. 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.

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.

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 for the spreadsheet columns.

None, data must be entered based on the Standard field labels for the spreadsheet columns. However, the tag will be added with the specified style.

The Master Place List can contain a Place record previously entered which uses a Place Style different than the default Data Set Style set in the Data Set 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 Data Set 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.

If adding multiple people and they will have places entered which all should use a non-default Style, temporarily change the Data Set default Style in the Data Set 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.

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”.

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.

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.

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.

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

Using the “OS” date suffix sets the date as Old Style even if this makes no sense

In general TMG will NOT convert a date whose year is within the “Old Style” range of years if input as an Old Style format but the month is not Jan-Mar. However if the input format which is used is a date followed by the letters “OS” for Old Style, TMG will mark a date whose year withing the year range as Old Style regardless of the month. This may be an appropriate way (and the only way) to record a date from some unusual version of the Julian calendar which started the new year outside the common range of January through March 25 and have TMG treat it as “Old Style”. A date entered this way will be sorted and displayed by TMG using Old Style notation. However as such dates are rare, most would consider this a BUG. It is at least an inconsistency in TMG’s input conversion routines.

Only use the “OS” suffix on a date entry with a month outside Jan-Mar if it is desired to have TMG to treat it as “Old Style”. Otherwise do not use the “OS” suffix on a date which is within the “Old Style” year range and outside Jan-Mar. Enter such a single date without the “OS” suffix and it will be treated simply as that date and not a double-year date.

Some irregular forms of date input are interpreted as regular “between” dates

Date text which is input with a trailing single quote followed by from zero to three characters (e.g. 1720’s) should be recognized by TMG as irregular. However, some forms of this input will be interpreted as a regular “between” date, which is a bug. This happens when the year ends in two zeros. For example either 1700’ or 1700’s will be interpreted by TMG as the regular date value “between 1700 and 1700”. Up to three characters following the single quote, consisting of any alphanumeric characters and most special characters (e.g 1700’xyz), will be interpreted this way. Further if the year is preceded by text indicating a valid month (e.g. Mar 1700’xyz), this date input also will be interpreted as a “between” date (e.g. “between Mar 1700 and 1700”).

Date input which is desired to be interpreted as irregular should be carefully noted when entered to determine if TMG actually interprets it as irregular. Several forms of input have been discussed by users, especially the use of a non-breaking space (Alt + 255 on the numeric keypad), to ensure TMG interprets the input as irregular.

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, thus does not produce ‘circa’.

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 users believe the program’s behaviour when changing the tag type of an existing tag of not causing the current style to change to the associated default style of the new tag type is appropriate, I consider this a bug. If the user has specified a default style for a given tag type (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 new Name tag then the tag entry screen opens. Now if before entering any data if the Tag Type button is clicked to change this new tag to a custom Name tag type with a custom default style, the Name style is not changed and remains the Style of the default Name tag type created by <Ctrl>V.

When creating new tags and the standard tag type and its default style is not desired, do not use the keyboard shortcuts; instead choose Add a Tag and select the desired tag type from the Master Tag Type list. That will create a new tag of that type with its associated default style. When changing the tag type of an existing tag, it is important to note that the style is not changed to what is assigned as default for that new tag type and must be manually changed separately if desired.

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 one of the child options shown is selected, 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 the Relationship Tag Type for the Mother of a son is attempted to be changed, and the “Son-something” option for the type is selected, the actual tag type automatically selected for this Mother will be “Father-something” because the “son” option was selected who is male. TMG will then indicate this tag type is inappropriate for the sex of the Mother.

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 when changing the Mother’s tag 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.

Avoid using the MACHINE or UNIQWT collate sequences. Alternatively if one of these sequences is necessary, and the Primary designation of any Name tag is changed, immediately edit the Primary name tag in some way, then edit it back to its correct value. You may also need to change the “Sort by” option to something else, then change it back, for a picklist to now recognize the editing changes. If there is a need 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 (e.g. {sensitive text}}) 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.

Sensitivity markers cannot be nested. If braces ‘{ }’ are desired as text within text which is also 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.

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.

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.

[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 exclusion maker or 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.

A Negative Latitude entered in the LatLong Place field requires a leading Escape character

Places in the southern hemisphere require a negative latitude value, e.g. Rio de Janeiro is at -22.906800, -43.172900. TMG requires a negative latitude value to be entered preceded by the escape character ‘\’ (e.g. \-22.906800, -43.172900) to avoid TMG treating the leading negative sign as a single exclusion value for the field. WARNING: If a negative latitude is entered in the Lat/Long place field without an escape character, TMG will automatically insert an escape character ‘\’ between that minus sign and the LatLong value. This highlights and separates the (presumed) single exclusion marker from the (presumed positive latitude) LatLong value, e.g. -\22.906800, -43.172900. Further, the addition of this separator is often not noticed since the escape character will not be added by TMG until after the cursor leaves this field.

This automatic insertion of the escape character will only occur if Preferences / Program Options / Prompts / Validate LAT/LONG values is enabled. This is because if that preference is disabled any value entered in this place field is treated as text and not considered a Latitude/Longitude value. If the placement of the added escape character is not modified, the LatLong value will be treated as a single exclusion value and in the northern hemisphere, rather than as a negative latitude. It is not clear this is a bug, as usually TMG requires escaping characters, such as exclusion markers, which could have special TMG meaning. The user may have intended entering a single exclusion LatLong value. However, since the automatic addition of the escape character can easily go unnoticed, I have included it in this list.

First when entering southern hemisphere values, always include the escape character before the negative sign of the latitude value as part of entering such values. Otherwise, double check southern hemisphere LatLong entries after moving the cursor from that field and completing the entry. If a southern hemisphere value is desired to be single excluded, two negative signs plus the escape character for the second are required: e.g. -\-22.906800, -43.172900.

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

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 “ - - ” (dashes surrounded by spaces) which TMG interprets as an irregular date. Since the Research Log requires regular dates, the program will not allow saving the Task with this irregular date. I will only allow a Cancel of the editing of the Task while the dates contain this automatic text.

If this date Display format is desired, and editing some existing Tasks is required, simply manually delete the automatic “ - - ” irregular text in each originally empty date field. That will change the date text to “__-__-____” which will be accepted as an empty date. If there is need to edit many existing Tasks, first temporarily change the date Display format to a format without dashes (e.g. to “dd Mmm yyyy”), edit all the Tasks, then change the format back.

With this sequence the linkage buttons for Person, Event, Source, and Repository are now inactive. Without these buttons active adding or editing non-Repository links to this Task is not possible. For all other ways to access a Task these linkage buttons are active.

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

Since the introduction in Version 9.0 of the ability to add a new source without leaving the Citation screen, plus the new 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.

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.

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 placeholder 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 ‘placeholder’. Sometimes, and only sometimes, the lack of such a ‘placeholder’ can cause errors. The errors demonstrated are numerous and vary with the particular type of split field. One such error described in a bug in this document is: Split Memo output may be incorrect in Charts. Another involves split citation details outputting the wrong split part. There now will be (at least) four vertical bars in a row in the CD. The footnote output in a TMG report will count too many empty parts and consider the existing parts as belonging to the wrong later split CD variable parts. The Full Footnote preview will show correctly, so the user will believe all is correct but the report output will be wrong. Other errors caused by a lack of placeholders have been reported but are not more fully documented here.

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

Adding a new Flag may cause an error if immediately moved within the list of Flags

Right click in the Flags window to “Customize flags” and “Add” a new Flag. “OK” out of the “Add New Flag” window. Since the Flag is added to the bottom of the list of Flags, only the “Move up” button of the two “Move” buttons is active. However, the new Flag is not the Flag currently highlighted/selected. The Flag highlighted/selected is still the Flag which was highlighted/selected when the Add was performed. If the “Move up” button is immediately clicked TMG will attempt to move that Flag. If that Flag is the very first Flag (which is the default when Customize flags is first entered) then an appropriate “Array Dimensions are invalid” error message will appear, since TMG is attempting to “Move up” the very first Flag, which would move it out of the list.

Immediately after adding a new Flag, notice that this new Flag is not highlighted/selected. Before doing any Move operations first highlight/select the Flag which is to be moved. Never attempt to “Move up” the first Flag in the list.

A new custom tag type in the History Group can be added in the following multiple ways, all of which will produce an error:

• Opening an existing tag of a type which is in the History Group and clicking on the Tag Type button at top left will open the Tag Type List restricted to types in the History Group. Clicking “Add” to create a new History tag will get an error.

• Open the Master Tag Type List from the main Tools menu or choose to Add a Tag. Now click to highlight an existing tag type in the History Group. Clicking “Add” to create a new History tag will get an error.

• Open the Master Tag Type List from the main Tools menu or choose to Add a Tag. Now click to highlight or leave highlighted an existing tag type not in the History Group. Click the Add button which will default to create a new tag in the highlighted non-History group. This will not give an error. However, while now in the pop-up new Tag Type Definition window changing the desired Tag Group to History for this new tag type will get an error.

The error message “Array dimensions are invalid” appears. A custom tag type in any Tag Group other than History can be created with “Add” without encountering this error.

When the error appears selecting Abort “sometimes” allows selecting a different Tag Group or cancelling the Add, but may hang the program requiring termination from the Windows Task Manager. Selecting Ignore sometimes allows adding the new tag type in the History Group, but this is not recommended. Some users have reported subsequent strange errors in the program when using that resulting added custom History tag type. Instead, the workaround below is always recommended when creating a new tag type in the History Group.

For creating new custom tag types to the History group, do not use Add. Instead in the Tag Type List first click to highlight the standard History tag type, then click Copy. Now change the name of this new History tag type in the pop-up Tag Type Definition window to the name desired.

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

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.

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.

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.

View the actual sentence template or memo instead of relying on either the Sentence Preview or Item tips. Although this text does 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, and the report option for Places is set to Place Style, and the report destination is not HTML, then those place fields will not output.

Unfortunately all known workarounds would affect all places output in the report. The most common solution chosen is to not use TMG to create HTML reports, instead use some other post processing program like Second Site. Otherwise the output report file will have to be manually edited to insert appropriate values for places which contained such characters in a TMG place field. If multiple Place Styles are not in use, another alternative is to 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 change the report Places option to “Use Short Place field” for all Places.

It is not clear this is a bug, but the behavior can be quite unexpected. While any of the Embedded Format Codes can be directly entered as text, alternatively with the cursor in a field which can be formatted one can Right-Mouse-Click to display a menu and choose a format code to be applied to selected text or at the point of the cursor. Some codes are single codes intended to be inserted at the cursor point. If no text is selected the code is always inserted at the cursor point with no affect on other existing codes. Some codes are intended to apply to all of some selected/highlighted text. If text is selected/highlighted and some or all of that text is already formatted, that existing formatting can be removed by choosing a menu item.

• If “Show formatting codes” is OFF, and the existing formatting codes within the selection are hidden:

• Choosing any menu item which would insert a single code (e.g. [:CR:], a role, etc.) will insert the code at the beginning of the selection but remove all hidden codes within the selection. —BUG—

• Choosing several of the menu items which would insert beginning and ending codes around the selection (e.g. CAP, CENTER, FONT, HID, HTML, INDEX, LIND) will bracket the selection with those codes but remove all hidden codes within the selection. —BUG—

• If “Show formatting codes” is ON, and there are existing visible formatting codes within the selection:

• Choosing any menu item which would insert a single code will insert the code at the beginning of the selection and retain the visible codes within the selection.

• Choosing a menu item which would insert beginning and ending codes around the selection will bracket the selection with those codes and retain the visible codes within the selection.

If text is to be selected/highlighted, and that selection contains existing formatting codes, and the menu available by a Right-Mouse-Click is intended to be used to add any formatting, then ALWAYS first turn ON “Show formatting codes” so that those existing codes are visible BEFORE selecting the text and using the menu.

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.

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.

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.

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, the slider is used to position the image so as to be able to add the marquee where desired, the marquee is not added in the desired position. —BUG— For example, if the image is moved 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 by the slider.

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.

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.

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.

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

• 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. —BUG—

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.

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.

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. (The required actions may differ depending upon the version of Word.)

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.

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

Problems with Duplicate Source Element names in different Source Element groups in different Data Sets

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

First, creating a custom Source Element in a different Data Set where this new Source Element would duplicate the name of an existing custom Source Element previously created in a different Data Set but in a different group is allowed, since Source Element names are supposed to be specific to their own Data Set. But when this new same-named custom element is used, TMG thinks it is in the other group as defined in the other Data Set where this Source Element name was first created.

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

This bug is also demonstrated by a project with a custom Source Element which is merged to become a second Data Set in another project which already has a custom Source Element with that same custom name but in a different group. TMG will give no errors for that merge. (The two Data Sets mentioned above with their custom source elements could have started as two projects which were then merged to become two Data Sets in the merged project which now exhibits the problem above.

However, this merge itself now causes additional problems with how any incoming Source Types and sources which use that same-named Source Element are merged into the incoming project. Any incoming Source record which has data in the same-named Source Element will have that data assigned to the Source Element whose name is the group name of the existing same-named element. 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 in that source record, but that source record’s template would still have the [MJH] element, so the data now is not in the right element to give the correct source output. Further, editing the existing Source Types using the duplicate names produce the error mentioned above due to TMG being confused as to which Source Element group that same-named Source Element is in.

Merging two Data Sets with same-named elements within the same project does not have a problem. When merging the Data Sets any incoming identically named custom Source Element which is in a different group than the receiving Data Set is renamed when merged into the receiving Data Set by appending a digit, but this modified and now not same-named Source Element remains in its original group. As an example, the incoming Data Set’s same-named element [MJH] in group “Author” will be renamed to [MJH1] in the receiving Data Set 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 Data Set.

The safest action is to manually resolve duplicate Source Element names in different groups before merging. When naming custom Source Elements in different Data Sets 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. However, merging one project into a second Data Set in another project, and then immediately merging that newly created Data Set into the existing Data Set and deleting the second Data Set seems to resolve all problems. The Data Set merge will resolve the same-name issues by renaming the incoming elements and their use in templates.

Source Element names longer than 20 characters can be entered but cause problems

New Source Element names can be created to be as long as 30 characters. Some standard source element names already exist with names longer than 20 characters. However, any source element name longer than 20 characters will cause problems, whether new or existing. If a source element with a name longer than 20 characters is attempted to be edited, its name in the Edit Source Element screen will display blank, and no name change of any length will be recognized. Also longer names will be truncated in other displays, sometimes to 20 characters and sometimes to 28, but neither truncated value will work if attempted to be used as the element name in the source definition template. The full, actual name of the source element to its total number of characters when created must be used, even if it is often hard to know what that full name is from the truncated displays. And in some cases no version of such a longer element name will be recognized as a valid source element variable in a source template.

If any source element name longer than 20 is desired to be edited, it must first be deleted and then added again with a new name of not more than 20 characters. While a bit more work I recommend temporarily to leave it alone, and first create a new element in the same group with the new shorter name. Now find all source templates which still have the old name and change them to reference that new shorter named element. Finally if desired, once the old longer name is no longer being used it can be deleted.

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.

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

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.

Change the default font within Word for “Normal” to be the same as the text font set as the default font for Text in the Report Options in TMG. If possible do this in the Word document template which will be used to create the TMG report.

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.

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.

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

If a tag has multiple citations, and the Sentence contains the [:NP:] code, only the first citation for that tag will appear in narrative reports. The other citations will simply not output. Typically the Full footnote template is used when a source is cited for the first time in a report, and the Short footnote template for subsequent citations. If the first time a source is cited is to a tag with the [:NP:] code in its Sentence, and this citation isn’t the first of multiple citations for that tag, this citation reference using its corresponding Full footnote template are missing in the report due to this bug. However if this same source is cited and output later in the report the Short footnote form will be used, even though there is no preceding Full footnote which is output in the report.

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.

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:

[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.]

If the Report Options are the combination of mentioned above, try changing one of them. If both source citations and memo notes are footnotes, check the setting on the Memos tab of Report Options. If the report is being sent to a word processor, the Roman numeral format of citation references can be changed to the format desired 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.

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.

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.

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.

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.

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.

LIND codes around a Memo variable can produce FONTM errors depending upon periods

• There is a period in the sentence template immediately before the closing [:LIND] code,
e.g. <[LIND:][M].[:LIND]>

When editing the sentence via the [Sentence] button under Tag Entry, the “[:FONTM” code is not output. But when using a report such as the Individual Narrarrative there is a extraneous “[:FONTM” code output. If the period after the memo variable in the sentence template is removed the extraneous code does not appear. However, TMG removes all but one period from the output. Second Site will output all periods entered and not produce the code error.

For TMG reports do whatever is necessary to avoid one or more of the above conditions, such as avoiding the period in the sentence template before the closing [:LIND] code. Alternatively usually multiple periods are being entered at the end of the memo when a horizontal ellipsis character ‘…’ is actually desired. On the keypad enter Alt+0133 to enter that single character. (The equivalent HTML code is ‘…’.) Using this special single character as the trailing character in the memo instead of multiple periods prevents both the error code and avoids removing the periods.

A single vertical bar character in conditional memo text is treated as the Two Principals separator

A single vertical bar character inside conditional brackets within a sentence template is intended to separate different text to be output depending upon whether only one Principal is known or two Principals are known for the tag. Only the text that precedes the bar will output if only one principal is known. Only the text that follows the vertical bar will output if both principals are known.

However if a Memo or Memo part variable (e.g. [M] or [M2]) is inside conditional brackets in a sentence template and there is a single vertical bar character within the text of that memo or memo part, TMG will treat that single vertical bar in the memo text as if it were the Two Principals separator in the sentence template at that point within the entire conditional brackets text which will affect the output of that sentence in TMG reports.

I consider this a bug. This separator (in my opinion) should only be recognized within conditional variable text contained in a sentence template. Second Site only recognizes this special meaning of this character in sentence templates, not in memos.

Conceptually TMG replaces the memo or split memo part variable with its text and only then examines the resulting expanded text within the conditional brackets for this separator character. Depending upon the number of known Principals the resulting output will either be only the resulting expanded text before the vertical bar, or only the expanded text after the vertical bar. Thus either the text before or the text after the separator bar will not output.

This Two Principals separator is honored in sentence templates (and conditional memo text) even if the tag can have only one Principal, such as a Death or Birth tag. For such single Principal tags the text following the separator can never output unless that character is escaped.

As with all the special characters which have a special use within TMG, when entering these characters as text such as in a memo, they should be entered escaped using the backslash escape character (e.g. “\|”). If escaped then a sentence with this character in conditional memo text will output the same in TMG reports and Second Site.

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]”).

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.

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

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.

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.

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 letters for the 6 elements Name, Address, Prepared Date, Phone, Email and Web site, the following occurs:

Always select for output at least Name and Address if the Researcher information is to have any other fields. If neither of these two fields is desired in the report, post process the report and delete them manually in the Word Processor.

End of sentence processing performed for a source citation even with [:NP:] code

Most embedded format codes may be used in source templates, in most source element fields used in those templates, and in a citation’s detail or memo field. However, even if the [:NP:] code appears within a source or citation field, TMG will perform end-of-sentence processing on the end of the entire citation. For example if the last character to be output in a citation is a quote (”), TMG will automatically add an end-of-sentence period before that trailing quote according to its use of North American style rules. (This also occurs in Second Site, even if the configuration Pages / Body Tags / Sentence Ending Parenthesis is set to Period After.)

A typical workaround in TMG is to enter the trailing period as an escaped character (\.) in the source element field (not in the template). Second Site now will not move that period, but TMG will still move that period to in front of the preceding quote. For TMG reports the only known workaround is to post-process and edit the report.

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.

Extra comma from [L] and [PAR] variables 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, TMG reports output a trailing comma after the Location data immediately followed by the period from the Memo.

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.

There is a default for a “Short place” template in Preferences / Current Project Options / Other for this project. Unfortunately there is a BUG in the final version where this project’s short place template can be changed, but that change is lost with no warning when the project is closed.

If an existing project’s short place template is required to be changed, the only way I have discovered is to (carefully) open the project’s *.PJC file in a text editor and change the following default line in that file to the template desired, then being careful to save it as a text file.

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.]

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.

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. —BUG— However the output of the markers from the tag memo is correctly controlled by the “With markers” option.

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

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.

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 up to a maximum of 132 characters will work. Users of Win 7 Pro (64-bit) have reported pathnames only up to a maximum of 129 characters work. 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. —BUG— Further, if the full pathname is even longer the program can produce significant error messages with this Report Destination.

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.]

Some report options for Places affect Repository Addresses differently than all other Places in report

A Master Place Record of a place linked to a Repository can be assigned a Place Style and a separate local Short Place template. These usually affect which of the ten place fields will output in reports, but do not for a Repository Address. If the Report Definition option for Places is set to “Use selected place fields” for all Places in that report, that (correctly) also affects any Repository Address and only the selected Repository fields will output. If the report’s Places option is set to “Use Short Place field” for all Places in that report, the project’s default Short Place template will be used even if the Master Place record assigned to this repository has a separate Short Place template defined. —BUG— Finally if the report’s Places option is set to “Use place styles” for all Places in that report, any assigned Place Style output template for this Place entry is ignored. —BUG— In this case the fields to be output will be only those currently selected in the report definition for the option “Use selected place fields” even though that option is not currently selected.

If the Report Definition option for Places is set to “Use selected place fields” for all Places, then all places will output as expected. If the option is set to “Use Short Place field” for all Places and separate Short Place templates are desired for some Place records, be sure that the default Short Place template will work for all Repository Addresses. If the option is set to “Use place styles” for all Places, a separate action is required to specify the fields for Repository Addresses. First choose the option “Use selected place fields”, then select the place fields to output for all Repository Addresses. Now change the option to “Use place styles” which will affect all other places in the report but will leave the choices for selected place fields to be used for Repository Addresses.

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

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.

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.

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

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

Text formatted with the TMG codes [WEB:]url;hyperlink-text[:WEB] 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 & which adds a semicolon. That semicolon now incorrectly signals the end of the URL and the start of the hyperlink text.

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.

If the [LIND:]…[:LIND] codes are used 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 that LIND text, whether still within the text exhibit or for all 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 that 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.

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 this manual clean-up is done regularly, a set of indentation styles could be saved 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.

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 3 person images are linked, the last will be output 3 times. The first 2 images will not be output. —BUG— [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.]

The simplest workaround is to ensure there is only 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 multiple Person exhibits are assigned to the same person, when producing a DIN report 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.

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 also will always output in the index even if “With markers” is not selected.

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.

Using Accent colors in an Individual Narrative produces no color for the Focus Person in the Title

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 an Individual Narrative the focus person’s entire name will use the font style and size for titles, but will not use the Accent color. —BUG—

Manually color the name (if desired) in the Title of an Individual Narrative report as part of post processing the report.

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.

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.

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

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

This is (probably) 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.

“Include memos from witnessed events” Journal Report Option does not control the Main memo

On the Memos tab of the Report Options for a Journal Report there are options which are all within the box for “Memos that are not included in the sentence”. The final option “Include memos for witnessed events” is supposed to control whether a Main memo which is not included in the Witness sentence of an event tag is to be output. The following conditions affect this Main memo output option associated with a Witness sentence:

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

• a Journal report is being run that includes that witness person, and a Witness sentence for this person will output (i.e. neither the person nor their Witness sentence is excluded)

• “All events and witnessed events” is selected on the Tags tab of Report Options controlling which event tags will output, and

• the option “None” for “Memos that are not included” is not checked on the Memos tab of Report Options, so a not included Main Memo should usually output somewhere

A not included Main memo should only be output associated with a Witness sentence if the “Include memos for witnessed events” option is checked. But if all of the above are true then a not included main tag Memo will still output associated with that Witness sentence in the manner specified for memos which are not included. Thus a Main memo which is not included in the Witness sentence is always output regardless of this option as long as any memos not included in the sentence are specified to be output. —BUG—

To ensure that a Main tag memo not included in the Witness sentence does not output 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 so that the Main memo is considered to be included. Alternatively use a different narrative report such as the Individual Narrative report where not selecting this witness events option will prevent a not included Main memo from being output.

Journal Report will not substitute the value of a variable in the Main memo text when a “not included” memo is output

Sentence variables such as People and Location variables (e.g [P] and [WO], or [L]) can be included as unconditional variables in the text of a Main event memo whose output is intended to be controlled by the “Memos that are not included in the sentence” report option. However whether for Principal sentences or Witness sentences, the Journal Report will NOT substitute the value of the variable within that specially output Main meme, but instead will output the text of the variable itself (e.g ‘[WO]’). —BUG—

Include the Main memo in the Principal or Witness sentence template itself and avoid using this report option for this report type. Otherwise use another report type like the Individual Narrative which does not have this bug.

Using Accent colors in a Journal report produces wrong font for Focus Person in Title

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. —BUG—

Manually change the font size of the surname in the Title of a Journal report as part of post processing the 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.

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.

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 consider the generation of the focus person. For example if the number is 2, the focus person’s generation plus the parents are output, as well as the grandparents. Thus it appears that one more generation than requested is output for Ancestors since the focus person’s generation is not considered towards the maximum count.

[It is not clear if this difference is intentional and 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 as a bug.]

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 not counted for Ancestors where it is counted for Descendants, and set the maximum generations count appropriately.

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.

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.

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. —BUG—

If the Selected name is desired as output for that tag in either of these reports, the output option “Last, Given (Selected)” must be selected and simply accept the added Suffix field.

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. —BUG—

• 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. —BUG—

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

There is no workaround to get 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 can only be based either on the Place Style or on the “Short place template” depending upon the option selected.

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 TMG 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.

If a particular Location field is of interest in an LOE report, output that field as a separate column.

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

In a List of People (LOP) report if an output column is set to “Marriage Group* tag; # of Citations”, the output is wrong. —BUG— 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.

First, if the filter conditions for the LOP are complex, run that filtered LOP report, but do not use the output. Instead use the Secondary Output Report Options to set a Flag to ‘Y’ to identify only these people. Finally instead of the LOP use a List of Events (LOE) report to get the desired output with filter conditions such as:

(	Field	Subfield	Operator	Value	)	Connect
(	Principal1…	flagname	= Equals	Y		OR
	Principal2…	flagname	= Equals	Y	)	AND
	Tag Type Group is		MARRIAGE

Note carefully the parentheses which are needed when ‘OR’ connects the two conditions. In the final LOE report include “Number of Citations” as an output column 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 the LOE output is desired to be more like what would output from the LOP, the output can be restricted to only those tags which are Primary by also including the additional filter conditions of:

(	*	Field	Subfield	Operator	Value	)	Connect
(		Principal1…	Primary Marker is	On			OR
		Principal2…	Primary Marker is	On		)

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

A List of Witnesses report whose filter generates a large number of match possibilities can fail

Regardless of the report destination type, a filtered List of Witnesses report on a large Data Set where the potential matches can also be large may generate an error reporting that the file:

While it might be possible to change each filter condition to be more restrictive, there is otherwise no known workaround to such a filtered report. The only alternative seems using an unfiltered List of Witnesses report of all witnesses whose output columns include all the data necessary to manually sort and filter that report. Unfortunately note the bug below that custom Flag values cannot be output in such a report. Using a Report Destination to a file where one can manually sort the columns and delete rows as desired seems the best workaround solution. Note that a Report Destination of “Microsoft Excel v5 (XLS)” may not work if all one has are older versions of Excel as this report may generate more rows than those early versions can handle. An alternative Destination then would have to be some form of unlimited text file, such as the “Comma Separated Value (CSV)” Destination.

This is more of a limitation than a “bug”, but I choose to record this limitation here. The options for output columns only include Standard Flags for Principals and Witnesses. While filters for these reports can be based on custom Flag(s), the value of any custom flag cannot be output.

A possible workaround is to use the Secondary Output of a List of People report to (temporarily?) set the value of an otherwise unused Standard Flag to the value of a custom Flag, then output that Standard Flag value. Likely unused Standard Flags are: MULTIPLE BIRTH, BIRTH ORDER, ANCESTOR INTEREST, and DESCENDANT INTEREST. The column heading in the report of such a Standard Flag can be set instead to reflect the custom Flag’s name/meaning to make the report more useful.

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.

If an Ancestor Box Chart is produced 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. —BUG—

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

(	Field	Subfield	Operator	Value	)	Connect
	# of Fathers		= Equals	0		AND
	# of Mothers		= Equals	1

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.]

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.

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 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 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—

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 mentioned above about Empty Split Memo Parts in the Tag Sentence Details chapter of my on-line book.

[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.

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

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.

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.

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.

Which place fields are to be used can be specified 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”.

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.

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.

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.

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:

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

• 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

• neither note is entered as comment in Place record
(While I believe they should be imported, at least a warning is given, so no bug.)

• Referenced NOTE is not entered in Source Definition comments, data lost —BUG—

• 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—

• 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

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 seems the best workaround.

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 .

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.

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.

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

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.

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

Problems with merging Data Sets with Duplicate Tag Type names in different Tag Type groups

There is a problem with merging two Data Sets where an identically named custom tag type exists in each Data Set, 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 Data Set will have their group changed to the tag type group of the same named tag type in the receiving Data Set. For example if a tag type named “XYZ” was in the Address group in the sending Data Set, and there was a tag type also named “XYZ” in the receiving Data Set but in the Marriage group, all “XYZ” tags in the sending Data Set will now become tags in the Marriage group in the combined merged Data Set.

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 Data Sets to avoid the duplicate names.

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 the cursor is clicked 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.

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

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.

Use compound AND/OR filters based on combining the conditions “# of fathers” and “# of mothers” with appropriate numbers for each. For example, to find people with more than two parents, and at least one of each, use this compound filter (note the parentheses):

(	Field	Operator	Value	)	Connect
(	# of Fathers	= Equals	1		AND
	# of Mothers	> is Greater than	1	)	OR
(	# of Fathers	> is Greater than	1		AND
	# of Mothers	= Equals	1	)

Filters with Subfield “Surname” or “Surname (Selected)” do not work with some operators

Some Operators and Values (but not all) give wrong results with the two values in a filter Subfield of “Surname” or “Surname (Selected)”. This regularly occurs with a filter Field of a Name tag type like “Name-Variation” and where the Primary box can be checked at the beginning of the filter condition. For example this condition attempting to match a Primary name tag:

(	*	Field	Subfield	Operator	Value	)
	✓	Name-Variation	Surname	<> Does not equal	JONES

demonstrates a BUG which involves these Surname Subfield values as it will match either all names or none depending upon various conditions. These two values in the Subfield when coupled with some Operators, like “= Equals” and “Contains”, seem? to work correctly sometimes? But in other conditions with those same Operators they do not work, and the Operators “Is empty” and “Is not empty” also have been reported to not work. This bug has been verified for this particular Name tag Type in both the Project Explorer and List of People report, and is likely to be present anywhere this filter is used. Some other Name tag Types appear? to work with these two Subfield values, but using the workaround alternate Subfield value described below is still recommended.

Another example of the two Subfield values “Surname” or “Surname (Selected)” which give wrong results is when matching a name in a List of Events:

where these two Subfield values again to appear to match either all names or none depending upon various conditions.

If possible use a condition with the value “Surname” in the Field column. Otherwise use compound AND conditions, and avoid using the values of “Surname” or “Surname (Selected)” in the Subfield column. If the Field used requires such a value in the Subfield, such as in a List of Events, instead use the alternate Subfield value “Last, Given (Selected)” with an appropriate Operator.

For the first example, using the “Surname” value in the Field column for a List of Names or a Project Explorer filter appears to work correctly in contrast to using that value in the Subfield column:

(	*	Field	Subfield	Operator	Value	)	Connect
		Surname		<> Does not equal	JONES		AND
	✓	Name-Variation	# of Tags	= Equals	1

This combination will list all people whose Primary name tag is Name-Variation, and who do not have the specified surname.

The Field of “Principal2…” in the second List of Events filter example above requires a Subfield qualifier, so use the alternate Subfield value of “Last, Given (Selected)” with the alternate Operator “Begins with”

or with the Operator “Does not begin with”. These combinations seem to work to find the events where the given Principal’s surname begins with the desired text. Unfortunately in all these cases the “Begins with” operator will also match longer surnames like “JONESTON”. Once it becomes clear what other undesired surnames are also matched, specific additional conditions of “Does not begin with” could be used to exclude them, such as excluding surnames which begin with “JONEST”.

Trying to find an empty surname using the two Surname Subfield values also often does not work, even combined with the Operators of “Is empty” or “Is not empty”. Instead this alternate “Last, Given (Selected)” Subfield and the Operators “Begins with” or “Does not begin with” can be used but in the Value field enter simply a comma, which is how a full “Last, Given” name output would begin which had no Surname.

But unfortunately and confusingly using the “Begins with” Operator to find surnames exactly “Jones” whose given name begins with ‘E’, the Subfield “Last, Given (Selected)” with the Value “JONES, E” does not work. Nor does a Value of “JONES,” with an ending comma find exactly this surname. Instead use a filter with the Subfield “Last, Given (Selected)” for the surname but with an added compound condition with Subfield “Given (Selected)” which does seem to work correctly with the Operator “Begins with”:

(	*	Field	Subfield	Operator	Value	)	Connect
		PRINCIPAL1…	Last, Given (Selected)	Begins with	JONES		AND
		PRINCIPAL1…	Given (Selected)	Begins with	E

I can find no consistency or rationale for what combination of Subfield and Operator works or does not work. But the Subfield values “Surname” or “Surname (Selected)” pretty consistently do not work so should be avoided. Generally if the combination used does not work, there will either be no matches or a match to everyone in the project, which makes the failure obvious. Different combinations will then need to be tried of Fields, Subfields, and Operators to see what correctly tests for the specific condition desired.

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.

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.

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.

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.

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.

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.

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:

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.

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.

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.

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.

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.

Now if, while the “From” number is still 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. —BUG— It contains consecutive ID numbers starting with one. Any ID number in this list which is actually in use may be selected. However the program will not let an ID in use to be used, 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 an exit from the Renumber window is attempted 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 to “Please select the person that you want to renumber”.

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.

The titles of the Sort options which include Soundex for the main sorts of both the Picklists and Project Explorer imply that a 3-level sort will be performed:

Level 1	Level 2	Level 3
Surname Soundex,	Given name,	Birth date
Surname Soundex,	Given name,	Death date
Given name Soundex,	Surname,	Birth date
Given name Soundex,	Surname,	Death date

While such 3-level sorts are expected based on the title of the option and would be appropriate, the actual TMG sorts are an inappropriate 4-level sort:

Level 1	Level 2	Level 3	Level 4
Surname Soundex,	Surname,	Given name,	Birth date
Surname Soundex,	Surname,	Given name,	Death date
Given name Soundex,	Given name,	Surname,	Birth date
Given name Soundex,	Given name,	Surname,	Death date

The automatic insertion by TMG of this unspecified second level of sort destroys the desired grouping by the “other” name part within a soundex code.—BUG—

There is no workaround to make the Picklists and Project Explorer sort and group appropriately within Soundex codes. The only alternative which uses Soundex I can find is to run a separate “List of Names” report filtered for the desired people. That report can include separate output columns of any or all of the following:

That report can then set the sort order separately for each of the desired three columns. (The output should probably also include a column for the ID Number to aid in jumping to the person.) Because the columns are sorted separately this separate report will correctly use the Soundex codes to group the names and identify the people of interest, and can be used to quickly go to each person for any other information desired.

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.

If TMG is closed and then re-opened, 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. All of the following examples are BUGS and can damage your data:

• attempting to return to the “previous” person using Ctrl+L may cause an unexpected person to become 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 have been rare, users randomly encountered this error for several years across several Versions. Unfortunately, no repeatable sequence of actions which would always cause an erroneous list was ever determined, so the bug was never fixed and remains in the final Version.

While it is unclear what “triggers” the bug the “cause” of the subsequent erroneous TMG behaviour is clear. If a problem is observed which possibly is caused by this bug, first review the list of “Recently Viewed People” in the View menu. If there are unexpected people, this list has become corrupt and is the cause of TMG’s erroneous behaviour. Two methods seem reliable in clearing this list: exiting TMG and deleting the entire list, or staying in TMG and manually inserting valid data into the top of the existing list.

If you are comfortable with editing TMG’s internal files John Cardinal noted that you can delete the entire list by opening the project’s .PJC file in a text editor, e.g. Notepad. First, EXIT TMG. (Never have TMG running when editing its system files.) Go to the bottom of this project’s .PJC file where there is a section like the following:

Save the ID numbers of these people to later check whether any of their data has been corrupted. Delete all the Person1, Person2, etc., entries, up to and including Person10. Leave the [ViewHistory] entry in place. Save the edited .PJC file and restart TMG.

Alternatively you can 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. Other actions have sometimes been known to help, but this is the only action which appears to always clear the issue.

Do not use any other method to change focus to known people when adding people to the list, such as double-clicking on names. Instead change to people via ID number 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 deleting the list or forcing some known people to the top of the Recently Viewed People list should any attempts be made 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. Even after cleanup, do not use the Recently Viewed People list itself to change focus to any of the entries below these added known people.

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

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

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

There are two ways to set the preference for whether non-primary events are shown in the Details of a person display:

• In Preferences / Program Options / Tag Box toggle the option “Show non-primary events”

• Right click in the Tags area of the Details of a person, choose the menu option “Filter for…”, toggle the option “Primary events”

Both methods will affect whether non-primary events will show while TMG is currently running, and both will indicate the tag list is “Filtered” if non-primary events are not shown. The bug occurs when using the Preferences method. The setting of this preference is NOT saved when the program is exited, even if you make a point of saving the layout. —BUG— If the Right Click Menu method is used then the preference is saved when the program is exited.

If the preference is desired to be saved, before exiting TMG use the Right Click Menu method to set the preference to the state desired.

This TMG issue is caused by the final TMG program internally containing the XP version of the Windows WinZip code to perform Backup and Restore. That Windows code had problems with filenames or pathnames which have “characters not in the original IBM PC character encoding set”. Several versions of Windows, such as XP and later, began to allow creating filenames and pathnames with non-IBM PC characters (e.g. accented characters like ‘Í’ and even some Unicode characters). However, the XP WinZip code was not updated to handle such characters. Thus when Backup stores a pathname or filename containing such newly allowed characters in the .SQZ file, that WinZip code “might” change a non-IBM PC character in that name, such as removing the accent!! Now when a Restore is done based on the names in the .SQZ file such a restored name contains a different character. But since any TMG internal links to that name still includes the original character, TMG will not be able to find the file or path with the changed character and will report that error.

The most reliable workaround is to avoid non-IBM PC characters such as accented characters, punctuation, etc., in any filenames or pathnames associated with TMG and keep them as simple as possible due to such possible complications. This is another reason I generally do not have TMG include the external exhibits as part of the TMG backup. Instead I recommend that external exhibit files be backed up outside of TMG. It has become more common and useful for the filename of an external exhibit to contain non-IBM PC characters, such as an accented person or place name, since modern Windows will allow them. Modern backup and restore programs, such as the current versions of WinZip and 7Z, when used outside of TMG will have no problems handling such names, whereas a TMG Backup/Restore can produce an error.

1. Adding the counts will total to only 113 bugs listed here. Over time I have merged bugs B01 and B23 with others.

2. The TMG-L Mailing List used to be hosted by RootsWeb. However, they ended hosting mailing lists in early 2020. At that time the TMG users moved the list to be hosted by Groups.io where it is still actively supported and maintained by users.

I am not affiliated in any way with TMG™, its company Wholly Genes, Inc., or its primary author Bob Velke, nor with John Cardinal, author of several TMG after-market programs. I am simply a satisfied user of these software packages and have constructed these documents to aid me in their use.

If others find these documents useful, so much the better. I do not warrant in any way that they are accurate or useful, and any use of them is at the user’s own risk.

These documents were composed with Adobe® Framemaker 2019®, converted using its hyperlink and "Save as HTML" features, post-processed with my custom Perl© script, linked to my Responsive CSS file, and the HTML and CSS are W3C validated.