Jump to content


Senior Members
  • Content count

  • Joined

  • Last visited

Everything posted by Pierce.Reid

  1. Colin, The free image display-editing program Irfanview, plus the utility GhostScript can convert PDF files into a multi-page (if the PDF has several pages) image file. I generally save each page as a separate jpg file. Pierce
  2. Roles

    Michael, When you use the variable [R:rolename] as the subject in a sentence for individuals that are not the Principal, and you want the tag for that person to be printed in a Journal or Naritive report, TMG will list all people havng that role in that tag as the subject for the sentence. Obviously the verb in the sentence should be singular if there is only one person in that role, and plural if there are more than one. That suggests that it is impossible to create a sentence template that will produce good English both when there is one person in the role and when there are more than one. Personally, I would like to be able to ignore the generic Witness role, and use the Principal role just for those who are most closely related to me (not the role TMG has decided should be the Principal for a particular tag type). As an Ultimate Family Tree fan, I use roles everywhere, including many I have created complete with sentence templates. However, I have not found a way to easily deal with this problem. Pierce
  3. The Future for TMG

    But if I remember correctly, version 6 had about 15 updates whereas version 7 has only had 4. During the version 6 era, we were getting monthly newsletters, now it seems to be maybe 2 or 3 a year. A little more communication goes a long way. As I remember, Bob made a promise to release version 6 "by the end of the year". It seems that he may have released it a bit early to meet that commitment, so a number of bug fixes were required in successive sub-releases. He does not want to do that again. And neither do we. I think WG has had some significant challenges in making TMG work in the 64 bit Windows. Maybe part of the problem is the many features and flexibility in the product, making it rather complex. We love these features and flexibility, but we want the product to work properly. We hope WG are working diligently to get TMG8 to do that. Pierce
  4. The Future for TMG

    TMG is probably one of the most powerful genealogy programs around. The downside is that is is also a complex program, with many options that users can work with. That makes it a challenge for a small company like WG to support and upgrade. The use of FoxPro and other third party programs probably helped get the early versions out the door more quickly by reducing the amount of programming that had to be done. But FoxPro limitations are imposed on TMG (e.g. Unicode), and it is not being upgraded. WG recently had problems with the routines that produce report output aimed at Word. There are probably other programs embedded in TMG that could now be causing programming challenges. In some areas there seems to be unnecessary complexity. One simple example is the requirement that only one event tag of a particular type can be primary. It seems to me that only key events need that - those that require dates/places on standard genealogical reports (e.g. ancestor/descendant charts). That could be limited to birth and death tags (you can only be born or die once - not counting religious rebirth) and maybe marriage of a couple and burial. Superimposing roles (sort of from UFT) on top of TMG's old Principals/Witnesses structure is an additional complexity that may not be solvable. The complex source, citation, repository structure maybe too difficult for me to learn to use "correctly", and I question their real value. Place and people names can have complex structures, even when they are limited to the British naming pattern. I suspect that these complexities are built into too many customers databases that they cannot be simplified. Ultimate Family Tree seems to have a simpler and, in my mind, a more elegant data structure which I think made it easier to program and to use effectively. Of course, when it was taken over by one of its competitors, the new owners decided it wasn't worth maintaining. There are a number of extra features in TMG that I really like, but of course they add to the complexity of the product and and may be difficult to maintain. I think the best we can hope for is that WG keeps slogging away and keeps the program working on the latest operating systems, at least until we can no longer do genealogy. Pierce
  5. The Future for TMG

    One more comment on the potential longevity of TMG. When Windows 7 64 bit came out as the standard retail operating system, many older programs no longer worked. This includes older versions of TMG, as well as Ultimate Family Tree (which also uses Fox Pro), for which support disappeared in the 1990s. Microsoft did come out with a workaround, which is called XP mode under their Virtual PC system. This does require an upgrade to Win 7 Professional, and the free download of the additional XP software. It is not quite as convenient as native XP, but it does work satisfactorily. When TMG 8 comes out with a solution to the report writer Win 7 problem, there will be ways to get it to work on the latest PCs and Windows operating systems for probably 20 more years, just like I can still run UFT that was designed to run on Windows 3.1. By that time I will probably be past being able to do genealogy. Pierce
  6. TMG 7.04 Tag Event

    If you are working from ships' passenger lists, you usually only know the ports the ship left from and arrived at. When my great grandparents came from Buckinghamshire, England to northern Minnesota, they left from Southampton and arrived in Halifax, Nova Scotia. That trip was probably the only time most of them came close to the sea, let alone did anything else significant in those ports. Another of my great-great grandparents sailed to New York and stayed a winter on Long Island with his sister, before moving on to their destination in Wisconsin. Many Irish immigrants sailed from Liverpool, although that was probably the only time they were in England The only solution in TMG is to use the location field for one of the ends of the trip and put the other in the memo (and maybe restructure the sentence template to deal with a split memo), or else have both a departure and an arrival tag. You could have one of those two tags not be printed in reports, but I think it would show up in a place list, if that is what you want to see.
  7. Just about every census has a unique set of fields, and some fields are usually not filled in. Ancestry.com has clear PDF images of blank forms for many of the censuses (but I forget how to access them - I downloaded them to my computer years ago). Some of the column titles are quite lengthy, even if the field values are just one or two characters. Some forms have so many fields that Ancestry displays them in two sections. And of course, states have their own creative ways of laying out their census forms. Some forms have separate pages for different sorts of information. Trying to create the computer program to handle even the variations in the federal censuses, both for input and output, would be quite a task. In the memo field of the census tag of the "principal", I summarize what I consider the important information and leave off some redundant information. For example, I don't repeat the family name - which is sometimes indicated by a dash or "do". I don't indicate if a "wife" or "daughter" is female (but I will indicate if the census taker got it wrong). I don't repeat the birth place if they are all the same (in English censuses, they give the town and county - I drop the county if the a previous line gave the same town). I will note what I think are errors. I link each person in the household with the appropriate role, as identified by the census taker (and I note in the memo where that is wrong). I make the person who is my closest relative the "Principal", with his or her designated role. I can therefore see, in each person's "person view", where that person was on census night, and maybe what that person was doing (e.g. lodger, servant, student, etc.). As someone has noted, TMG users have a wide variety of ways to handle censuses, both for recording and for reporting. I doubt that any particular tabular facility will satisfy only a small minority of TMG users. Pierce
  8. Ultimate Family Tree Import

    Wholly Genes support can be great. They addressed a couple of UFT to TMG problems I encountered once they took a look at my UFT data base. You will probably want to do a number of imports of your UFT data as you see where some of the things you did in UFT don't transfer as you wish into TMG. The UFT 3.1 Find and Replace function can be very useful if you find you have done something in UFT that does not go over to TMG very well. I've had to clean up a couple of event types so the TMG results are satisfactory. You may also find that there are some things TMG just can't do as well as UFT. If you feel some feature that UFT has that is missing in TMG, you could try suggesting a wish-list item, which might some day be implemented if it is likely to be of use to many other TMG users. (But so far the ones I have suggested don't seem to have gone anywhere.) Pierce
  9. Ultimate Family Tree Import

    I've been importing my UFT database regularly, and have not noticed duplicated sources. I have noticed an empty citation field at the end of one of my memo text fields. It shows up as " [CIT:] [:CIT]" This produced an empty footnote in the Journal report. For that source, I have one field that is defined just for this occurrence of of the source reference (a common UFT feature, similar, I guess, to a Citation Detail in TMG. I need to do more examination of my sources to try to track down the conditions that might produce this result. Pierce
  10. Version 8?

    Jim, I don't think that statement will be quite accurate. While Wholly Genes tries very hard to get each release perfect, TMG is a very large and flexible program. The beta testers test a wide range of feature combinations but TMG users are very creative in how they try to use the program, and there always seems to be a few obscure (and sometimes not so obscure) things that don't quite work properly. If they didn't insist on giving us so many useful ways to record and report our data, maybe they wouldn't have a few bugs in every release. But then many of us would not be interested in using the product. Pierce
  11. For those wishing to explore the EXIF and IPTC data on the jpg files from their digital cameras, you can download irfanview (from irfanview.com), image editing software that is free for personal use. It provides access to this information. Cameras store quite a bit of technical data about the exposure within the EXIF section of the file. IPTC data is usually data users can add, such as copyright notice, captions, keywords, etc. Other programs can add more data. For example, I have a Sony GPS logger with software to merge GPS location information to the EXIF data. Then irfanview can launch Google Earth to pinpoint where the picture was taken. For example, it would be neat if TMG could fill in the LatLong field from an attached exhibit containing that information. I plan to use it when exploring cemeteries, so I can locate grave sites of interest. Pierce
  12. I have someone with a mother specified but no father. In the Ancestor Box Chart, there is no line between the mother and the child, although the mother's box is shown. I can only get a connecting line if I create a dummy father record. If I have parents for the mother, the mother's ancestor tree is floating above her son's. Do I have to draw in the connection between mother and child if there is no father? Pierce
  13. I also have not committed my data base to TMG, but do regular imports, both for the useful TMG features and to learn how to make my data fit. One "wish-list" feature I would like is for TMG to remember the Import options from one import process to the next. Generally I always want to use the same options, although in some cases I want to play with the possible choices for just one option. It would also be useful if you could set all the options at the beginning and let the Import complete to the end without requiring user input part way through the job. Imports take enough time as it is and we should not have to come back to the computer to select a few more options before it churns away some more. Pierce
  14. Who was born here Filter

    I'm surprised that TMG does not have an easy way to search for people who are linked to a particular place. UFT has a menu bar option to Search > Individual > Presence that allows the user to search for everyone associated with an event (in any role) that occurred in a particular place in a specified time period. I have found it very useful to locate relatives that might be referenced in some new on-line data base for a particular local. I've found a number of people in data bases I would not have searched, since I have not remembered (or my wife had done the data entry) recording anyone in that area. TMG filters can be powerful search tools, as many experts have explained. However, it takes practice, and maybe a certain way of thinking, to design one for a particular need. And even if you can put together a filter for a particular task, it may not be perfect, so that you do not get all the records you want. And you may not realize that you are missing some data. It would be nice if there were a way for filters to be packaged up in a nice fill-in-the-blank form, which experienced users could create and distribute to less skilled users. Pierce
  15. Exhibits linked to events

    Jim, Is this a reasonable understanding of this issue? An Exhibit is just a link to a media file, such as a picture or video file. As such, an Exhibit is quite small, just a pointer to the file. The media file, on the other hand can be quite large. More than one Exhibit can point to a single media file. In some situations, an individual's record (e.g. the individual display in TMG or a box within a chart) can handle only one media file (generally a picture). For these purposes, the Exhibit used is the one that is marked Primary. In these cases, an Exhibit usually points to a picture. Are there other situations where only one exhibit can be used? There does not seem to be a situation where information on an event needs to have no more than one Exhibit shown. Therefore, there is no need to mark an event Exhibit as "primary". The confusion in this conversation seems to be the use of the word Exhibit when the writer really means the media file, or when a reader sees the word Exhibit and thinks this means the media file. I hope this is a simple enough view of the issue. Pierce
  16. I second that motion. Ultimate Family Tree has a Journal report option "All spouse data", which is similar to an option on descendant journal reports in TMG. UFT goes a bit overboard with ancestor reports, since the part of the report on an ancestor will contain all the data for the wife who is also an ancestor. Then on the section on the wife, it gives all the information on the husband. That can produce a lot of redundant information. I therefore manually edit out, in the word processor, all the spousal data except the BMD information, which is what I find useful for easily identifying which of several ancestors with the same name I am currently looking at. (The All Spouse data option also presents all the information on the spouses of the ancestor's siblings, which I find very useful.) Pierce
  17. Pierce, I think the simple answer is that in TMG the [RF:rolename] variable was never intended to be used in the sentence for that role. TMG's standard sentences all use the [P] or [W] variables, which automatically substitute the pronoun "He" or "She" in useful ways. The [R:rolename] variable does the same. But the [Rx:rolename] variations do not. So TMG's design apparently intends that references to the current witness will use either the full name or the pronoun. I don't find adequate - I think there needs to be a way to get just the first name, which, as I said, is on the wishlist. Terry, Aside from not being adequate, I think the way the [RF:rolename] and similar role codes are implemented are fundamentally wrong from an English grammar point of view (and is even more wrong for the grammars of other languages). You cannot have [RF:rolename] do something if you might have one or you might have more than one person linked to "rolename". If your sentence template was "[RF:rolename] was ...", then if more than one person is in the role of "rolename", the result would be "John and Jim was ...". For the "Principal" roles (not really proper terminology), you can have either just one person, represented by "P" or two people, represented by "P" and "PO" codes. You can therefore test for the existence of "PO" to decide if the sentence will use a singular or a plural version of verbs. I don't think there is a way for the sentence to detect if there is just one or more than one person linked to regular roles. At least one proposal has been offered to add some syntax to do that but that may not even be on the wish list yet. Pierce
  18. What "standard role sentences," Pierce? All the standard role sentence do use the "equivalent to the [P] variable in standard Principal sentences" because they are exactly the same as the standard Principal sentences, including the use of the [P] variable. If Pierce has role sentences that work otherwise they were created by the user, or they were imported from UFT. Terry, You are right: I have lots of role sentences that were imported from UFT. These sentences would work quite well in TMG if TMG were to support "[RF:/rolename]", etc. the same way as "[PF]", etc. A work-around for some of my sentences might be if there were "[WF]", etc. available, but that would not solve all my issues. I still think that the way TMG implements substitution for "[RF:rolename]" is not logical. I do not see how you can create a sentence using this variable that will be correct English when there may be one or more than one person linked to that role. It will only work if you ensure that only one or only more than one person is linked to that role. There are many events where there could be one or many people with the role of "son", "beneficiary", or even "witness" (in the real-world marriage or legal trial sense), etc. and we should not have to have redundant roles defined just to get around an illogical TMG convention. On a related note, I've seen several people comment on how they use "redundant" roles, such as "son1", "son2", etc. so they can create role sentences or memo text that reference several people with the same real-world role, but with different attributes (e.g. age). This technique has the advantage that if you create an index of people for a report, the index will be sure to use consistent names and dates for various references to an individual. (Normal index entries in memo text require the user to be sure that the name and birth/death dates in the index match the "current" values that TMG maintains.) It would be nice if the specification of index entries in memo text could be separated from role references. In UFT, you specify an index entry using the individual number. You can then update the person's name and dates without worrying whether you have index entries in various memo text that have to be updated to be compatible. This would also allow you to enter "incorrect" names in the memo text but have the correct name in the index. For example, a census entry was transcribed as "Francis [sic], Daughter, ..." should have an index entry referencing "Frances". The girl was never called "Francis" by anyone (except the census enumerator who did not read some handwriting correctly), so it is not a valid alternate name. But I don't know if Bob has given this idea further thought since I suggested it to him a couple of years ago. I am certainly getting a better feel for how TMG handles roles, and various techniques for using them. I just hope some of our wish list items on this topic get implemented. Pierce
  19. I think this will allow the creation of a sentence template that will work with one or multiple people linked to a role. At the present time, it does not seem possible to create a sentence template that will create a proper English sentence in either case - it seems you have to create additional, redundant roles and you have to know if you have one or more people in a real-world role before assigning the TMG roles (e.g. "pupil" vrs "pupils"). I don't think it solves my original problem. If there are several people in a particular role and I want all tags a person is associated with to be printed in a Journal report, the standard role sentences will not come out correctly. I want "John was listed as the son of Sam Smith..." and there does not seem to be a way to do that if there are more than one "son", unless I custom edit the tag sentence or create multiple roles. Ideally I should be able to link each individual to the correct role, and we should be able to use a default role sentence that references (by name or by pronoun) just that individual. It should also be able to create a sentence that uses a list of names or collective pronoun. For my use, I would only use a single name or pronoun for my default sentences for all roles. Other users may want to produce sentences with a list of names or collective pronoun, possibly using a sentence template like you propose. Pierce
  20. Terry, We've been through some of this before, but I did not realize that [R:rolename] would produce just one name, while other role variables such as [RF:rolename] would produce the list of all who had the specified role. Is there any logic to that difference? It seems fundamentally inconsistent. As others have pointed out, you have to create extra roles, or custom edit the role sentence to handle one or more people in a specific role, if you want the role sentence to read correctly. That looks like a fudge to get around a poor design decision on how to handle role references. It could also require you to retrofit a tag when you decide to add someone in a particular role. For example, you have a census with several "pupils" listed, only one of which you recognize as a relative. So you link that person to the role of "pupil", and make that person "principal" (because that is the only person on the census you are interested in). The role sentence might read "[RF:pupil] was listed as a pupil in the school of [R:headmaster]...". Later you find another relative who was a pupil at that school, so you link that person to the role of "pupil". Now the sentence will come out "Jane and Mary was listed as a pupil ...". Now you need to go back and create a role of "pupils" if you want to get "Jane and Mary were listed as pupils..." or create roles "pupil1", "pupil2", etc., as suggested by several people. (I've had a situation where I found a relative who was a pupil at a boarding school, and later found another relative recorded as a pupil in the same census.) It seems a better solution might be to have a role code that would indicate you wanted to list all individuals in the role sentence; otherwise only the current one being reported would be used. For example, the letter "M" (if "M" isn't already assigned a meaning) could be used to indicate multiple people are to be listed. For example, [RF:rolename] would list only one person (the same as [R:rolename]), while [RFM:rolename] would list all those with that role. (It might also be useful to have a logical variable indicating whether one or more than one person had the role, Which could be used to select whether "was" or "were" would be used in the sentence. Things could get even more complicated if TMG wanted to support languages that had different spellings of the word for "they" and "pupils" depending on whether "they" included boys or just girls.) There might be a better way to solve this problem, but I think the current logic for handling these sentences is not reasonable. If the individual had the role of, for example, "pupil" (that is what the census said), then that is what we should link the person to. The role sentence for that person should not have to change depending on whether someone else is linked to the same role. Pierce
  21. Rufname

    These are basically fudges to deal with a common practice in a number of cultures, including the "British" culture in many countries. It is quite common in my very British families to use a given name that is not a first name as a "common" name. For example, both my in-laws did NOT like to see their first names in print - they both used their middle names. I like the idea of using a special character such as the # sign to indicate the "common" given name, which would then be underlined when used as part of the person's complete name. The system could possibly use another symbol to indicate a nick name that you wanted to use instead of one of the given names. This name could be displayed in quotes, as many people currently do, when the full name is displayed. It would also be used instead of the person's first name in any role sentences. I realize that you can specify alternate name tags, and you can go through various role sentences for the tags that refer to this person and select the name you want used. But this solution would automatically cover a large percentage of those who did not normally use their first name. (I really don't like the look of using font codes to indicate a commn name, and that does not handle use of the common name in memo sentences.) Pierce
  22. The next obvious question is: Why can you not include spouse data for siblings of your ancestors in an Ancestor report? Bob, could this option be added to the wish list? Superficially it looks like you must already have much of the code written for the Descendant report. Pierce
  23. I have wanted to include spouse data in journal reports, not just BMD data but other data as well. This can help create a more complete view of the family and can help keep people with similar names separate when reading your report. In Descendant reports, it is also useful to include spouse data for every one. For example, if a descendant dies with a young family, that person's spouse may have census tags, etc which describe the family after the descendant's death. Ultimate Family Tree has an option "include all spouse data". This does create a lot of redundant text for ancestors and their spouses in an ancestor report, but gives a more complete picture of families. It would be nice if TMG provided options to do something similar. Does any one else care for this feature? Pierce Did you check "Include spouse events" on the Miscellaneous tab under Format? Thanks, Paul, I had not noticed that option on the custom reports. I still have a lot of options to try out. Pierce.
  24. Book Manager

    If you are planning a fairly extensive book for one family or a group of related families, you are likely to have a number of names that were each used by a group of individuals. Some groups may have individuals with the same name that are not related at all (e.g. Smiths). To create separate index entries for each individual, you should include birth and death dates (just years usually do) by selecting the appropriate TMG report index options. As Jim suggested, you should use the same options for all TMG reports you will combine. If you want to include index entries for references to individuals mentioned within memo text, you have to include an Index entry near each name. e.g. [index:]Person: Last, Given (dates)[:Index]. (See "Report Options: Indexes" in TMG Help). To have a unique index entry for each individual, you have to make sure that the "dates" you enter as part of the memo "Index" entries match exactly the format and values in your data base. And if you change an individual's birth or death years, or the individual's name, you have to find and correct the index entries you have inserted into any memo text that references the individual. Once you have started to enter index entries in memos, it can be a lot of work if you want to change the TMG options for index entries. A good index is a sign of a good book. Lack of an index makes a genealogy book much less useful as a reference tool. Pierce
  25. I have wanted to include spouse data in journal reports, not just BMD data but other data as well. This can help create a more complete view of the family and can help keep people with similar names separate when reading your report. In Descendant reports, it is also useful to include spouse data for every one. For example, if a descendant dies with a young family, that person's spouse may have census tags, etc which describe the family after the descendant's death. Ultimate Family Tree has an option "include all spouse data". This does create a lot of redundant text for ancestors and their spouses in an ancestor report, but gives a more complete picture of families. It would be nice if TMG provided options to do something similar. Does any one else care for this feature? Pierce