Family Historian User Group

Updated screen-shot - the earlier one posted did not have the Source expanded, though it makes no difference ...

You have not appear to have replicated my problem correctly.  Your Note is attached to the Individual.  Mine, as explained, was a Note attached to a Source attached to a census attached to the Individual.

Nick, not sure I understand exactly what you mean by 'source note' - I cannot find any reference to this entity in FH Help? Neither can I find reference to 'source note' in my copy of the 5.5 standard? The Local Note I described is attached to the Source record itself, rather than to the link to the...

I have a census entry for an individual. The Census entry has a local Note attached to it with some additional information about his employer (I don't want to use Associated Person in this case). The Note is linked to a Source Record, but I cannot link the Source Record to a Repository at this level...

Nick Walker said: didn't really understand this one: 5) 1911 census: 'Completed years present marriage has lasted'. Suggest the user should enter this as an accurate record of the census contents, even if they're wrong (a note can be appended if so).  GC should not start 'inventing' the right data ...

Not Nick, ... John [wink]

You're quite correct, I'd forgotten. I'd still prefer Occupation and Employment details recorded separately.

Just for info: the 1911 'Infirmity' column (Blind, Deaf, Dumb etc) is being redacted until 2012, as the Information Commissioner has ruled this to be sensitive.

1) 1851 census onwards: Support the Whether Blind/Deaf/Dumb column - suggest this should be recorded in DSCR as long as a Date and Source link to the census are also added (they may not have always been DDB); also appended to the AutoText (I add this manually now, if present) 2) 1891 census onwards:...

Perhaps, then, 'Evidence Explained' (pub: 2007, reprint 2008) would be the more appropriate reference, as it updates 'Evidence!' (pub 1997), inter alia, for 'records created by the new digital media: Websites, Digital books and journals, DVDs, CDs, Audio files, Podcasts, E-zines'. Until it, too, is ...

Hmmm, I'd rather have consistency of behaviour, rather than the current inconsistent and idiosyncratic behaviour, and I'd prefer to have explict configuration, rather than having fields appearing and then disappearing again.

Completely agree with AlanWhite; his is a more comprehensive exposition of what I was getting at. I realise that I mis-edited my OP; it wasn't just SOURCE tags that I want to control, despite my specific example relating to them.

Simplest way is in the Properties dialig box. Immediately to the right of the tab with the name of the first spouse, you'll see a blank grey tab. Click this, and it opens a new entry tab for the second (or subsequent) spouse details. Or, in Records Window, select the person you want to add the new s...

As an alternative, try this:

http://www.fhug.org.uk/cgi-bin/index.cg ... ries&id=97

which selects 1st, 2nd, 3rd etc cousins based on an input parameter ('Ordinal') and the selected 'Starting Individual'.

John

The =Relationship() function returns inconsistent results when the TEXT parameter is employed. Some 1st Cousins are listed simply as 'cousin', whereas 'removed' cousins are listed as '1st cousin [number] removed'. It would be better if all 1st cousins were so identified, or there were an optional pa...

Yes, SOURCES was what I meant. I was thinking of something else at the time I was typing. Typical male; can't think and type at the same time [smile] Have editted the OP to suit.

The ability to specify, in Settings, that optional/unused GEDCOM tags are not generated when adding SOURCES [/i] (thank you Jane!). As a specific example, I (and it seems from correspondence plenty of others) don't use the SHORT TITLE field. It's irritating to have to delete every time. It would sav...

Hmmm ... perhaps not, then.

Thanks.  [rolleyes]

You can output reports and diagram as pdfs if you get a pdf 'printer' such as PdfCreate or pdf995.

By Ged Census I assume you mean Gedcom Census. Yes, you do have to type in all the census details, but it's far far easier with this program than with FH!

HTH

Has anybody used this website?  Despite the help/faq only mentioning the USA, it appears, at least, to offer access to UK records.

Is it worth the subscription (currently between $29 and $40 depending on the package)?

Thanks

John

ID:3119

Excellent advice Chris. I've exchanged emails with GR about Hot Matches; I get very irritated by lists of supposedly Hot Matches when my person is born in (say) Devon and the so-called 'Hot Match' is born in America, or Australia, or Yorkshire ... etc etc. I asked whether it would be possible to, pe...

I do put GRO Quarter Dates in for BMD events found in the Indexes, but I flag this up by putting the registration District Name, appended by '[RD]' in the Place for the event. I also use a Named List (BMD Required) where I list the details of the BMD Event, Flag the Individual ('BMDReqd') and have a...

I'm with Chris - I'd like FH to support any format registered on my machine. I guess that would include video, sound ... that would be nice, though how FH would support them in reports would be interesting! [confused]

Simon,  thanks for a prompt reply.  I take your point about =Date(); I should have spotted that  [rolleyes]

The desire for parameters to be allowed and evaluated in Titles still stands, though ... [smile]

The ability to include (multiple) query parameters directly in Query Titles, and have them correctly evaluated. At the moment they are not; further, if you try to use a function to evaluate them, it either doesn't work - e.g. =ForceText() - OR you get prompted for a seperate instance of the paramete...

I thought it would be a good idea if Simon Orde's recent reply (below) to Kathy Kult about how Calico Pie take the Wish List into account when prioritising changes to FH, was made a sticky' posting on the Wish List Request thread, and possibly on the Wish List itself, just so it's completely clear t...

Simon, thanks for the reply.  At least I better understand what's going on. However, it does seem odd to me to treat the set of all records (i.e. regardless of Record Type) as a different data type to the set of all records of a specific Record Type; the latter is just a particular subset of the for...