John Cardinal

Michael, OK, I found the issue. The quotes in the HREF value are interfering with the processing of the WEB codes. The problem is a combination of some logic that SS applies to source elements combined with the rules of the WEB code. I don't have a workaround for you now... Sorry!

Michael, I meant to reply to this part of your message in my last response, but I forgot. When SS is creating a site, TMG is not involved and doesn't do any parsing. Second Site reads the TMG database directly. So, your guess that "TMG parses it into the HTML format. Then SS tries to parse the HTML format" is not correct. Actually, SS sees the exact text that you provide, including the WEB codes, and SS interprets the web codes. In this case, you didn't follow the rules; the WEB code calls for an HREF, not an HREF and a TARGET. It's OK to break the rules, but sometimes you get caught! In this case, the way TMG implements the WEB feature, your approach works. SS is honoring the rules, but is implemented a little differently than TMG, and that's partly why there's an issue...

Michael, First, it shouldn't matter which source element is used for the URL. SS processes all of them the same, at least with respect to URL handling. I think the issue has something to do with the Second Site's automatic detection of URLs in sources. Now that I understand how and where you are using the WEB codes with the target= parameter, I'll do some testing here to figure it out.

Michael, I am not sure what to tell you about using the [WEB:][:WEB] construct in source elements. Second Site auto-detects URLs in sources and that may be interfering with the use of the [WEB:][:WEB] codes. If I read your reply correctly, you were able to use the WEB code in the COMMENTS field but not in the other source element fields? Let me know if I got that right so I can do some tests here. Your ringmaster is not up to date with respect to web standards, and that's a shame. The issue is not that target="_blank" is overkill; the issue is that using target="_blank" takes control away from the person browsing the site. When target="_blank" is used, the person browsing the site has no choice; they click the link and it opens in a new window (or possibly a new tab if the browser is configred that way). They may not want another window or tab, but they can't do anything about it. On the other hand, if target="_blank" is not used, the user can choose to open the link in the same window, a new tab, or a new window... whatever he or she prefers. That's the important point. It sounds like you don't agree with her, so I won't berate you further! Perhaps I gave you some ammunition to convince her to reconsider. Anyway, please clarify how you used the WEB codes in source elements and I'll try to figure out a workaround.

Michael, I urge you to reconsider using the target="_blank" parameter. Most web designers now agree that people browsing a site should choose for themselves whether or not to break out of a framed site or open a new window or tab to view a link. (All modern, full-featured browsers include right-click options to open a link in a new window, etc.) Note that the target= parameter is deprecated in HTML 4.01 (the latest official version) which means it will be removed in a future version. Given the above, I don't think it's wise for TMG to add support for the target= parameter. It's very likely that most web browsers will support the target= parameter for quite some time, but that doesn't mean that well designed sites should use it.

Darryl and others who may see this post, FYI: As of v7.01, TMG has an Initialize Repeat Files command in the Files > Maintenance menu. The command is simpler, easier, and safer than doing the same thing by hand.

Kathleen, I do check messages here, usually once a day. I think you are trying to use the Flag Filter for something other than what is intended. The Flag Filter does not filter which flags are shown; it is used to specify a flag that is used to include or exclude people. Regarding which flags are shown, you have limited options to control that. SS can either show all custom flags, or none. You can't choose a subset of flags to show. Does that answer the question?

I don't think it's a good idea to add formatting codes to the name data. Name parts can be formatted when reports are produced. Doing it that way keeps the data clean, and clean data is happy data. More importantly, however, I don't think it's necessary to bold or underline the rufname if you don't embed it as part of the birth/legal name, and I don't think it should be embedded. Embedding it in the birth/legal name is a shorthand for "usually known as" or "also known as" or something and is a lazy way to do it. Basically, you are combining two names in one name record. It's cleaner (and more correct, IMO) to keep them separate. Given the above, my suggestion is to add a Name tag where the rufname is in the given name field and the legal/birth name is not present, and make that the primary Name tag. Add another Name tag, non-primary, which captures the legal name. You can add a memo or citation to the rufname Name tag to explain things if desired.

I keep the files on the PC side, not in the Mac file system.

Just an FYI: I have no trouble running TMG v7.03 using Win XP under Parallels.

The Export Data feature in TMG Utility has the ability to export source information to an HTML page. It's pretty comprehensive, and includes more than the Make Source List feature.

You've found the issue, and you'll also found that using [WEB:][:WEB] can be useful. Here's one more thing: SS will detect URLs in source data and convert them to links without any HTML and also without the [WEB:][:WEB] code. That URL detection may have been the issue you first noticed; if the HTML was not 100% correct, the detection logic might have made things worse, not better.

