Jerry Bryan

I use Dropbox to copy my RM database to my iPhone and my iPad. The normal way to do so is to copy my RM database to a folder called C:\Users\jbryan\Dropbox\Apps\RootsMagic\ on my Windows system, where jbryan is my Windows username. But recently, doing so didn't work. By that I mean that having done the copy process, my iPhone and my iPad couldn't see the new copy of my RM database.

Instead, I discovered that there was a new folder on my system called C:\Users\jbryan\Dropbox\Apps\RootsMagic(1)\  The old folder without the (1) was still there, so there were two Apps folders for RootsMagic, one folder called RootsMagic and the newer folder called RootsMagic(1). When I copied my RM database to RootsMagic(1) folder under the Apps folder, my iPhone and iPad could then see the new RM database.

So I have a solution to getting my RM database to my mobile devices, but it's puzzling. I didn't create the RootsMagic(1) folder, and I don't know what process did so. And I don't know why Dropbox on my mobile devices looks in the RootsMagic(1) folder rather than looking in the older RootsMagic folder. It all works, but an explanation of what's going on would be a nice solution to a curious puzzle.

Jerry

I realize that there is a suggestion to close the existing Wish List and start another one when RM8 comes out. So I am reluctant to post any new wishes right now. But I want to post this one anyway lest I forget.

This one may have been mentioned before, in which case I apologize for the duplication. But when a fact is shared with the another person, it is the name of the fact that is shown in the Edit Person screen for the other person rather than the name of the role. It seems to me that this makes no sense. It should be the name of the role that is displayed for the other person.

For example, suppose you create a role for the Birth fact called Midwife and share the Birth fact with the midwife when the midwife is known. The Edit person screen for the midwife will say Birth for the Midwife event rather than Midwife. For example, suppose you create a role for the Marriage fact called Flower Girl and share the Marriage fact with the flower girl when the flower girl is known. The Edit Person screen for the flower girl will say Marriage for the Flower Girl event rather than Flower Girl. The midwife was not born that day. She served as a midwife that day. The flower girl was not married that day. She served as a flower girl that day. It's just really backwards.

The sentences print correctly in narrative reports. It's just in the Edit Person screen itself that the display is totally backwards. Please fix it. The change should be so easy to make that it could even appear in RM8.0 without disruption to the RM8.0 release date.

Jerry

I've been working a lot lately with tagging media items, which leads inevitably to the occasional need to untag a media item. Unless I'm missing something obvious, doing an untag is much more difficult and is much more error prone than was tagging the media item in the first place.

The situation I'm describing is a total non-issue if a media item is only tagged one place. Under this circumstance, untagging is easy, it's not error prone, and it just works. On the other hand, if a media item is tagged many, many different times then untagging becomes almost an impossible chore. Here's the problem. Suppose you are in a sub-screen of the Edit Person screen and suppose you see a media item for a person or for a fact or for a source or for a citation that you wish to untag. So you click on the media item which brings up all the media tags for that item. Suppose you then click on untag. You would think that would untag the media file from the person or fact or source or citation that you used bring up the list of all media tags. But no, it typically untags some other media tag. In fact, it appears to delete the first tag in the list.

The proper procedure on the part of the user instead is to navigate through the entire list of media tags for that media items and find the one to be untagged. Only then should the user click untag. But if there are dozens of tags, the proper tag can be very difficult to find and more importantly, I have already in some sense clicked clicked on the "right" tag in the process of bringing up the list. I shouldn't have to spend a lot of time finding the "right" tag again.

The problem I'm describing really is only for media items with a lot of media tags. Examples where this might typically happen would be a comprehensive obituary that mentions a lot of people, a family bible page that lists a large number of people, or a page from a compiled family history that lists a lot of people.

And the worst thing is that if I fall into this trap in the RM user interface and make the mistake of deleting the wrong media tag, it's essentially impossible to discover which one I deleted so I can put it back.

If I am misunderstanding this situation, I would be pleased to stand corrected. But otherwise, I hope this whole situation might be improved in RM8 or some subsequent release.

Jerry

