Jerry Bryan

I wish for a tool to identify and fix certain family link problems.

The "identify" part of the tool would be an addition to the basic Find dialog that would find individuals who are linked to the same spouse partner twice. Essentially, the Find would be finding duplicate entries in RM's FamilyTable. For example, there might be family #12 where the partners are people #27 and #28, and there might be a family #9934 where the partners are people #27 and #28.

The "fix" part of the tool would merge the two families. In my example, it would be merging family #12 and family #9934. The tool would merge family sources and family notes, but would not merge family facts. In practice, I would suspect that the percentage of RM users who use family sources and family notes is extremely small, but nevertheless family sources and family notes have to be addressed. I would emphasize that family facts can have sources and notes, but a source for a family fact is not the same thing as a family source and a note for a family fact is not the same thing as a family note. So the only thing that has to be merged for sources and notes is family sources and family notes. Finally, the list of children in the ChildTable would need to be merged, so that each child is in the child table for the couple just one time. A possible problem is that the list of children could get out of order in the process. So it seems to me that this kind of tool should not work globally on the whole database, but rather should just work on the currently highlighted family that you have just found.

I make mention of the fact that a similar situation that could benefit from a find tool and a fix tool is where there is just one family and the same child has been linked into it twice. On it's face, this is a much simpler problem that doesn't require any merging of anything and simply requires any duplicate children to be deleted from the ChildTable. However, just like in the case with spouses who are linked to each other multiple times, the fix could leave children in the wrong order. So again, it seems to me that this kind of tool should not work globally on the whole database, but rather should just work on the currently highlighted family that you have just found.

Jerry

I wish for an option in RM whereby you can run in Essentials mode temporarily, even though you have registered your product key. The purpose would be to be able to see what users in Essentials mode see, for example if you are helping such a user. Having feature list of Essentials mode vs. full mode is not the same thing as being able to run in Essentials mode. I picture this being an on/off switch that is easy to turn on and off.

You can accomplish the same thing by doing a CTL-U and disabling your product key to get into Essentials mode and then by re-entering your product key to get back into full mode. But that's an extremely user unfriendly way to do it.

Jerry

I just now had a situation where I needed to export a source template, but I exported the wrong source template to the correct Windows filename. So I did it again using the same Windows file name and exporting the correct template this time. It wouldn't export because the file name already existed. There was not an opportunity to approve the overwrite. It just wouldn't work.

The only solutions are to delete the existing template file from Windows or to export with a different Windows file name. Neither solution seems very friendly. Indeed, the first time I did this I didn't notice the message that the source template hadn't exported correctly and I sent the wrong template to a user who wanted a copy of one of my source templates. It was a puzzling problem to resolve after first failing to notice that the correct source template hadn't overwritten the incorrect source template.

Hopefully this behavior might be improved in RM8, preferably RM8.1 if fixing this would delay the release of RM8.0.

Jerry

I don't think I have reported this problem before, and if not I should have. It's a problem in RM7 and I don't know if it's a problem in RM8 or not. I don't expect or wish it to be fixed in RM7, but I hope that it's not a problem in RM8 and that if it is it will be fixed in a timely fashion.

I have made a group of all the people buried in a specific cemetery, 53 people in all, and I wish to do some minor editing on each of the 53 people. So I made a group of the people, went into People View, and filtered People View by the group. My idea was just to go down the list doing my edits, one person at a time. I have the columns in People View set up so I can see my minor edits in People View as I complete each edit. But after exiting the Edit Person screen and returning to People View, a totally different person now has the focus than the person I just edited. Indeed, the person now with the focus is down towards the bottom of the list of 53 people and the person I just edited not only no longer has the focus but no longer is even displayed on the screen. So I have to scroll the screen back up. It slows me way down.

Jerry

Not too long ago, I mentioned on these forums that RM's UTF-8 character encoding would not support the UNICODE encoding for many languages of the world. That was completely incorrect, and indeed RM's UTF-8 can support anything that UNICODE can support which is pretty much every language in the world. It was an honest but grievous error on my part. Here is some background on the issue.