<at [Church]> in <[City],> <[County],> <[State],><[Country]> One reason I don't use a custom Place Style similar to the above is some ambiguity about how the literal "in" will be handled. As far as I know, WG has not specified when "in" will appear if other variables are empty. So, for example, if [Church] is empty, I presume that "in" will still appear. But what happens if all the subfields except [Church] are empty? Does "in" appear or not? If it does, then you'll get incorrect output; "in" will be at the end of the place output. In general, using literal text in style templates can be tricky. If you test the method you use, and you are consistent when you use the method, you should be fine. Given there are some ambiguities in the rules, however, the current behavior is not assured and so things could change in the future.

It sounds like the unexpected power outage broke one or more of your TMG project files. Reloading TMG won't help with that problem because most of the files that are part of the install don't change in daily use, and so the power outage can't really hurt them. (Usually, only files that are being written are damaged during an unexpected shutdown.) Do you have a recent backup of your project from before the power outage? If so, you can restore from there. If you do not have a backup, I suggest you contact the support group at Wholly Genes. They may see this post; a direct email message to support@whollygenes.com is a more reliable way to get help.

Here's how I handle it, which is a little different than you requested. I use a default sentence that is something like this: [P] married [PO] The key part is the location variables. If [L2] is used in the sentence, then the value of [L] will not include the detail (L2) field, and so the sentence above uses the preposition "at" before the detail field value and the preposition "in" before the rest of the place display. Another way to do this is to customize the sentence for each case and specify which preposition you want: [P] married [PO] when you have the church name or [P] married [PO] when you don't. Some people use other, very involved systems for managing place prepositions but I prefer the methods above.

TMG allows you to attach exhibits to places, and you can view those exhibits via the Exhibit Log. When you open the Exhibit Log for an event, TMG shows you exhibits attached directly to that event. To see exhibits attached to places, you access the Exhibit Log via the Master Place List. As far as I know, TMG does not include place exhibits in any reports. Second Site includes place exhibits in its output when you use the "Place Index" feature. In a narrative, for example, the first reference to a place will be a link to the given place's index entry. The index entry shows everyone who has at least one event at the place. If that place has a place comment and/or one or more place exhibits, Second Site includes an icon to open a page that displays the place comment and/or exhibits.

Jim's response describes a good method that will avoid the tedium of fixing them all manually. Regarding TMGU, the only Living flag value that is eligible to be changed by TMGU "?". A blank value is not correct and TMGU doesn't have a special exception for that.

TMG Utility has a feature that can help fix the Living Flag values. See Set Living=N.

As far as I know, there is no way to do that in TMG. In the next version of Second Site, a companion program for TMG that creates web sites from TMG data, you can create maps. You can add markers to the map based on locations in your TMG data or you can specify locations via a Map Editor. It's not exactly what you described, but I think it may be worth investigating...

Michael, My guess is that your IP address is changing when the DSL connection drops. I think (but do not know for sure) that the WG forum site will force you to re-logon if you change IP addresses, even if you have the "Remember Me" option set when you logon. My guess is based on my own experience: I use a laptop that I carry between home and work, and whenever I change locations, I am logged out. It's a bit of a pain because the "View New Posts" functionality gets messed up when I visit the site after changing locations.

I am not an expert on the GEDCOM import feature so I can't help there. TMG is pretty strict about the GEDCOM standard and that might explain the issues. Taking another tack, however, have you tried importing directly from your old program into TMG? TMG will read the data files of many other programs and the transfer of information is more accurate when you do it that way.

Mark, Check out the Adjust Birth and Death feature in TMG Utility. In particular, read step 2 in the instructions. The feature has an option to set the primary designation for birth and/or death events. It may help you in this case. THe likely outcome is that some people would have to be fixed by hand (cases where a person had two or more events in the birth group or in the death group) but it would take care of the majority of people automatically.

I would use a single dataset for all families. It's much harder to maintain separate datasets, especially when there is overlap in sources, etc. If there are no connections, it's relatively easy to keep the lines separate in reports, etc., even if they are all in the same dataset. To answer your question directly, no. You cannot share sources, sentences, or anything else between datasets. The whole idea of a dataset is that they are separate. The dataset feature is useful for reviewing information that you want to keep separate, such as data sent to you from other researchers, but I don't think it helps in the situation you described.

TMG Utility has a feature to convert internal exhibits to external exhibits. It will take a few seconds to run, thought it may take you a few minutes to decide how to use it. Still, that's faster than a few weeks!

I went to the articles page and tried to open the first link, "Creating a Web Site". My browser asked me if I wanted to download a "pps" document, which I guessed was a PostScript file but who really knows. Umm... nope, don't wanna download that, I don't want to download anything. One down, 9 to go. The rest are PDF files. I took a peek at a couple and they'd be better off as HTML: there's not much formatting and certainly no requirement to make them PDFs. After looking at those briefly, I got tired of waiting for Adobe Reader to take over the window, tired of Adobe Reader not respecting the back button, tired of Adobe Reader putting big page breaks in the middle of the content for no apparent reason (I'm reading online, not on a piece of paper). Tired of ... well, you get the point. I stopped looking at the documents. There may be good stuff in them, but I am not going to invest the time to find out.