I was recently working on my long term (and on and off) project to move Place Details back into the Place field due to the likelihood of Place Details being lost on transfer of my data to other genealogy software. I'm doing it as a manual project and not an SQLite project, except that I do run a few SQLite reports as I go along to monitor the progress. I do all the updates from the RM user interface.

After moving all instances of a Place Details value to the Place field, I delete the Place Details value. Occasionally RM warns me that such a Place Details is still in use, even though both the RM user interface and my SQLite query say that the Place Details really isn't in use. I've done things like reboot my computer and run all RM"s database tools without solving the problem. I suppose I could just delete the Place Details despite the warning, but I wanted to see if I could diagnose the problem.

I don't know if can recreate the problem reliably or not, but the following real scenario is suggestive. I was moving all instances of the Place Details for Black Oak Cemetery in White County, Tennessee to the Place field. When I was done, a delete on Black Oak Cemetery from the Place Details field said that the value Black Oak Cemetery was still in use even though it wasn't. Upon further investigation, I discovered that my database also had a Black Oak Cemetery in the Place Details in Anderson County, Tennessee that also was not in use - I guess because I had already moved all the instances of Black Oak Cemetery from the Place Details to the Place in Anderson County, Tennessee and had forgotten to delete the Place Details. So I deleted the Place Details field for Black Oak Cemetery in Anderson County, Tennessee which was deleted without complaint by RM. Having done so, I tried again to delete the Place Details field for Black Oak Cemetery in White County, Tennessee which was now deleted without complaint by RM.

So I am wondering if having a Place Details field with the same name but under different Place values might somehow or other be confusing RM's delete process for Place Details. The multiple Place Details fields with the same name have different PlaceID's in RM's PlaceTable, which is correct and just what you would expect. But maybe something in RM is keying off the Place Name rather than off the PlaceID.

Of course, working on this project reminds me of lots of things in RM's place management that need improvement and I'm interested in what improvements might be in RM8. A really obvious one is that Place Details needs a Print button. Another really obvious one is that Lists>Places needs to be able to work in reverse order - not just print in reverse order but actually work in reverse order. Another really obvious one is that Lists>Places should show you how many times each Place and Place Details is used. You shouldn't have to run a report to see this data. It should just be there. Another really obvious one is that the Print button for a Place shows all the Place Details for the Place that are used but doesn't show any of the Place Details for the Place that are not used. Another really obvious one is that you can be in Lists>Places, highlight a Place Detail, and click the Delete button. Having done so, RM deletes the Place rather than the Place Details - a very serious trap in the user interface. But in the meantime, I would like to be able to delete an unused Place Details without RM saying it's still in use.

Jerry

People View allows you to sort by any one column. It's well known that I think it would be very helpful to be able to sort on multiple columns, but let's allow that to slide for now.

For any fact, you can make the Description field into a column in People View, you can make the Date field into a column in People View, you can make the Place field into a column in People View, and you can make the Place Details into a column in People View. If you sort People View by column for a fact's date, RM doesn't actually sort the column by the fact date. Rather, RM sorts the column by the sort date associated with the fact date for the column.

In some ways, this makes sense. But a fact date and a fact sort date don't have to be the same. And indeed a fact can have a null date and a real sort date. For example, I use this technique to place the burial fact after the death fact when the burial place is known but the burial date is not known. I don't consider "after death date" (whatever the death date is) to be a meaningful piece of information because a person is always buried after they die, and sometimes they may be buried on the same day they die. So I think an unknown burial date should be left null.

I use People View a great deal to identify and correct situations where data is missing. If the data in question is made into a column in People View and if People View is sorted by that column, then people with the missing data are all lumped together at the top of the list or the bottom of the list. And this technique is especially useful if I restrict People View just to a group.

But this technique doesn't really work quite right to find truly missing data for date fields if the date is forever unknowable but can be adequately approximated with a sort date. Therefore, I think it would be most helpful if People View supported separate columns for fact dates and for fact sort dates. The fact date column would be sorted by the fact date (including when it is null) and the fact sort date column would be sorted by the fact sort date (including when it is null). And indeed, sort dates are pretty hard to see in RM on any kind of global basis. You can see them for any individual facts, but not globally. So this would be a good view into all your sort dates.

Jerry