Back in the earliest days of computing, computers had very limited character sets and could not even encode lower case letters. I believe before that there were character sets for teletype machines that could not even encode numeric characters and numbers had to be spelled out in English. Also, all the initial character sets for computing were English letters only. Gradually, these limitations were resolved where lower case letters could be encoded and then later so that letters from languages other than English could be encoded.

An early character set that could encode lower case English letters was ASCII - American Standard Code for Information Interchange. ASCII was truly an American Code. An organization called the International Standards Organization also developed character sets for other languages, especially for languages based on the Latin alphabet. These character sets were called ISOnnn where nnn was a three digit number. The code that corresponded to ASCII and American English was called ISO646 and I don't remember what the ISO code was called for French or German etc.

In any case, ISO recognized that a code needed to be developed that would support all the languages in the world, and the code that was developed was called ISO10646. ISO10646 was much criticized, even by the committee that developed it. It was considered to be messy and unwieldy. One characterization of ISO10646 was that a committee had been tasked to develop a horse and instead they came up with a camel.

I was a part of a group that reviewed ISO10646. I had nothing to do with the design, just the review. And the review committee was humongous - at least hundreds of people if not more. So the review committee was scarcely in mutual agreement, either, except that most everybody on the review committee thought that it had serious problems. The upshot was that ISO10646 was voted down, mostly by the same people who developed it (I didn't have a vote). I don't remember the exact date, but this was in the late 1980's.

One of the problems with ISO10646 was that it had variable length characters. Basic English characters would remain encoded as 8 bits. But many letters for some languages would be encoded as 16 bits and some letters for some languages would even be encoded as 32 bits. This kind of variable encoding would have made any kind text very difficult for computer software to process.

In the aftermath of the failure of ISO10646 came UNICODE which is what we have today. The legend is that the basic design of UNICODE was accomplished by two guys at a restaurant in Silicon Valley who in one night wrote their ideas down on a cocktail napkin. I think the legend is mostly true and is repeated to emphasize that committees of thousands are not good ideas. In any case, an important attribute of UNICODE was that all characters of every language would be represented by the same number of bits. UNICODE has evolved a bit since its beginnings, and in the current model it is a 32  bit code of which only 21 bits are used. As such it is wasteful of space. It is further wasteful of space if you have a lot of English text that can still be encoded in 8 bits.

The early days of UNICODE were the 1990's and that's where I lost contact with the project. The last I heard, there were going to be 8 bit and 16 bit versions of UNICODE that could be used when all the data would fit in either 8 bits or 16 bits. But that's not so. This is the source of my honest mistake in understanding UTF-8.

UNICODE is 32 bits per character. Period. What has happened since then is that pure UNICODE is seldom or maybe never used directly. Rather, encodings called UTF-8, UTF-16, and UTF-32 are used. To tell you the truth, I'm not sure what the difference is between UTF-32 and pure UNICODE since they are both 32 bit encodings. But in the case of UTF-8 and UTF-16, they are variable length encodings of full UNICODE and the design is very similar to the original "a camel is a horse designed by a committee" design of ISO10646. If UTF-8 is used to encode UNICODE which contains only English or western European letters, then each letter will be encoded as 8 bits and can be processed one byte at a time without dealing with variable length characters. But if UTF-8 is used to encode UNICODE which contains other characters, there is a likelihood that some of the characters will be encoded as multiple bytes. Software which processes character strings encoded in this way either have to deal with the variable length characters or else they have to call standard functions to convert the variable length strings to full UNICODE. Once the conversion has been accomplished, the software can deal with character strings with fixed length characters where all the characters are 32 bits in length.

I really don't know how RM deals with UTF-8 strings internally. It may convert them to pure UNICODE before processing them and then convert them back to UTF-8 before writing them to disk. I really don't know. But I will post a follow-up message to report on some experiments with RM where I have entered characters into RM that cannot be encoded using only 8 bits. RM does seem to support them just fine. So I was wrong. RM can stay with UTF-8 forever and be able to support every language in the world if it so chooses.

Jerry