Jim Byram

I've been been able to replicate the error. The updater appears to be causing the problem. A couple of days ago, we surmised that the issue is that the activex control which contains the text viewer module is not properly registered and this is the source of the problem. The solution is to register the activex control. I installed v6.00.000 and updated to v6.07.000. (This is the same updater that Dale used.) I ran TMG, opened the Sample project and set the focus to Frank Alexander (1), opened the Exhibit Log and tried to view the text exhibit. And got: 2006.01.26, 20:27:58 1923Object GOMEDIAVIEWER is not found. 170 FRMEXHIBIT.MVIEWEXHIBIT Closed the Exhibit Log and exited TMG. Opened the Command Prompt. Changed to the system32 folder. CD \windows\system32 Registered the activex control by typing: regsvr32 richtx32.ocx Hit [Enter]. Got the confirmatory prompt and exited the Command Prompt. Ran TMG, opened the Exhibit Log and tested the text viewer. The viewer now worked with no error. I asked Dale to try this a couple of days ago and he said it didn't work. I've asked him to try again. Puzzled as to why the registration wouldn't work.

(This is not an official Wholly Genes response.) It works the same in TMG although the notion of a 'witness' differs in UFT and in TMG. All individuals linked to an event in UFT will be imported as such to TMG. It was suggested that you are in the Beginner data entry mode where the witnesses to events are hidden. Change to Advanced data entry mode. File / Preferences / Program Options / Data Entry / Data Entry Mode / select Advanced This PDF completely documents the UFT to TMG imports. It describes what data is imported and where it goes. http://www.whollygenes.com/files/uft2tmg.pdf There is also an article located on the Roots Users Group website written for the RUG Newsletter by Paul Lawrence on UFT import to TMG. http://www.rootsusers.org/ Go to Downloads, scroll down and you'll find a downloadable PDF file.... Once you start importing for real, there will be questions that you have that should be directed to the TMG-L mail list so that those who are experts in the UFT import can respond. http://lists.rootsweb.com/index/other/Software/TMG.html

(This is not an official Wholly Genes response.) There is no difference with TMG. Each source in the Master Source List can be linked by citations to as many name, relationship and event tags as you wish. You may be thrown off by the Mills templates with the details in the source. I do very much what you describe with custom census source types. The census source is per year - 1850 U.S. Census (Free Schedule) - for example. They could be by year and county as your example. The details are in the citation detail. Here's my 'template' for creating the citation detail entry for US census entries - ST, Co, Tn, p. n, ED n Sh n Ln n (Nat. Arch. Film #). People using TMG record census sources many, many different ways depending on what suits them. The UFT MIlls census templates are very similar to the TMG Mills census templates. Sources in TMG are specific to the data set, not external to the databases in a master library as with UFT.

http://www.pocketgenealogist.com/download.htm The “Unregistered” version is a “try before you buy” version. It is fully functioning except it does not allow data entry, direct imports, or the “Tree” views. (Ancestor and Descendant)

(This is not an official Wholly Genes response.) The answer is to try both and compare the results. There are a few omissions from the direct Legacy import such as the citation and source 'actual text' fields. The loose ends for the direct import have been reported.

In terms of TMG functionality? None at all. There is an issue of access to the installation depending on operating system privileges for different users if an 'all users' installation is located in a privileged folder such as Program Files (discussed in a different topic in this section).

No. You have to proceed as you have been doing. This is not the appropriate forum for this topic since this is not a site (aka related to this Message Board) issue. I'm assuming this is a v6 topic and should have been posted in the 'The Master Genealogist v6' support forum (above).

Sure. You'll notice that when you install TMG, on the first screen, there are alternates to install for 'all users' or for a single user (or different single users if you have more than one). You install one installation for 'all users' and after that is done, you install a second installation for a single user. Each installation needs to be to a different program folder location. And you will need to unlock each installation when run for the first time. Be aware that each installation has different settings for paths and the configuration files (app.ini) for the installations will differ and you must be aware and maintain that difference. Other files such as layouts can be used in either installation. Running two installations is straightforward but requires a certain amount of discipline and awareness of the differences between the two.

PDF printer drivers have a variety of settings that end up affecting the size of the PDF file produced (for example... how images are handled, whether fonts are embedded, etc.). You would need to configure each driver with comparable settings before you could make a valid comparison.

Arman, Using WinXP... I'm wondering if the issues are being encountered because the installation in Program Files is an 'all users' installation rather than an installation for the specific user. I experimented with my 'single user' installation in Program Files running my user with non-admin rights and manipulated various files in the program folder with absolutely no problem. (tried app.ini, repeat files, webother.txt, the Sample project, etc.) On the other hand, with an 'all users' installation in Program files, it was completely unusable by a single user since none of the non-static configuration and data files could be changed by the non-admin single user. If WinVista locks down program Files for even single user installations, then there will need to be changes. This is a non-trivial issue since many of the non-static files in the program folder are used by all users. In addition, static files can be added by the user to the program subfolders such as frames and graphics. Jim

