TPG

I am somewhat disquieted by the entire proposal to enhance the TMG gedcom export capability to accommodate the specific gedcom import facilities of other genealogy programs. I'm not sure why I am disturbed, since most of the tweeks added (e.g. the new initial underscore tags) would be ignored in a more general setting. But I do believe that it sets a bad precedent of junking up the standard TMG gedcom export capability with special features when perhaps cleaner options might exist. I am uncomfortable with the feature of TMG becoming dependent on the import conventions of other genealogy programs. In any case, the gedcom modifications proposed would seem to only approximate the natural import requirements of the specific importing program. I also ignores other competing products' import requirements. Rather, I would suggest that we rely on separate standalone programs to provide TMG output compatible with the import facilities of particular genealogy programs. These programs would, if necessary, read the TMG proprietary data files to produce the necessary input in whatever format was needed by the importing program. This is easily done as is shown by John Cardinal's TMG Utility and by the availability of the FoxPro OLE module underlying my WitnessTMG program. We could load up these individual standalone programs with as many features as desired and, if the associated genealogy program's import requirements change, only have to modify the individual program. TomH, while he was testing my witnessTMG program, urged me to adopt many of the suggestions he has made in this forum. I resisted incorporating the changes, partially on the grounds noted above. By the way, the modifications to the TMG export facility leaves intact what I consider to be the greatest deficiency in its gedcom export facility - namely the requirement that the owners of a joint event have to be married or at least be the joint parents of a child. Changing this to allow the event to appear as separate events under each individual should be relatively easy.

NOTE: This posting was also placed in the "Discontinuation of TMG" topic, where it is also relevant. Witness TMG Program Builds witness entries from TMG propritary project files and includes them in a compatible TMG generated GEDCOM file. The witnessTMG program asks that the TMG project be identified in the form of the core " . . . __.PJC" file of the project. It also asks for the input GEDCOM file to be identified. After the program processes and inserts the witness data, a new GEDCOM file is left in the program's folder as "newGEDCOM.ged". The generated witness statements are inserted as 1 EVEN 2 TYPE Witness: [role] in [eventtype] for [Prin1] and [Prin2] ** 2 DATE [date]* 2 PLACE [place]* * entry is omitted when [date] or [place] is blank. ** either or both [prin1] and [prin2] is omitted when blank. It was originally developed to use gedcoms produced by some earlier versions of TMG. It was then revised to handle gedcoms produced by TMG Version 8. Tom Holden, another contributer to this forum, has successfully tested it with gedcoms produced by TMG version 9. You may download the witnessTMG package via www.crestline-enterprises.com/witnessTMG. The WitnessTMG package is in the form of a zip file, whose only content is the "WitnessTMG.exe" program. One should extract the program from the zipped package and store in a convenient folder. You can run it from this folder, which becomes the folder containing the output "newGEDCOM.ged". IMPORTANT NOTE: In order for the WitnessTMG Program to be able to read the internal files of The Master Genealogist, one must first install the Microsoft VFPOLEDB facility before installing the WitnessTMG Program. This can be gotten from: http://www.microsoft.com/en-us/download/details.aspx?id=14839 I believe that one may choose either of the relevant installers to download, although I have used VFPOLEDBSetup.msi. After the VFPOLEDB facility has been installed, one may install the WitnessTMG Program. All that is strictly required is that the GEDCOM file have the same numbering conventions of the TMG file and that the TMG file include all individuals that occur in the GEDCOM file. This requirement is most easily satisfied if the TMG project is the project file itself used to generate the GEDCOM file or is a superset of that project file.

