Thanks. I probably would not have figured that out till I got "bit"!
It's a recurring theme on this forum that new RM users are "bit" by this behavior of RM. Users will mark all the descendants of John Doe as red and then add a new descendant of John Doe expecting that new descendant to be red. It's a very reasonable expectation, but it doesn't work that way. In the case of groups, it's usually said that what RM has is static groups and what it needs is dynamic groups. And it's not just groups. Color coding, setting relationships, etc. are all static.
In going from RM3 to RM4, RM was a complete rewrite and it was RM4 that first introduced the groups facility. When the issue of dynamic groups first arose on these forums with RM4, the RM folks made a comment about dynamic groups having been planned for RM4 but the "dynamic" part of the feature ran into trouble during development and it had to be pulled from the product to get the product out the door in a timely fashion.
I suspect that the problem ran a bit deeper than just about getting the product out the door in a timely fashion. For example, suppose you color code all the descendants of John Doe as red and then you add a new descendant of John Doe. As described above, the new descendant is not color coded red automatically. But consider what RM would have to do behind the scenes to make all such features completely dynamic. Each time you add a new person, it would have to check all the groups, all the color codings, all the relationship settings, etc. to put the newly added person in the appropriate groups and with the appropriate color, etc. This could slow RM down to a crawl. And it's not just when adding a person. It would be when unlinking people, relinking people, when importing GEDCOM, etc. that RM would have to do all the checking.
I may be being Chicken Little and such completely dynamic facilities might be made to work. But I think that more reasonable would be some way under user control to reapply all the criteria for groups, for color coding, for relationships, etc. And maybe the criteria could optionally be reapplied any time an RM database were opened. Etc. In any case, the key event would have to be the saving of the criteria. Without saving the criteria, nothing could be done, anyway.
GenSmarts is not a product of RM, but it does seem to be in some sort of partnership relationship with RM. There is an RM interface to GenSmarts and you can buy GenSmarts from the RM web site. GenSmarts will make research recommendations for you based on your RM database, and it reads your RM database directly. GenSmarts has the ability to limit its scope of work to a subset of your RM database. The subsetting is done in GenSmart itself, and nothing about a subset in GenSmarts is stored in your RM database. I mention this only because the GenSmarts model is an excellent model of how to store subset criteria. You can mark individuals to include in the subset one individual at a time. You can mark individuals to include in the subset as ancestors or descendants of an individual, etc. And these various ways of marking are not mutually exclusive. The equivalent in RM would be to be able to color code two or three individuals as red, one at a time, and then also to make all the descendants of John Doe as red. A dynamic color coding in RM would remember all such color codings, not just the descendants of John Doe. GenSmarts can do it, so why not RM? Again, I would suggest that the only big issue would remain the question of exactly when and how often any saved criteria should be applied.
Jerry
