Jump to content


rrh7254

Member Since 02 Aug 2017
Offline Last Active May 03 2018 03:05 PM
-----

Posts I've Made

In Topic: Wall Chart Problem

29 April 2018 - 01:29 PM

I too am having the exact same problem when running Wall Charts, with options: Descendant Chart, 6 generations, bottom to top (which for reasons I don't understand generates oldest ancestor on top to youngest descendant on bottom).

My Version info is 7.5.6.0 running on MacOS 10.13.4.

 

My database is rather small  (53 people) and all linkages appear to be correct.  Box size and spacing is the default.

 

Upon generation of the chart, the horizontal connectors for different descending families cross on top of each other making it appear like many children belong to more than one set of parents.  Moving the child boxes around will however reveal that they really are just connected to one set of parents.  But it takes a lot of playing and shifting to figure out how to properly isolate the proper family groups (and that's only with a small tree).  It would seem near impossible should this happen on a larger tree (not clear there would be enough "sheet size" to make the placements).

 

The problem is clearly that, for some users, the box placement on the wall chart is improperly being calculated in a way that horizontal connectors (across children) for one family overlap the horizontal connectors for the children of an adjacent family on the same generational level.

 

I also observe other box placement issues which may relate to the same positioning problem.   For example, I observe the children for one family (let's call it the "center" family) are shifted so far left that they are more aligned under the adjacent parents on the left, and likewise, the children for the adjacent parents that fall to the right of the "Center family" are more aligned under this "center" family.  I think it's this shifting that then generates extra long horizontal connectors which now overlap each other.


In Topic: Going under the hood of Memorize Sources (Citations)

21 August 2017 - 07:52 AM

 

The results where you made a change in the Source Details portion of a citation and it wasn't reflected when you ran a report makes no sense. I guess I'm wondering about the nature of the change that you made. You can make changes that do affect the footnote sentence, and you can make changes that might not affect the footnote sentence. It depends on which source template you are using and on what the change was that you made. Is it possible that you made a change in the Source Details that didn't actually change the footnote sentence?

 

Jerry

 

Thanks guys.

 

Jerry's observation proved to be correct.  But I think I also observed something I'm only beginning to get my head around.

 

The Detail Fact field I had edited was, in fact, incorporated in both the full footnote and the short footnote sentence templates, so it wasn't quite as simple as it not being in the sentences.

 

I had made a custom source template that involved the use of abbreviations for certain Fact Detail fields (i.e. full version entry || abbreviated entry).  The edit I had initially made to one copy of the source (but not the other) only affected the abbreviated portion of the field in the copied ("memorize") source.

 

I guess when RM initially compiled the potential list of sources requiring citations, it logically would have seen them as two different "standalone" sources, but since both only appeared one time each, each probably generated what would turn out to be identical full footnote citations.  RM then, despite them actually being two different "standalone" citations, recognized they were the exact same construction and combined them as one citation (one reference number) when putting the citations into my narrative report.

 

When I went back and edited the "full version entry" for the copied ("memorize") source that had the previously edited abbreviation entry, and re-ran the narrative report, I got a different result. RM must have still recognized the Master portions of the sources were common, so it generated a first full footnote using the unabbreviated text of the first source, but then generated a 2nd short footnote using the edited abbreviated text of the 2nd source.

 

So while I still don't fully understand what RM is doing under the hood, I get the sense that maybe RM is first trying to match the Master Source fields to decide if two citations can potentially be combined and then second looking at whether the Detailed Source fields can also be combined.  But in that second part it may only be looking at the unabbreviated portions.  If the unabbreviated portions are the same, it treats them as fully common and generates just one source citation.  If the unabbreviated portions of the detail fields are different (and assuming Master Source fields are the same), then it generates both full and short footnotes, but they are based on each source copy's information (independently)....Or so, I think.

 

I guess that suggests to me there is no real cross-linking in the database for related source information at all, and all the smarts for combining sources is done in the citation generation engine.  While probably not really taking advantage of the power of databases, I guess it works even when users manually enter the same source over and over.  This would probably be necessary to handle things done by users before the the "memorize" feature was added.

 

....That's the big problem with handling "legacy" when updating databases.  It tends to hand-cuff your options sometimes.

 

--Randy


In Topic: question about alternate names in sentence templates

14 August 2017 - 12:53 PM

That's a clever approach. Another factor to consider... These custom "Alt Name (xxx)" fact types will not be Name-type facts; instead, they will be Event-type facts. They will not show up in the Sidebar Index, report Indexes, nor can they be searched or filtered as Names. You cannot create a custom Name-type fact type.

Oh, that's too bad!  That really limits the value  of creating an "alt Name (xxx)" fact of any kind.


In Topic: question about alternate names in sentence templates

14 August 2017 - 07:55 AM

Thanks Jerry!    I'm an experienced genealogist who is trying to make the jump from TMG.  I've watched most of the basic RM Webinars, read the RM book, and spent hours going through the forums, yet every time I sit down to actually work on my data, I immediately find my self saying "I'm not sure how to do that" or at least "how best to do that".  As they say, the devil is in the details.  And there are many details in RM I have yet to learn. (I wish there was an "advanced" RM book covering "best practices").   But I am very grateful that all you RM "pros" are willing to help guide us RM newbies.  Again, thanks!


In Topic: question about alternate names in sentence templates

14 August 2017 - 06:59 AM

Zhangrau, I like that, it's nice and clean.  But you got me wondering, would it be possible to create 3 fact types which I will call

 

Alt Name (Begin)

Alt Name (Continued)

Alt Name (End)

 

with respective sentence structures

 

[person] was also known as [ [Desc]< [Date]>

,  [Desc]< [Date]>

and  [Desc]< [Date]>.

 

to generate a singular extended sentence of aka names?  (so you don't keep repeating the "Sarah was also known as" over and over.)

 

I think the sources would mark properly in a narrative report, but I am just a few weeks into learning RM and am not sure what other negative ramifications there might be.

 

Also, might it be possible to embed the separator strings "----" and "====" into the sentence structures for Alt Name (Begin) and Alt Name (End) respectively to save adding the extra seperator "facts".  I know it wouldn't show on the person's edit screen, but I would really only need those separators to show in my reports.  I know you can put any text into a fact sentence, but I'm not sure how you would embed a <carriage return> or <new line> command.  Is that even possible with RM?