Jump to content


Member Since 26 Apr 2008
Offline Last Active Today, 02:32 PM

Topics I've Started

TreeShare Foibles - Family Facts, Inconsistencies, Phantoms et al

07 January 2018 - 11:00 AM

A discussion on FB has drawn me into the TreeShare spaghetti of issues. It started with the complaint about "Residence (fam)" fact label on an Ancestry Member Tree created by a TreeShare Upload being changed to "Residence (family)" when the fact was updated to AMT for a change that had been made in RM. TreeShare no longer matches these otherwise identical facts so the fact on one side has to be added to the other and the remaining unmatched one deleted. Adding to RM may result in a custom individual fact type with "(family)" in the name - a source of confusion. Re-adding to AMT means deleting the renamed fact separately from both spouses. It gets more complicated because the TS Update to AMT only changes the value for the fact for one spouse - why not both?


I've pulled on a few spaghetti strings and tried to document my findings for other users to learn from, analyse, contribute to... and for RM developers to focus some corrective effort. They are Google Slides slideshows:


1. TreeShare Foibles #1 Family Facts (A)

2. TreeShare Foibles #2 Family Facts ( B) 

3. TreeShare Foibles #3 - Fact Update Causes Mismatch


What little use I have made with TS has been for download so I had not noticed that a TS upload of a RM family-type fact produces a special fact on AMT. I understand that all AMT facts are supposed to be individual-type but uploads result in the other spouse's name being hyperlinked from the fact on the AMT Facts and Timeline pages of a person's Profile, just as is seen for (some) Marriage facts generated on the AMT from an Ancestry Source Hint. I haven't found a way to create such spousal hyperlinks through the AMT UI and, somehow, these cross-linked individual facts do get transformed through a download or a TS Add update from AMT to RM into RM family-type facts. So if TS Upload and Download can create these "family" versions on either side, why can't TS Update propagate changed values from one family fact in RM to both individual facts for the spouses on AMT and, likewise, in the opposite direction?

Compressed Pedigree Chart

07 November 2017 - 11:04 AM

I needed a compact 6-generation pedigree chart as an illustration for a 2-page report for my local Society on my ancestors living at the time of Canada's Confederation in 1867. I had done one using the RM Pedigree Report for another member but he had half as many ancestors to cover - I'll describe it separately because it, too, was a challenging, learning experience. For my report, I gave the RM Ancestor Wall Chart a try. Here's the result, tucked into the lower left of the page:




Here's a comparison of a compressed pedigree to the original generated by RM.



Had I used the original, I wouldn't have had enough space for text. The overall process involved editing in RM Wall Chart to mesh the columns for the first 3 generations into the fourth column, exporting a PNG, cropping with Paint.net along with deleting the white space outside the boxes (its selection wizard makes that a 2-click operation) and inserting the revised PNG into the Word doc.


Editing in Wall Chart is tricky, partly because the objects RM generates have dimensions and locations that don't correspond to the default grid or to any practical grid and there are hard-coded dimensions that a link can revert to when moved. Without snap-to-grid, multiple columns or a single column can be selected and dragged and the links stay rectilineal. But, ultimately, they start crossing through adjacent boxes and vertexes need to be moved. Moving a vertex may result in a segment on an angle. This can be very hard to correct. Working in 200% zoom to move a vertex lowers the risk. Dragging a segment regenerates the rectilineal polyline that goes where you do not want it but you can start afresh on it.


Working with snap-to-grid may actually compound things - I'm not sure. I set the grid spacing to 0.1", select and group a column of boxes and then adjust the right and left sides to snap points and then move it. Link lines may need to be tweaked as they do without snap. At times, I have resorted to deleting the link and creating a new one (the blue L control, not the black L in shapes).


RM color coding has no effect on the chart text, only on the box fill. I wanted the boxes white and the names of those not alive in 1867 subdued. That was easily accomplished on this small chart by selecting multiple boxes and then changing the font colour through Properties.


I found the Chart Help to be superficial and suspect there are features that are not even described. Nonetheless, if you need a one-off as I did for this report, you aren't completely at the mercy of the standard output.

TreeShare: adding Ancestry Source to another fact multiplies media

21 July 2017 - 09:25 PM

Given an Ancestry Source already tagged to a fact on my Ancestry Member Tree which has been TreeShare downloaded to a new database. Add that Ancestry Source to another fact and Accept that change. TreeShare downloads the image file again and repeats its name in parentheses. Now the media folder has the same image twice with two names and the RM Media Gallery shows them both.


Do it again. This time, it appears that the image may be downloaded again but it might not. Either way, there remains the two images in the folder, "name.jpg" and "name (name).jpg". However, the Media Gallery now shows 3. That's because the MultiMediaTable has three records for the same image. For example:

MediaID MediaFile
1 40356_320214636_0045-00433.jpg
4 40356_320214636_0045-00433 (40356_320214636_0045-00433).jpg
5 40356_320214636_0045-00433 (40356_320214636_0045-00433).jpg
So citation media files are at least duplicated and, in the Media Gallery, they multiply like rabbits. And there's no Merge tool for media.

Why update iPad app to 1.3?

13 July 2017 - 09:25 PM

With reports of problems with both the iOS update to 1.3 and with the corresponding update to the Android version which I also experienced, I checked my iPad. The app still works on my old iPad 2, still downloads from DropBox even though it is running the Dec 2015 version 1.2.1 and despite not having done the update to 1.3 for the DropBox API rev. I'm wondering whether there is any merit in updating to 1.3 if it means risking breaking something.


What does seem to be different from before is that repeated RootsMagic 7.5 Save to Dropbox results in serialized files on Dropbox instead of one file whose name does not change and whose change in timestamp triggers a notice in the iPad app. Now I get no no notice and I have to manually select and download the new file and delete the old from my device.


I don't know if the multiple versions of the database file on Dropbox is a consequence of a change in the API or a change in the way RM 7.5 uses the API. I haven't made much use of it so I cannot identify when it began.

June 30 version not working on Moto G4 Play

13 July 2017 - 08:59 PM

Having read accounts of others having a problem with the RM App on Android phones since the June 30 update for a new DropBox API, I installed RM for the first time on a Moto G4 Play phone (Android 6). On launching, I get the error message that "RootsMagic has stopped working".


The app still works on my old iPad 2, still downloads from DropBox even though it is running the Dec 2015 version 1.2.1 and despite not having done the update to 1.3 for the DropBox API rev.