Let me first establish some context in which witnessTMG was written. I wrote it originally for my own use and it was intended to massage the gedcom input for my own Progenitor 4 program by adding witness statements. Progenitor 4 is an elaborate and sophisticated genealogy display program that is ultimately an evolution of the original Progenitor 2 from the late 1990s. Progenitor 4 takes gedcom input and produces an entire website for uploading, much as Second Site does from TMG file input but without some of the bells and whistles. Some of the more minor design choices in witnessTMG were driven by the need to serve furnish input to Progenitor 4. (If you are interested in seeing the output from Progenitor 4, please go to http://www.crestline-enterprises.com/genealogy/giammoFamily/wg_Advanced.htm. I'd advise you to look at the GUIDE before proceeding to gain some familiarity with its capabilities.) Jim Byram and Tom Holden convinced me to revise and release witnessTMG, Tom Holden was also very helpful in testing the revisions and ascertaining that it ran with TMG version 9 project input files. Now, let me answer your specific questions - * Yes, the WITNESS statements are inserted as part of the INDI structure of the relevant individuals. * [Prin1] and [Prin2] are the "N:srnamedisp" full display names of the individuals. * I was aware of the limit of 90 characters, but did not believe that it would be a serious limitation - at least not in the application for which it was intended. Although the maximum size of each of the fields might cause an overflow of the 90 characters, the "role" and "eventtype" fields are relatively small and shouldn't make that much of a difference. Thus, I am reluctant to make use of the CAUS statement, which is also not how the gedcom standard envisions its use. * Your use of the NOTE field implies that witnessTMG would have to parse the [witness memo] and insert substitutions for the various sentence variables. That is beyond what I am willing to do.

WitnessTMG Program Builds witness entries from TMG propritary project files and includes them in a compatible TMG generated GEDCOM file. This version of "witnessTMG" is the same program that was first announced on the Rootsweb TMG forum. It has been revised to work with TMG version 8 or 9 files. The program asks that the TMG project be identified in the form of the core " . . . __.PJC" file of the project. It also asks for the input GEDCOM file to be identified. After the program processes and inserts the witness data, a new GEDCOM file is left in the program's folder as "newGEDCOM.ged". For reference purposes, the newly generated WITNESS statements are collected in a file named witnessOut.txt, stored in the same folder. The generated witness statements are inserted as: 1 EVEN 2 TYPE Witness: [role] in [eventtype] for [Prin1] and [Prin2] ** 2 DATE [date]* 2 PLACE [place]* * entry is omitted when [date] or [place] is blank. ** either or both [prin1] and [prin2] is omitted when blank. "witnessTMG" was originally developed to use gedcoms produced by some earlier versions of TMG. It was then revised to handle gedcoms produced by TMG Version 8. Tom Holden, another contributor to this forum, has successfully tested it with gedcoms produced by TMG version 9. You may download the witnessTMG package via www.crestline-enterprises.com/witnessTMG. The WitnessTMG package is in the form of a zip file, whose only content is the "WitnessTMG.exe" program. One should extract the program from the zipped package and store in a convenient folder. You can run it from this folder, which becomes the folder containing the output "newGEDCOM.ged". IMPORTANT NOTE: In order for the WitnessTMG Program to be able to read the internal files of The Master Genealogist, one must first install the Microsoft VFPOLEDB facility before installing the WitnessTMG Program. This can be gotten from: http://www.microsoft.com/en-us/download/details.aspx?id=14839 I believe that one may choose either of the relevant installers to download, although I have used VFPOLEDBSetup.msi. After the VFPOLEDB facility has been installed, one may install the WitnessTMG Program. All that is strictly required is that the GEDCOM file have the same numbering conventions of the TMG file and that the TMG file include all individuals that occur in the GEDCOM file. This requirement is most easily satisfied if the TMG project is the project file itself used to generate the GEDCOM file or is a superset of that project file.

In your post directed at me, you snidely said: "Please describe any free software you supplied that helps TMG users." I have supplied a program, witnessTMG, in various forms. The program reads the TMG proprietary files and inserts the relevant WITNESS statements into a TMG generated gedcom. Notice of it was first posted to this forum long ago and has since been cited by Jim Byram. The latest revision has been posted to the Rootsweb TMG forum. I intend also to post the latest revision to this forum. I don't want to get into a contest regarding the cause of TMG's demise. It was you, however, who chose to blame a class of TMG users for its failure. In an earlier post, you said "TMG users who didn't upgrade are a leading cause of the demise of TMG". I believe this to be rather mean-spirited and narrow minded of you. I still don't believe that common users have any moral obligation to support any software product through the purchase of unneeded upgrades. The product and its upgrades should be priced to be self-supporting. If that prices the product and its upgrades out of competitiveness, then something is amiss. Perhaps TMG has always been mispriced - but that is not the users fault. Those users who do not religiously purchase each new version are making a simple economic decision based on the value of a particular upgrade to them vs. its cost. Regarding your support to WG, I am sure that you are to be commended. But the fact is that the nature and extent of this type of support was not sufficient to save TMG. Your Second Site program depends on a flourishing base of TMG users. Helping out on TMG conferences allows you to cultivate future Second Site users. Supplying your very useful TMG Utility could also well be viewed as shrewd advertisement. It is true that I do not know the exact gross sales from Second Site. But I sold almost 300 copies of a clearly inferior product, Progenitor 2, in an era when computers were much more limited and before there was a mature internet. It is hard for me to believe that you haven't sold many more copies of Second Site. If I am wrong, then let me know what the gross sales actually amounted to and, if they are less, I will openly apologize to you - and perhaps offer you some advice on how to market Second Site.

While I have a lot of respect for John Cardinal, I think he is off base in blaming the demise of TMG on users who did not religiously upgrade to the most current versions. TMG, like other software, is a business proposition and upgrades have to justify their costs by providing new features, improved performance, etc. I only upgraded TMG on occasion, when I believed that the value of the accumulated changes justified the expense. For some time now, WG has not delivered the quality improvements commensurate with the price of upgrades. This has been especially true given the buggy nature of some of the upgrades. I had a fairly successful GEDCOM based software product for many years (Progenitor) but eventually realized that the expense of providing upgrades and other related maintenance activities could not be supported by new sales and the price I could charge for upgrades. I didn't blame anyone. I just folded the product after making almost $7,500 from it. John Cardinal made much more money from his Second Site connection to TMG. Perhaps he should have contributed part of that to the continued financial health of WG instead of blaming simple users.

You complain that genealogy with The Master Genealogist is no longer any fun. You have the wrong perspective on this whole issue. You should think of it as an opportunity to learn all the ins and outs of the operating system, details of folder naming, interpretation of obscure error messages, the quirks with various third party software that runs with everything else, etc. Then there's always the promise that the very next release will solve all your problems. What could be more fun than that?

On my MSIE v10 browser, neither the "views" nor the "responses" are being counted in the TMG v9 forum - at least for the last week or so.

Terry: I still don't think the forums are counting views. Nor do I think that the count of replies is correct.

I wrote to Bob Velke yesterday on this problem and he responded "We're working on it, Tom."

Is anyone working to fix the "counting" problem? Who is responsible to look into matters such as this? I doubt that this is a serious problem, but I am concerned that it hasn't been fixed yet. While I personally am not up to speed on forum maintenance responsibilities, it would be nice to know who, if anyone, is working on this.

I'm not sure that I understand your problem. If you are outputting a report to WordPerfect, you have control over the formatting of footnotes within WordPerfect. In WordPefect, click on format/styles. If you have generated footnotes, click on the footnote style, and then edit. You can then create whatever style suits you for your footnotes. But, perhaps I am misunderstanding you?

Michael: Now that you've mentioned WordPerfect, perhaps you could venture an explanation what the difficulty was that held up its implementation. If I understand TMG's handling of WordPerfect, all that was necessary was the preparation of a WordPerfect compatible file containing the generated output report. TMG is not issuing any 64 bit print commands itself. This seems pretty vanilla to me - and almost nothing to do with 64 bit programming. WordPerfect has not changed its formatting requirements for a WordPerfect compatible file since WordPerfect version 6 ! (perhaps ten years ago?) The only conceivable connection with 64 bit programming would be the extraction of the TMG data behind the generated output report. But that had to be done for all other report formats, whose availability significantly preceded the availability of WordPerfect for TMG. Since any TMG report of a given type consists of identical TMG data, one would think that, once one has programmed a report type for Word, PDF, screen, etc. it would be virtually effortless to make the minor modifications for WordPerfect. Am I missing something here? I know you are "just a user like yourself", but I would appreciate your thoughts on the subject.

I guess that I just didn't understand your use of the term "recognize". I took it to mean that ancestry.com didn't display any of the citations, but not that they didn't replicate the links to ancestry.com source records in some fashion or another. But, why then would you expect them to do so?

If I might be excused for stating the obvious: 88 hours into an import with it being only 52% finished implies that something is seriously wrong! Jim Byram's comment that " The GenBridge part of the import is not particularly well optimized" is at best a gross understatement. Assuming that DaveR has not messed up the import parameters, then Wholey Genes should definitely treat it as a problem that needs to be addressed. If, on the other hand, DaveR has messed up the import parameters, then we should be asking him questions about how he has gone about the import - and not be discussing Second Site or other alternatives. Although I maintain my primarily data on a TMG file, I keep copies of several of my trees at ancestry.com and get a fair number of contacts via that route. I have written a side program that scans GEDCOMs to be uploaded to ancestry.com, compares them to the TMG data files, and then adds "witness" and some other information extracted from the TMG files to the GEDCOM before uploading it. The "witness" part works fairly well, but the Event Notes have to be automatically broken up into parts due to the limitations in ancestry.com. In some cases, the narrative portion of some of the GEDCOM tags are truncated by ancestry.com. I am, however, not very happy with that whole process. But, in general, it serves the purpose of giving other ancestry.com folk a better picture of what I have in my TMG file. "http://trees.ancestry.com/tree/45222664/person/6327322746" and "http://trees.ancestry.com/tree/45222664/person/6327322048" will give those of you on ancestry.com some idea of what I'm talking about. An aside to Terry Riegel - My experience with uploading GEDCOMs to ancestry.com is that they do recognize source citations. They replicate whatever is in the citation itself. What they don't do is provide a direct link to the source document itself. But this is quite understandable, since the TMG source citation itself doesn't contain any such link.

Michael Hannah: I believe that you are confusing problems with the TMG process of exporting an equivalent GEDCOM with innate problems with the GEDCOM standard itself. The GEDCOM standard and TMG envision slightly different genealogy models. The flaws you cite would seem to be more associated with the TMG process of converting between the models than with the GEDCOM standard itself. One example of this, which you address, is when the TMG model has an event with two principals. The TMG process of exporting-to GEDCOM has several choices: export identical events associated with each of the relevant principals, create a FAM event but only if the two principals are married, or ignore the event entirely. The first choice would seem to be the most logical; the second choice could well be misleading; the third choice makes no sense whatsoever. The TMG export-to-GEDCOM process does not take the first choice. I have never understood this choice, except as a matter of programming convenience. Although I believe that the TMG model is more flexible (after all, I do use TMG as my primary software package), it is not without limitations of its own. As on example, one cannot without artificial mechanisms, however, directly handle events with three or more principals, which is the case in this thread. In addition, I believe you exaggerating in at least a few of the cases which you claim the GEDCOM standard cannot handle - e. g. unwed parents, non-primary relationships, exhibits, etc.

I'm been using ver 8.08 for some time and have never encountered this problem before. I am attempting to print a Journal report in WordPerfect. When I do so, I get an Error Message "Array Dimensions are invalid". When I attempt to cancel the message, another screen appears with the message "unknown member: ROPROTECTIONMAN". When I try to cancel this message, I get into a loop which I can only get out of by going to the task manager and cancelling TMG there. HELP!!

What a shame! I really don't understand why the error messages must be so opaque. When TMG discovers that some of the array dimensions are invalid, it must at least known which dimensions it found invalid. Why not add that information to the error message? And what "member" exactly is "ROPROTECTIONMAN"? I never have seen anything like that in any of the documentation. This appears to just be sloppy amateurish error handling procedures.

Your advice to reset the report to its defaults worked. Thanks. As you suggested, I did not use any sources. I will have to add the sources in the future, but did not need them in the present case. I am upset, however, by the need to reset the report to its defaults. What do the mysterious errors messages mean? Are they discussed in any manual or help file? Had I previously done something wrong? How can I avoid the problem in the future? What we appear to be reduced to is an undocumented mass of informal generic palliatives that seem to address problems. It reminds me of the general "bleed the patient" advice given in the older medical texts. In the great majority of cases, I honestly believe that I should be able to diagnose from the program documentation whatever caused my problem. I should at least be able to understand what I had done wrong.

I simply created a custom LAND tag. The characteristics are: type- custom; group - other event; gedcom - prop; sentence: [:CR:][P1G]< and [P2]> conducted a land transaction< [D]>< [L]><. [iTAL:][M][:ITAL]>; witness sentence: [:CR:][W] was mentioned in a land transaction conducted by [P1]< and [P2]>< [D]>< [L]>

Virginia/Jim: It worked fine this time - with the correct file changed. By the way, the new template left an open entry at DYS462e and did not require any copying of dna data. Thanks again. Tom Giammo

Jim: I replaced the "Family Tree DNA.dna" with the unzipped new one I downloaded from your link. I first changed the name of the old one. They were in the "C:Program Files (x86)The Master Genealogist v8" folder. When I opened the DNA file in the program, however, I noticed no change what-so-ever. The element DYS464 still only had four markers. What did I do wrong? By the way, I tried ancestry.com and they allow for five markers under the DYD464 allele. Tom Giammo

Jim: You're right! I do have a total of 68 markers on the 67 marker Y-DNA test. I hadn't noticed that before. On my first test, I originally had only four markers on allele 464 (12-13-13-14), which I did not question. I, however, had other questions about the test results and so had myself secretly tested a second time under a different name. That test came back with the identical markers, except for allele 464 - which on the second test came out as 12-13-13-13-14. I wrote to them, asking for an explanation. They agreed to run the first sample once again. This time it came out with the five markers 12-13-13-13-14, the same as on the second test. They apologized for the error and agreed to change my first result to show the five markers for allele 464.

Jim: I should have said up to five markers for DYS464 from Family Tree DNA for my 67 allele Y-DNA test. I, in fact, have five markers for this allele as reported by Family Tree DNA (12-13-13-13-14) and have no way to enter them all. DYS464 is a strange allele. It does have a variable number of repeating markers. I happen to have five, which I believe is the maximum.

A bit off-topic. Perhaps Jim Byrum might add it to the list of minor bugs - The TMG Y-DNA template only allows for four entries under Family Tree allele DYS464 (i.e. marker 464a, b, c, and d) , whereas Family Tree DNA reports on up to five entries (i.e. marker 464a, b, c, d, and what should be 464e).