I noticed that none of the sample websites for GedSite have a place index. I looked through the instructions and I don't see the option. Am I missing something? Virginia

Chris Sackett <[email protected]> wrote: >That fits with my test. I was the one who reported 48 minutes for a GEDCOM export. My project has 37,000 people, 81,000 events, 108,000 witnesses. How do you find out these numbers? I have no idea how many people, events, and witnesses I have in my two family projects. I have never attempted to export exhibits - had no idea GEDCOM could use them. I thought a GEDCOM was basically a text file. RootsWeb WorldConnect would not use the exhibits, but I guess Ancestry and MyHeritage would. Mary

Mary Grindol wrote: > I have a fairly large database and export to GEDCOM quite often - > to share with Ancestry.com, RootsWeb.com, and MyHeritage.com. I > have NEVER had an export take 45 minutes. I wonder if Chris, or > whoever said this in the first place, was trying to export exhibits > (which aren't recognized by GEDCOM anyway). No one else seemed be > shocked at 45 minutes, but I am. I don't think my GEDCOM reports > take much longer than saving to a backup (since I also don't backup > the exhibits because they are external). Mary, I am not an expert on exporting GEDCOMs from TMG, but my experience is that they take a long time. To make sure I wasn't misremembering, I just did a test and exported my 27,000 member project and it took 20 minutes. In my opinion, that's slow. Backing up my project is much faster, no more than a minute. I did include exhibits in the GEDCOM file. I don't think TMG will include internal image exhibits (I don't have any), but it did include external image exhibits (GEDCOM 5.5 supports that) and it also exported internal text exhibits. The external image exhibits should not slow TMG down. It doesn't copy the image files, it writes the path to the file in the GEDCOM file. I have a little experience with importing GEDCOM into TMG, and that is really slow, though there are wide variations based on the characteristics of the GEDCOM file. The other day I imported a 140,000 person GEDCOM file and it took more than 24 hours. That file was exported from Reunion for the Mac and there were various issues with it. I wrote a program to adjust the Reunion GEDCOM file and make it more standard. When I imported the modified GEDCOM into TMG, it took about 3 hours. John

Robin, Michael, John, Many thanks for your reassuring remarks about switching in due course from TMG and SS to HRE and GedSite, in particular for explaining that HRE should be able to produce a GEDCOM in a couple of minutes rather than the 48 minutes taken by TMG in my test run. That really is a game changer. Regarding the comment that not all data is capable of export to GEDCOM, are there at this stage known TMG features that, although they will transfer directly to HRE, will still not be able to be exported to a GEDCOM file and thus will not be able to be published on a website? In other words, are there clean-up or other tasks I could be doing now in TMG to avoid website problems after switching from a direct TMG-SS system to an indirect HRE-GEDCOM-GedSite system? Chris Sackett > On 18 Nov 2017, at 02:40, John Cardinal <[email protected]> wrote: > > Chris, > > Michael has already responded, and I agree with what he wrote. > > With regards to TMG and the agonizingly slow GEDCOM export, that's a TMG problem, not a GEDCOM problem. Most programs will write a GEDCOM file very quickly, and my guess is that RootsMagic or Family Historian (for example) would export your data to GEDCOM in a minute or two. Exporting to GEDCOM before making a site with GedSite is an extra step, but the time that takes should not be a significant issue. > > John > > > The TMG archive is found here: http://archiver.rootsweb.ancestry.com/th/index/TMG/ > Instructions on how to subscribe to TMG: http://lists.rootsweb.ancestry.com/index/other/Software/TMG.html > ------------------------------- > To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message

John wrote on November 14: >With regards to TMG and the agonizingly slow GEDCOM export, that's a TMG problem, not a GEDCOM problem. Most programs will write a GEDCOM file very quickly, and my guess is that RootsMagic or Family >Historian (for example) would export your data to GEDCOM in a minute or two. Exporting to GEDCOM before making a site with GedSite is an extra step, but the time that takes should not be a significant issue. I have a fairly large database and export to GEDCOM quite often - to share with Ancestry.com, RootsWeb.com, and MyHeritage.com. I have NEVER had an export take 45 minutes. I wonder if Chris, or whoever said this in the first place, was trying to export exhibits (which aren't recognized by GEDCOM anyway). No one else seemed be shocked at 45 minutes, but I am. I don't think my GEDCOM reports take much longer than saving to a backup (since I also don't backup the exhibits because they are external). Mary Grindol

On 11/18/17 12:51 PM, Chris Sackett wrote: > Robin, Michael, John, > > Many thanks for your reassuring remarks about switching in due course from TMG and SS to HRE and GedSite, in particular for explaining that HRE should be able to produce a GEDCOM in a couple of minutes rather than the 48 minutes taken by TMG in my test run. That really is a game changer. > > Regarding the comment that not all data is capable of export to GEDCOM, are there at this stage known TMG features that, although they will transfer directly to HRE, will still not be able to be exported to a GEDCOM file and thus will not be able to be published on a website? In other words, are there clean-up or other tasks I could be doing now in TMG to avoid website problems after switching from a direct TMG-SS system to an indirect HRE-GEDCOM-GedSite system? > > Chris Sackett > There are lots of features in TMG that can not be exported as a 'Standard' GEDCOM. A number of extensions, many/most of which John has put support for in GEDSITE are available in some programs to record in the extended GEDCOM much of this information. I suspect that there are still some features of TMG that haven't had an extension to support them, largely because no other program supports all the features of TMG, and thus no other program needed to implement an extension to GEDCOM to express it, and for the most part, TMG didn't worry about extending GEDCOM to maximize the information it exported, but instead until near the end focused on producing a total standard GEDCOM expressing the information that GEDCOM was designed for, and at the end added the option to include a number of the common extensions that other programs used to express their feature that standard GEDCOM couldn't handle. This doesn't mean that HRE couldn't work on creating further extensions to express more of these features, and John could support them in GEDSITE. (I would hope that they could work together to maximize the information transfer). That said, while creating a GEDCOM to express the basic, and even some of the advanced, genealogical data/features is probably on the road map for HRE, even more than TMG, they are not constraining the data model to be easily expressible as a GEDCOM, even with significant extensions. For example, I am not sure how badly you would need to abuse the GEDCOM standard to handle the fact that HRE treats places differently than the GEDCOM standard, allowing a lot of descriptive information to be attached and interrelatons recorded (a place may have multiple names, perhaps with time periods assigned; may be part of larger entities, again possibly with time periods; be divided into multiple sub-places, been derived from and later become other places over time, etc). -- Richard Damon

John, Is there any way to create a GEDCOM from a SS database that would be faster than doing it directly from TMG? On Fri, Nov 17, 2017 at 9:40 PM, John Cardinal <[email protected]> wrote: > Chris, > > Michael has already responded, and I agree with what he wrote. > > With regards to TMG and the agonizingly slow GEDCOM export, that's a TMG > problem, not a GEDCOM problem. Most programs will write a GEDCOM file very > quickly, and my guess is that RootsMagic or Family Historian (for example) > would export your data to GEDCOM in a minute or two. Exporting to GEDCOM > before making a site with GedSite is an extra step, but the time that takes > should not be a significant issue. > > John > > > The TMG archive is found here: http://archiver.rootsweb. > ancestry.com/th/index/TMG/ > Instructions on how to subscribe to TMG: http://lists.rootsweb. > ancestry.com/index/other/Software/TMG.html > ------------------------------- > To unsubscribe from the list, please send an email to > [email protected] with the word 'unsubscribe' without the quotes > in the subject and the body of the message >

I've recently acquired MS Office 365 and wonder if I would have formatting problems sending TMG reports to Word 2016? Reports I use often are Compressed Pedigree, Descendant Indented Chart and Journal. I still have Word Student 2007 edition, which I have used for many years, so I still can open the report there to check it, then open again in 2016. But if there are no known problems with 2016, I'd just as soon get rid of 2007. Thanks for any advice. Also many thanks to everyone who helped me with my "floating images" problem in the Word reports. I have successfully published the results. - Sally

Hi Chris, This discussion is on-going. At this time we are focusing on the implementation of the HRE core. It is unclear as to which solution would be practical and viable. It is the question of allocation of resources. John Cardinal has the expertise in making genealogical website tools. However, you make a good point that website builder to HRE tool would be more time efficient than the use of an external tool. It is not a simple question to answer at this time. One of the major problems in the use of an external tool is, like all uses of GEDCOM, it strangles the scope of data transfer, thus the website is likely to have no way to represent all the data featured in the database. [BTW: An internal HRE website builder tool might could use the HRE Commit Log to only update the previous web site by examining which records have been updated since the previous website was created. This would significantly reduce the website updating time.] RobinL On 18-Nov-17 09:16 AM, Chris Sackett wrote: > On 16 Nov 2017, at 16:02, John Cardinal <[email protected]> wrote: >> I will not be adapting Second Site to work with HRE. As mentioned in this >> thread, Second Site reads the TMG database directly and it's not practical >> to adapt it to the HRE database format for several reasons. >> ... >> While GedSite is intended primarily for use with GEDCOM, it's possible to >> adapt it to other data formats. However, I think it is unlikely I will adapt >> it to read an HRE database directly. There are several issues involved and I >> think it makes more sense for HRE to export a GEDCOM file. When an HRE >> GEDCOM export is available, I'll configure GedSite to load it. > I’m getting a bit confused, and a bit worried, about what I might need to do about TMG, SS, and HRE. > > The most important thing I do with my genealogy is publish a website, using SS output from TMG. I am constantly adding to my database and I update the website at least once a month with a complete upload of the whole site to FHH. I have not looked in detail at GedSite as it was clearly stated that SS is the better option for TMG. > > After reading the current thread, out of interest, I exported a GEDCOM from TMG. It took 48 minutes. I don’t know how long it might take with HRE but, however long it is, this is going to be a significant extra step every time I update my website. I always review changes in a local version before uploading, and I always find changes/corrections I need to do. This is not that big a deal when it takes about 7 minutes to re-make the site. But it will become a serious PITA if I have to export to GEDCOM every time as well. > > The possibility is mooted of HRE having its own website generator. Perhaps it’s too early to ask, or to know, but is this likely to have all the goodies we’ve been used to with SS? > > My fear is that I’ll be faced with the dilemma of sticking with TMG, which is running out of time, in order to continue taking advantage of SS features, or switching to a future-proof HRE, but in the process either losing a bunch of brilliant features or having to go through the additional hassle of making repeated GEDCOM files. > > Chris Sackett > The TMG archive is found here: http://archiver.rootsweb.ancestry.com/th/index/TMG/ > Instructions on how to subscribe to TMG: http://lists.rootsweb.ancestry.com/index/other/Software/TMG.html > ------------------------------- > To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message -- Robin Lamacraft, Adelaide, Australia

On 16 Nov 2017, at 16:02, John Cardinal <[email protected]> wrote: > > I will not be adapting Second Site to work with HRE. As mentioned in this > thread, Second Site reads the TMG database directly and it's not practical > to adapt it to the HRE database format for several reasons. > ... > While GedSite is intended primarily for use with GEDCOM, it's possible to > adapt it to other data formats. However, I think it is unlikely I will adapt > it to read an HRE database directly. There are several issues involved and I > think it makes more sense for HRE to export a GEDCOM file. When an HRE > GEDCOM export is available, I'll configure GedSite to load it. I’m getting a bit confused, and a bit worried, about what I might need to do about TMG, SS, and HRE. The most important thing I do with my genealogy is publish a website, using SS output from TMG. I am constantly adding to my database and I update the website at least once a month with a complete upload of the whole site to FHH. I have not looked in detail at GedSite as it was clearly stated that SS is the better option for TMG. After reading the current thread, out of interest, I exported a GEDCOM from TMG. It took 48 minutes. I don’t know how long it might take with HRE but, however long it is, this is going to be a significant extra step every time I update my website. I always review changes in a local version before uploading, and I always find changes/corrections I need to do. This is not that big a deal when it takes about 7 minutes to re-make the site. But it will become a serious PITA if I have to export to GEDCOM every time as well. The possibility is mooted of HRE having its own website generator. Perhaps it’s too early to ask, or to know, but is this likely to have all the goodies we’ve been used to with SS? My fear is that I’ll be faced with the dilemma of sticking with TMG, which is running out of time, in order to continue taking advantage of SS features, or switching to a future-proof HRE, but in the process either losing a bunch of brilliant features or having to go through the additional hassle of making repeated GEDCOM files. Chris Sackett

Chris, Michael has already responded, and I agree with what he wrote. With regards to TMG and the agonizingly slow GEDCOM export, that's a TMG problem, not a GEDCOM problem. Most programs will write a GEDCOM file very quickly, and my guess is that RootsMagic or Family Historian (for example) would export your data to GEDCOM in a minute or two. Exporting to GEDCOM before making a site with GedSite is an extra step, but the time that takes should not be a significant issue. John

Just for the record - HRE does not have a concept of Source Element Groups. It has an unlimited set of user nameable Source Elements. The user can order those elements in the GUI. The user can assign a behavior for any Source Element so that it acts in the way that you expect. Such as only allowing the correct format of data in its field, e.g. a non-date value can not be accepted in a date behavior field. [All TMG Source Type definitions will migrate to HRE with no problem.] RobinL On 17-Nov-17 05:28 PM, Brian Gross wrote: > It's important to keep in mind that you cannot have the same Source Element > in two Source Element Groups. This can lead to real difficulties if you > want to use the same Source Element in different custom source templates. > > The Source Element "Volume", for example, is part of the [VOLUMES] Source > Group. If you want to use "Volume" in a custom source template, all the > other Source Elements in that template need to be from other Source Groups. > It's really easy to get confused or to design yourself into a corner if > you're not careful (I know, I have). > > I've found that using a spreadsheet that lists all my custom sources and the > source elements is essential to keeping track of my custom elements. I > strongly suggest your uni student do the same. I've listed three entries > below so you can see how the spreadsheet idea works. > > Brian > > "Federal Census, 1900+, > Household" "Book, > authored, multivolume" "Book, compilers, et al., authored chapter" > > GROUP ELEMENT ELEMENT > ELEMENT > > [TITLE] Title Title > Title > [SHORT TITLE] Short Title > Short Title > [SUBTITLE] Subtitle > Subtitle > [SHORT SUBTITLE] > Chapter > [RECORD TYPE] County > [AUTHOR] Author > Chapter Author > [SUBJECT] Household > [COMPILER] > Compilers > [EDITOR] > [SECOND PERSON] > Short Compilers > [DATE] Publish Date > Publish Date > [SECOND DATE] > [LOCATION] Location > [SECOND LOCATION] State > [PUBLISHER] Publisher > Publisher > [PUBLISHER LOCATION] Publisher > Address Publisher Address > [SERIES] Enumeration District > [EDITION] Edition > Edition > [VERSION] Roll Num Volumes > [VOLUMES] Page (stamped) Volume > [PAGES] Page (penned) Page > Page > [REPOSITORY] > [REPOSITORY INFO] > [REPOSITORY REFERENCE] > [FILE REFERENCE] Dwelling OCoLC Number > OCoLC Number > [RECORD NUMBER] Family OCLC Number > OCLC Number > [FILM NUMBER] Film Number > [COMMENTS] M1 - M3 : Online source M1 - M3 : Online > source M1 - M3 : Online source > M4 - M7 : Not used M4 - M7 : > Not used M4 - M7 : Not used > M8 : Comments M8 : > Comments M8 : Comments > [CITATION DETAILS] CD > CD > [CITATION REFERENCE] > [CITATION MEMO] > [REPOSITORY MEMO] RM1: Repository Name RM1: > Repository Name RM1: Repository Name > RM2: Repository Location RM2: > Repository Location RM2: Repository Location > RM4: Repository State RM4: > Repository State RM4: Repository State > > > > The TMG archive is found here: http://archiver.rootsweb.ancestry.com/th/index/TMG/ > Instructions on how to subscribe to TMG: http://lists.rootsweb.ancestry.com/index/other/Software/TMG.html > ------------------------------- > To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message > -- Robin Lamacraft, Adelaide, Australia

Chris Sackett wrote: > I’m getting a bit confused, and a bit worried, about what I might > need to do about TMG, SS, and HRE. Chris, Let me try to ease your worries and confusion. I think you are anticipating this to be much more difficult than I think it will be. First, staying with TMG and SS for the time being I believe is a good thing, and will remain extremely viable for many *years* to come. Second, if (when?) you choose to transition I believe the best action will be to replace both TMG and SS at the same time with HRE and GedSite respectively. Robin has indicated that HRE will directly import your TMG databases. While there may be some "clean-up" to take advantage of new features in HRE, I suspect the conversion will be relatively painless since that direct import is a design goal of HRE. Next, you will export from HRE (not from TMG) to GEDCOM. The TMG GEDCOM export is limited in features. HRE is expected to be able to output many more features of its database into GEDCOM than TMG does using special non-standard GEDCOM constructs. Thus I expect that the HRE GEDCOM will be more complete than what TMG can produce. Finally, John has indicated he will enhance GedSite to recognize these HRE GEDCOM constructs to make web sites. Remember what little you needed to do to create your first Second Site web pages? The same simplicity is already available in GedSite, and I trust John that it will be just as simple when the input is a future HRE GEDCOM file. So I recommend sticking with TMG and SS for now, and not bothering with GEDCOM from TMG. But when they become available I believe you can expect to have an easy transition to HRE and GedSite later, and will gain added capabilities from those even more modern programs. Take a deep breath. Thanks to Robin and John I believe they will make sure there is not a problem here. Have faith! Michael

Brian Gross wrote: > you cannot have the same Source Element in two Source Element Groups... > It's really easy to get confused or to design yourself into a corner > if you're not careful (I know, I have). > I've found that using a spreadsheet that lists all my custom sources > and the source elements is essential to keeping track > of my custom elements. I second Brian's good advice. I also identify the source element groups which are used in each of my custom source types. For example see my Baptismal Register source type which lists by abbreviations (C, D, L, L2, PL, RA, Rp, RR, SbT, T, Vm) the eleven Groups used by that type: http://www.mjh-nm.net/SRCTMPLS.HTML#BaptismalRegister The Chapter of my book I referenced dealing with Source Elements http://www.mjh-nm.net/SRCELEMS.HTML organizes all the element groups and their variable name aliases according to "where" that element can be entered (Citation Screen, Repository Screen, plus Source Definition Attachments, Supplemental, and General Tabs). However, I have found a quick reference table of all the Source Element variable name aliases which exist helps to avoid Brian's valuable caution about duplicate names. See: http://www.mjh-nm.net/SRCELEMS_TABLE.HTML This table shows not only all the TMG default variable name aliases for each Source Element Group, but also includes my own custom names (beginning with an asterisk) which I use in my custom source types. This table is formatted to print out on one page which makes a handy reference when creating a new source type. The group name at the top of each column links to that group's entry in the main lists in the book. Hope this gives you ideas, Michael

Bravo! Danielle Forestier -----Original Message----- From: TMG [mailto:[email protected]] On Behalf Of robin lamacraft Sent: Thursday, November 16, 2017 11:42 PM To: [email protected] Subject: Re: [TMG] Can I relocate source elements on source templates? Just for the record - HRE does not have a concept of Source Element Groups. It has an unlimited set of user nameable Source Elements. The user can order those elements in the GUI. The user can assign a behavior for any Source Element so that it acts in the way that you expect. Such as only allowing the correct format of data in its field, e.g. a non-date value can not be accepted in a date behavior field. [All TMG Source Type definitions will migrate to HRE with no problem.] RobinL On 17-Nov-17 05:28 PM, Brian Gross wrote: > It's important to keep in mind that you cannot have the same Source > Element in two Source Element Groups. This can lead to real > difficulties if you want to use the same Source Element in different custom source templates. > > The Source Element "Volume", for example, is part of the [VOLUMES] > Source Group. If you want to use "Volume" in a custom source > template, all the other Source Elements in that template need to be from other Source Groups. > It's really easy to get confused or to design yourself into a corner > if you're not careful (I know, I have). > > I've found that using a spreadsheet that lists all my custom sources > and the source elements is essential to keeping track of my custom > elements. I strongly suggest your uni student do the same. I've > listed three entries below so you can see how the spreadsheet idea works. > > Brian > > "Federal Census, 1900+, > Household" "Book, > authored, multivolume" "Book, compilers, et al., authored chapter" > > GROUP ELEMENT ELEMENT > ELEMENT > > [TITLE] Title Title > Title > [SHORT TITLE] Short Title > Short Title > [SUBTITLE] Subtitle > Subtitle > [SHORT SUBTITLE] > Chapter > [RECORD TYPE] County > [AUTHOR] Author > Chapter Author > [SUBJECT] Household > [COMPILER] > Compilers > [EDITOR] > [SECOND PERSON] > Short Compilers > [DATE] Publish Date > Publish Date > [SECOND DATE] > [LOCATION] Location > [SECOND LOCATION] State > [PUBLISHER] Publisher > Publisher > [PUBLISHER LOCATION] Publisher > Address Publisher Address > [SERIES] Enumeration District > [EDITION] Edition > Edition > [VERSION] Roll Num Volumes > [VOLUMES] Page (stamped) Volume > [PAGES] Page (penned) Page > Page > [REPOSITORY] > [REPOSITORY INFO] > [REPOSITORY REFERENCE] > [FILE REFERENCE] Dwelling OCoLC Number > OCoLC Number > [RECORD NUMBER] Family OCLC Number > OCLC Number > [FILM NUMBER] Film Number > [COMMENTS] M1 - M3 : Online source M1 - M3 : Online > source M1 - M3 : Online source > M4 - M7 : Not used M4 - M7 : > Not used M4 - M7 : Not used > M8 : Comments M8 : > Comments M8 : Comments > [CITATION DETAILS] CD > CD > [CITATION REFERENCE] > [CITATION MEMO] > [REPOSITORY MEMO] RM1: Repository Name RM1: > Repository Name RM1: Repository Name > RM2: Repository Location RM2: > Repository Location RM2: Repository Location > RM4: Repository State RM4: > Repository State RM4: Repository State > > > > The TMG archive is found here: > http://archiver.rootsweb.ancestry.com/th/index/TMG/ > Instructions on how to subscribe to TMG: > http://lists.rootsweb.ancestry.com/index/other/Software/TMG.html > ------------------------------- > To unsubscribe from the list, please send an email to > [email protected] with the word 'unsubscribe' without the > quotes in the subject and the body of the message > -- Robin Lamacraft, Adelaide, Australia The TMG archive is found here: http://archiver.rootsweb.ancestry.com/th/index/TMG/ Instructions on how to subscribe to TMG: http://lists.rootsweb.ancestry.com/index/other/Software/TMG.html ------------------------------- To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message

It's important to keep in mind that you cannot have the same Source Element in two Source Element Groups. This can lead to real difficulties if you want to use the same Source Element in different custom source templates. The Source Element "Volume", for example, is part of the [VOLUMES] Source Group. If you want to use "Volume" in a custom source template, all the other Source Elements in that template need to be from other Source Groups. It's really easy to get confused or to design yourself into a corner if you're not careful (I know, I have). I've found that using a spreadsheet that lists all my custom sources and the source elements is essential to keeping track of my custom elements. I strongly suggest your uni student do the same. I've listed three entries below so you can see how the spreadsheet idea works. Brian "Federal Census, 1900+, Household" "Book, authored, multivolume" "Book, compilers, et al., authored chapter" GROUP ELEMENT ELEMENT ELEMENT [TITLE] Title Title Title [SHORT TITLE] Short Title Short Title [SUBTITLE] Subtitle Subtitle [SHORT SUBTITLE] Chapter [RECORD TYPE] County [AUTHOR] Author Chapter Author [SUBJECT] Household [COMPILER] Compilers [EDITOR] [SECOND PERSON] Short Compilers [DATE] Publish Date Publish Date [SECOND DATE] [LOCATION] Location [SECOND LOCATION] State [PUBLISHER] Publisher Publisher [PUBLISHER LOCATION] Publisher Address Publisher Address [SERIES] Enumeration District [EDITION] Edition Edition [VERSION] Roll Num Volumes [VOLUMES] Page (stamped) Volume [PAGES] Page (penned) Page Page [REPOSITORY] [REPOSITORY INFO] [REPOSITORY REFERENCE] [FILE REFERENCE] Dwelling OCoLC Number OCoLC Number [RECORD NUMBER] Family OCLC Number OCLC Number [FILM NUMBER] Film Number [COMMENTS] M1 - M3 : Online source M1 - M3 : Online source M1 - M3 : Online source M4 - M7 : Not used M4 - M7 : Not used M4 - M7 : Not used M8 : Comments M8 : Comments M8 : Comments [CITATION DETAILS] CD CD [CITATION REFERENCE] [CITATION MEMO] [REPOSITORY MEMO] RM1: Repository Name RM1: Repository Name RM1: Repository Name RM2: Repository Location RM2: Repository Location RM2: Repository Location RM4: Repository State RM4: Repository State RM4: Repository State

Hi Ann, If I remember correctly, the problem that you face and the reason for it is derived from matter the evolution of TMG and the evolution of source of template styles, from Lackey to Mills to Custom. The TMG Source Entry User Interface (GUI) only listed the fixed set of fields in a fixed order. As different source templates were created, all that these definitions provided was alternative labels for this fixed list of fields. The entry order of those fields in the GUI did not change and could not be changed by the user, only the labels were changed by the creation of a custom source type. The user has no control over the order of the display of the fields. The second problem that you may strike if you tried to create a custom set of source type definitions within the TMG fixed set of source fields is that some fixed source elements had special properties and so the output that you need cannot then be created. The fixed order and the limited number of possible fields are both limitations of the design of the source system in TMG. RobinL On 16-Nov-17 04:53 PM, Ann M Shepherd wrote: > I'm pretty sure I can't do this but again, just in case I'm mistaken . > > > > I'd like to rearrange the source elements on some of my source templates. (I > have a uni student helping me with sources, citations, etc, and it would be > much easier for her if the fields in my source templates were in a logical > sequence.) > > > > I guess that the source elements for any template are currently arranged > automatically somehow by TMG? > > > > Can I change the order of these fields in my source templates? > > > > Thanks in advance > > > > Ann > > The TMG archive is found here: http://archiver.rootsweb.ancestry.com/th/index/TMG/ > Instructions on how to subscribe to TMG: http://lists.rootsweb.ancestry.com/index/other/Software/TMG.html > ------------------------------- > To unsubscribe from the list, please send an email to [email protected] with the word 'unsubscribe' without the quotes in the subject and the body of the message > -- Robin Lamacraft, Adelaide, Australia

I'm pretty sure I can't do this but again, just in case I'm mistaken . I'd like to rearrange the source elements on some of my source templates. (I have a uni student helping me with sources, citations, etc, and it would be much easier for her if the fields in my source templates were in a logical sequence.) I guess that the source elements for any template are currently arranged automatically somehow by TMG? Can I change the order of these fields in my source templates? Thanks in advance Ann

At 11/16/2017 01:23, Ann M Shepherd wrote >I guess that the source elements for any template are currently arranged >automatically somehow by TMG? As has been noted by Robin and Michael, the Source Definition screen Source Element arrangement is fixed and can't be changed. As you already know, you cannot have two different Source Elements from the same Source Element Group in the Source Templates of a Source Type. These Source Elements Groups are each given a number internally by TMG and we cannot change them. There are 160 Source Elements spread across 32 Source Element Groups. It is a Source Element Group into which you enter data for a Source. But a Source Element Group name may not be the reminder that is needed to prompt you for the right data. It is for this reason that we have Source Elements and can add Custom Source Elements as aliases for the Source Element Group to which the Source Element is included. Actually, the Source Element Groups are more or less arranged in a logical order -- at least for the first few. Since not all Source Types are the same, some of the first few Source Element Groups aren't used and others have been added. Think of books, newspapers, and similar sources as being arranged in this order: 1 [TITLE] 2 [SHORT TITLE] or [ARTICLE TITLE] 3 [CHAPTER TITLE] or [SUBTITLE] 4 [SHORT CHAPTER TITLE] or [SHORT SUBTITLE] 5 [RECORD TYPE] 6 [AUTHOR] 7 [SUBJECT] 8 [COMPILER] 9 [EDITOR] These Source Element Groups will generally define most books, newspapers, and similar sources. Other Source Elements of the above Groups will go a long way toward defining many other sources. But, those other sources may not be logically similar to book and newspapers. Lee

Ann, Lee Hoffman observed that the first nine source element groups in the list of 23 possible groups I referenced are probably very common. I am assuming he is suggesting that if one creates Source Types whose definition includes these nine groups then any Source Definition created using such Source Types will have these elements fixed in the first nine slots. Since the General tab will only show Title plus 14 of the possible 23 such Source Element Groups, I chose to construct a custom Source Type called "Miscellaneous". It includes the element groups I find most useful, which are (in order on the screen) Title plus: Subtitle, Record Type, Author, Subject, Second Person, Date, Second Date, Location, Second Location, Publisher, Publisher Address, Series, Edition, Volumes. If consistency of order is important on the source data entry screen, then one could always use a single Source Type like this one for Source Definitions but only enter data in the fields appropriate to this specific source. For a description of the three templates for this custom general purpose Source Type of mine see: http://www.mjh-nm.net/SRCTMPLS.HTML#Misc Hope this gives you ideas, Michael