FTST-L Archives

Archiver > FTST > 2002-01 > 1010688070


From: Terry Reigel <>
Subject: [FTST] Primary Tags - was Selecting datasets in FTST
Date: Thu, 10 Jan 2002 13:41:18 -0500
References: <BBELINAJCPNPOALLDGONKEKACFAA.clcasper@sprynet.com>


Cheri Casper wrote:

> Terry - What *might* be preferable to printing only primary tags would be
> the ability to just print whatever tags you wanted, in any group, whether
> primary or not. Probably the easiest way to accomplish this is to allow for
> more than one primary tag within a group. I haven't thought of the
> ramifications of doing this, but the concept of "primariness" still seems
> somewhat silly to me.

The concept of "primariness" is still a key aspect of many functions in TMG/FTST. First, it is key in controlling the way data is displayed on screen. The primary Name Tag provides the names used in the Person, Tree, and Family views (but not the Picklist, which shows names from all tags.) The primary Birth Group and Death Group tags control the dates shown on the Picklist, and on the Tree and Family views, and the birth tag controls the calculation of age for all other tags. The primary Parent/Child tag controls who is show as parents and children in the Person, Tree, and Family view. Being able to indicate one tag from the group as primary is key to allowing an unlimited number of such tags to record various data, but still be able to construct those screens.

Likewise, certain types of reports - I'm thinking of a pedigree as an example - have by their definition little space for data as they try to get a lot of people displayed in limited space. So here again, the primary marks control which names, birth and death information, and the like, are used.

By contrast, the various narrative style reports are intended to be able to include most anything you want. The primary Name Tag still controls the name generally used (though users have asked for more flexibility there), the primary Birth Tag still controls any age calculations, and the primary Parent/child tags control which parents and children are reported (again, with requests having been voiced to deal with adoptions and the like). But other than that, the user has extensive control over which tags will be included. True, there is still the "Primary only" option, but I view that as a holdover from the days when the other options didn't exist. And, in the article on ControlLing Printing on my website I suggest that users ignore it. In the same article, I suggest users ignore the "primariness" of tags other than the types mentioned above. I'm inclined to think the primary marking on all those Other Group tags could be eliminated, but there might be a reason to keep them !
that I've missed.

The problem we're dealing with in this thread is that the Box Charts, once seen as being in the tightly formatted category with Pedigree Charts, have enhanced capabilities in VCF ver. 2, shipped with FTST. Now they can include up to 9 items, chosen from all the Tag Types in the dataset. So they begin to achieve a bit of the flexibility of the narrative style reports. While it would certainly be possible include more elaborate controls over what is allowed to be printed, I suspect that given the limited space in such charts, which tends to limit the utility of including lots of tags, most users would place higher priorities on development of other desired enhancements.


> One option to do this would be at the tag definition
> screen. You would have a checkbox to indicate whether this tag should print
> in reports or not. Then when you added a particular tag to a person, you
> should have an override capability (like you do for sentences). Selecting a
> tag by name at the report definition would let you suppress all tags of a
> particular type or print those tags according to how their are determined at
> the definition screen subject to any individual overrides.

I'm not sure I'd like this kind of control buried in each of tens of thousands of tags. To make changes you would have to go into each tag. You already have pretty much this control, but exercisable when you define the report, by placing the data in custom tags and then selecting or not those tag types (details of doing this are described in the articles on my website -- http://reigelridge.com/tmg).

Much of this discussion of course really is about TMG, as many of the issues discussed here cannot be controlled in the read-only environment of FTST.

Terry Reigel


This thread: