Is there any way for a plugin to be aware of which citation is in the active Citation Window?
I've got a lot of examples of lumped citations to things like FamilySearch and FreeReg that I use as temporary sources until I find the original document. The general format is
paramater = value
parameter = value
...
It's neater in FH7 to display those in a two column table. If it were a split source it's easy, as we can identify which source is selected in the Records Window and process its one permitted value of TextFromSource. The closest I can get with a lumped citation is to open the citation in the Citation Window and copy the plain text to the clipboard. I then invoke the plugin from the Tools menu, which reads the clipboard contents using fhGetClipboardData("UNICODE TEXT"), formats to tabular form with correct font and optimised column widths, and presents in a rich text window using fhPromptUserForRichText(rt). Finally, I copy this formatted text back to the citation window.
It actually works reasonably well, but it would be even better if it could identify the displayed citation (which presumably means identifying both the source it comes from and the event it relates to), so everything happened automatically. It would be easier to process all such citations automatically (which would also address my pet whinge about out-of-sync duplicates in lumped citations ) but I'd rather do it one at a time as I review the data.
* Read the Citation Window by plugin?
- Mark1834
- Megastar
- Posts: 2458
- Joined: 27 Oct 2017 19:33
- Family Historian: V7
- Location: South Cheshire, UK
Read the Citation Window by plugin?
Mark Draper
- tatewise
- Megastar
- Posts: 28342
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Read the Citation Window by plugin?
Until I read your last paragraph I was going to suggest updating all the lumped Citations via a selected Source record.
It is not possible to determine the current Fact or Citation that the user has selected.
The best I can suggest is the plugin lists all lumped Citations for a chosen Source record so the user can choose one to update.
Then the update happens automatically.
The list could be filtered by those Citations that already have a Rich Text Table so they are excluded.
It is not possible to determine the current Fact or Citation that the user has selected.
The best I can suggest is the plugin lists all lumped Citations for a chosen Source record so the user can choose one to update.
Then the update happens automatically.
The list could be filtered by those Citations that already have a Rich Text Table so they are excluded.
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- ColeValleyGirl
- Megastar
- Posts: 5465
- Joined: 28 Dec 2005 22:02
- Family Historian: V7
- Location: Cirencester, Gloucestershire
- Contact:
Re: Read the Citation Window by plugin?
I don't think there's any way for a plugin to be aware of the state of the FH interface, except in certain limited ways, i.e. getting the currently selected item, or the item currently displaying in the property box (but that would be a record, not a citation). There's the special case of the current Prepared Citation (which is actually accessing the HEAD record, but that wouldn't help you either.)
Helen Wright
ColeValleyGirl's family history
ColeValleyGirl's family history
- Mark1834
- Megastar
- Posts: 2458
- Joined: 27 Oct 2017 19:33
- Family Historian: V7
- Location: South Cheshire, UK
Re: Read the Citation Window by plugin?
Thanks folks, I feared that might be the case, and if neither of you think it can be done, it must be so.
A possible refinement would be to convert all citations where the text matches the clipboard contents with a suitable user prompt (e.g. “Format FreeReg citation for John Smith BIRT at ... on...?”, Yes/No/Cancel). That would take care of duplicates, but I don’t know if FH will get upset if I change the contents of the Rich Text Editor in code while it is still open. There’s only one way to find out for sure...
A possible refinement would be to convert all citations where the text matches the clipboard contents with a suitable user prompt (e.g. “Format FreeReg citation for John Smith BIRT at ... on...?”, Yes/No/Cancel). That would take care of duplicates, but I don’t know if FH will get upset if I change the contents of the Rich Text Editor in code while it is still open. There’s only one way to find out for sure...
Mark Draper
- tatewise
- Megastar
- Posts: 28342
- Joined: 25 May 2010 11:00
- Family Historian: V7
- Location: Torbay, Devon, UK
- Contact:
Re: Read the Citation Window by plugin?
Are you asking if a Plugin can edit a Rich Text field that is currently displayed to the user?
The answer is yes, any field that is on display can be changed by a plugin.
Just remember to use the fhUpdateDisplay() function.
There is one gotcha that I discovered in my Search and Replace plugin.
If the Rich Text field has record links then they must be recreated after the field is updated.
So the sequence is to save the _LINK_* & _LKID parameters in a table, update the Rich Text field, then recreate the links.
e.g.
The answer is yes, any field that is on display can be changed by a plugin.
Just remember to use the fhUpdateDisplay() function.
There is one gotcha that I discovered in my Search and Replace plugin.
If the Rich Text field has record links then they must be recreated after the field is updated.
So the sequence is to save the _LINK_* & _LKID parameters in a table, update the Rich Text field, then recreate the links.
e.g.
Code: Select all
if strDataClass == "richtext" then -- Cater for richtext
local arrLink = {}
local ptrLink = fhNewItemPtr()
ptrLink:MoveToFirstChildItem(ptrItem) -- Save any record link details
while ptrLink:IsNotNull() do
local strLink = fhGetTag(ptrLink)
if strLink:match("^_LINK_%u$") then
local intLink = fhGetValueAsInteger(fhGetItemPtr(ptrLink,'~._LKID'))
arrLink[intLink] = { Tag=strLink; Ptr=fhGetValueAsLink(ptrLink); }
end
ptrLink:MoveNext()
end
fhSetValueAsRichText(ptrItem,fhNewRichText(strNewVal)) -- Update richtext field
for intLink, dicLink in pairs(arrLink) do
ptrLink = fhCreateItem(dicLink.Tag,ptrItem) -- Reconstruct any record link details
if ptrLink:IsNotNull() then
fhSetValueAsLink(ptrLink,dicLink.Ptr)
ptrLink = fhCreateItem('_LKID',ptrLink)
if ptrLink:IsNotNull() then
fhSetValueAsInteger(ptrLink,intLink)
end
end
end
Mike Tate ~ researching the Tate and Scott family history ~ tatewise ancestry
- Mark1834
- Megastar
- Posts: 2458
- Joined: 27 Oct 2017 19:33
- Family Historian: V7
- Location: South Cheshire, UK
Re: Read the Citation Window by plugin?
Thanks Mike, these are all inherited from FH6, so no links. I’ll modify it to change all citations that match the clipboard contents. It’s better than what I have now, and probably the best that is possible.
I can see now why Jane limited her excellent plugin to formatting split source text!
I can see now why Jane limited her excellent plugin to formatting split source text!
Mark Draper
- Mark1834
- Megastar
- Posts: 2458
- Joined: 27 Oct 2017 19:33
- Family Historian: V7
- Location: South Cheshire, UK
Re: Read the Citation Window by plugin?
I found another gotcha that tripped me up until I figured out what was happening.
You define a multi-line string with something like
S1 = 'Line 1\nLine 2\nLine 3'
This displays each line on a new line, with no carriage return after the final line, so no blank lines in reports - all good.
Copy that string into the Windows clipboard, and bring it back with
S2 = fhGetClipboardData("UNICODE TEXT")
The two lines print exactly the same in the debugger, but S1 == S2 evaluates as false, so no match is reported.
It turns out that Windows is adding an explicit \r to the end of each line for its normal 2 byte line ending, so S2 actually has the value 'Line 1\r\nLine 2\r\nLine 3.
It's easy enough to strip out the \r characters with S2 = S2:gsub('\r', ''), and probably obvious in hindsight, but I've never needed to worry about the \r character up until now.
You define a multi-line string with something like
S1 = 'Line 1\nLine 2\nLine 3'
This displays each line on a new line, with no carriage return after the final line, so no blank lines in reports - all good.
Copy that string into the Windows clipboard, and bring it back with
S2 = fhGetClipboardData("UNICODE TEXT")
The two lines print exactly the same in the debugger, but S1 == S2 evaluates as false, so no match is reported.
It turns out that Windows is adding an explicit \r to the end of each line for its normal 2 byte line ending, so S2 actually has the value 'Line 1\r\nLine 2\r\nLine 3.
It's easy enough to strip out the \r characters with S2 = S2:gsub('\r', ''), and probably obvious in hindsight, but I've never needed to worry about the \r character up until now.
Mark Draper