(This is not an official Wholly Genes response.) Yes. I'm guessing that you aren importing from the File menu (File / Import) and there is a known bug when doing this. Do the import from the Welcome screen (Welcome / Import) when you start TMG and this error shouldn't happen.

Sorry. This has been on my to-do list for a long time and I've just gotten to it. v6.07.000 appears to be running just fine under WinXP Pro x64. I still need to exercise all the cracks and crevices but see no problems at this time. At this point in time, I wouldn't recommend anyone running x64 as their default operating system unless drivers exist for all of your hardware and all of the applications that you typically use have no issues. There are also some limits to web browsing that require working around with the 32-bit browser. Put another way, x64 is not for the casual user.

Kevin, My inclination is to do nothing. I built a test GEDCOM and tried it with GenViewer and Family Historian (which uses GEDCOM 5.5 as it's native database). GenViewer uses the last source memo found which means it doesn't accept duplicate source NOTE tags just like TMG. Family Historian accepts both source notes but has no structural constraint since it is using the GEDCOM file. Both programs reject the REPO structure since it is completely illegal. Repository records are top level records in a GEDCOM. It is illegal for the repository to be buried in the source record. Note that TMG actually imports this but is having some difficulty with the structure. This represents just one of many instances over the years where FTM ignores the GEDCOM specs and does it its own way. The trick is to import this to something like PAF to see if the data gets in and create another GEDCOM from there. This particular file is not a big undertaking to clean up after import since we're not talking about much data to hand correct. The specs are not clear on this point. The practice from what I can see is to have one NOTE tag per source. It's hard to see how any program could have more than one NOTE tag since the program note field for sources is typically one field. As notes above, the REPO structure in this GEDCOM is illegal. And I would again think the practice to to have one repository note for the same structural reason as with sources. I don't see this tag as being different from any other GEDCOM tag and can have unlimited length by way of CONC and CONT statements on the following lines. In any event, the length of the TMG field is the length. The design of TMG is not driven by what GEDCOM does or doesn't do except for following the rules on export. Don't think so. the TMG option on the Supplemental tab is a list box of set choices and it would be hard to map the GEDCOM tag to that design. Jim

If you ran VFI with the two correct paths in the search, each image path should have been corrected. This didn't work? I have tested this extensively and have never seen it not work correctly. The message at the end of the VFI run has nothing to do with the exhibit search. It helps to disable thumbnails when checking exhibit paths since thumbnails hide what is going on. In any event, the external exhibits option of VFI should take care of your changed paths if each exhibit has a unique name and you entered the two paths where the exhibits currently reside.

If the NOTE tag is subordinate to the source record tag (in other words, 1 NOTE), the text should always be imported to the note field on the Supplemental tab. You'll need to point me to some examples to check. Hummm... There are 40 NOTE tags in the sources and all are using xrefs so don't yet see a reason why some would work and others not.

Ray, You used PathWiz! with your project? I think those are the PathWiz! backups. You can delete these files. Jim

The problem is that you selected: Step 5: GEDCOM Options 1 Convert widowed SOURce tags This option will never apply to any GEDCOM 5.5 file which is what you are trying to import. In fact, I've never seen a GEDCOM file that required this option other than the GEDCOM that I created to originally test this. Stick to the defaults except where you understand exactly what the change does and that you need to make it. For example, it made sense to select 'Assume marriage of parents'. You need to look at the GEDCOM and the differences with a given option to see if a change makes sense. You will need to use Step 7 to assign the custom GEDCOM tags as custom tag types for import.

There is nothing intrinsically wrong with the first source that you say doesn't import so that points to the citations as the issue. I need to see the GEDCOM. How big is it when compressed into a ZIP file? You can contact me by email by clicking on the link below: Jim Byram

For the file type selection, I would suggest using either 'Word for Windows 2000 or later' or 'Rich Text Format (RTF). Both worked fine with OO 2.0 last time that I tested.

I tried this with a flash drive and got the same result. Will report it.

Shouldn't be although the permanence of unlinked places is always an issue. I tested this and couldn't remove the unlinked place with Optimize until I deleted the exhibit.

Michael, You made a critical omission when you set up your test. When you set up source #1, you need to tick the ibid selection 'ON - Requires same source and [CD]' on the Output form tab. There is a bug and a design omission. The bug is combining source endnotes/footnotes (with combine selected) with exhibit output to endnotes. This causes a recursion issue where report output is prematurely terminated and an endnote/footnote contains citations to itself. Issues like whether the exhibits endnote section should have a title when standing alone is a design issue, not a bug. Jim

All formatting codes are stripped out by design since they are meaningless to another program. Don't know why an actual TAB character would be stripped. Have to look at that. Trailing spaces are stripped by design. If an importing program uses this CONC form, it should understand to add the space on import. You should use the default CONC form (which is the correct form breaking within words) if possible.

Doug, With the next update, hopefully, you should find that the output is consistently FORM JPEG. If that's not the case, please let me know. Jim

This is clearly a PJC file issue. Could you send me that copy if you still have it. Clearly not. Can't get too paranoid. Good practices save your bacon. Click on the link below for my email. Jim Byram