Page 1 of 2

Possible enhancement for Search and Replace

Posted: 09 Mar 2013 03:28
by BillH
Jane,

Would it be possible to add the record name (individual name, place name, etc) to the top of the window? In this way we could know what record we are looking at which would help determine if we want to make the change or not on a particular record.

Thanks,

Bill

ID:6823

Possible enhancement for Search and Replace

Posted: 09 Mar 2013 08:59
by Jane
I'll have a look the Record is not a problem, but it could get quite complicated to look up a place, as text can be found on any level in any record format.

Possible enhancement for Search and Replace

Posted: 09 Mar 2013 12:05
by tatewise
Jane, this may be an example of where it would be useful to have an FH API Function that translates a Pointer into a Data Reference string (or similar) that LUA can manipulate.

See my thread Save/Load FH Item Pointer.

Possible enhancement for Search and Replace

Posted: 09 Mar 2013 17:33
by Jane
I think there is a code spinet which does that, it just needs enhancing to do the indexes, it's easy enough to move back up the tree, the problem is for me to work out a good global display option.

Possible enhancement for Search and Replace

Posted: 09 Mar 2013 18:01
by tatewise
I'll have a look at the Build Data Reference Function (code spinet) [sic]!
See if I can incorporate instance indexes.

Possible enhancement for Search and Replace

Posted: 10 Mar 2013 13:37
by tatewise
Jane, I have modified the Code Snippet function to cope with instance indexes, and written a complementary function to convert the Data Ref back to a Pointer.
Could you review and test them please, before I add them to Code Snippet library?

Code: Select all

--[[
@function:      TblDataRef
@description:   Get Full Data Reference for Pointer
@parameters:      Item Pointer
@returns:         Table of RecId, RecTag, DataRef
@requires:      None
]]

function TblDataRef(ptrRef)

   local tblRef = { RecId=0, RecTag='', DataRef='' }

   -- getDataRef() is called recursively per level of the Data Ref
   -- ptrRef points to the upper Date Ref levels yet to be analysed
   -- strRef compiles the lower Data Ref levels including instances

   local function getDataRef(ptrRef,strRef)
      local ptrTag = ptrRef:Clone()
      local strTag = fhGetTag(ptrTag)            -- Current level Tag
      ptrTag:MoveToParentItem(ptrTag)
      if ptrTag:IsNotNull() then               -- Parent level exists
         local intSib = 1
         local ptrSib = ptrRef:Clone()         -- Pointer to siblings with same Tag
         ptrSib:MovePrev('SAME_TAG')
         while ptrSib:IsNotNull() do            -- Count previous siblings with same Tag
            intSib = intSib + 1
            ptrSib:MovePrev('SAME_TAG')
         end
         if intSib > 1 then    strTag = strTag..'['..intSib..']' end
         getDataRef(ptrTag,'.'..strTag..strRef)   -- Now analyse the parent level
      else
         tblRef.RecId = fhGetRecordId(ptrRef)   -- Record level reached, so set table data fields
         tblRef.RecTag = strTag
         tblRef.DataRef = strTag..strRef
         if not fhIsValidDataRef(tblRef.DataRef) then print(tblRef.DataRef..' is Invalid') end
      end
   end -- local function getDataRef

   if type(ptrRef) == 'userdata' then getDataRef(ptrRef,'') end

   return tblRef

end -- function TblDataRef

--[[
@function:      PtrDataRef
@description:   Get Pointer for Full Data Reference
@parameters:      Table of RecId, RecTag, DataRef
@returns:         Item Pointer
@requires:      None
]]

function PtrDataRef(tblRef)
   local tblRef = tblRef or {}               -- Ensure table and its fields exist
   local intId  = tblRef.RecId or 0
   local strTag = tblRef.RecTag or ''
   local strRef = tblRef.DataRef or ''
   local ptrRef = fhNewItemPtr()
   ptrRef:MoveToRecordById(strTag,intId)      -- Lookup the Record by Id
   ptrRef:MoveTo(ptrRef,strRef)               -- Move to the Data Ref
   return ptrRef
end -- function PtrDataRef

-- Example of Use
local ptrRec = fhNewItemPtr()
local ptrRef = fhNewItemPtr()
local tblRef = {}
for intRec, strRec in ipairs({'INDI','FAM','NOTE','SOUR','REPO','SUBR','SUBM','OBJE'}) do
   ptrRec:MoveToFirstRecord(strRec)
   ptrRef = ptrRec:Clone()
   while ptrRef:IsNotNull() do
      tblRef = TblDataRef(ptrRef)
      ptrRef = PtrDataRef(tblRef)
      if ptrRef:IsNull() then
         print(tblRef.DataRef..'          Is Null')
      else
         print(tblRef.DataRef..'          '..fhGetDisplayText(ptrRef))
      end
      ptrRef:MoveNextSpecial()
      fhSleep(2,1)
   end
end

Possible enhancement for Search and Replace

Posted: 11 Mar 2013 16:55
by Jane
Mike I think that's OK. Obviously if someone edits the data between saving and loading the references, there could be a problem.


Bill, I have modified the Search & Replace routine to give more information on the Replace Prompt.

https://www.dropbox.com/s/q30ry7741zrx5 ... ace.fh_lua

Can you give it a try before I publish it to the store.

Thanks

Possible enhancement for Search and Replace

Posted: 11 Mar 2013 22:54
by tatewise
Jane, would it be OK to simply replace the existing Build Data Reference Function (code snippet) with both my new functions?

Possible enhancement for Search and Replace

Posted: 11 Mar 2013 23:12
by BillH
Jane,

That looks great. That will really help.

Thanks!

Bill

Possible enhancement for Search and Replace

Posted: 12 Mar 2013 09:07
by Jane
tatewise said:
Jane, would it be OK to simply replace the existing Build Data Reference Function (code snippet) with both my new functions?
I was thinking about the return from TblDataRef and wonder if it would be more 'Lua' to return the three values rather than a table with them in, that way it could be called BuildDataRef and return the 3 values as ref, recId, tag

That way it would be a direct exchange for the current one.

With the extra parameters available if needed

Possible enhancement for Search and Replace

Posted: 12 Mar 2013 12:58
by tatewise
Or we could redefine BuildDR as

Code: Select all

function BuildDR(ptrRef)
   local tblRef = TblDataRef(ptrRef) 
   return tblRef.DataRef, tblRef.RecTag, tblRef.RecId
end
and add both my new functions.

Otherwise, if we adopt your proposal, would the complementary function become PtrDataRef(strDataRef,strRecTag,intRecId) and are you happy with that name?

Possible enhancement for Search and Replace

Posted: 12 Mar 2013 14:23
by Jane
I am happy with the name, but wondered if it might be more fh function like as

getPtrFromReference ?

Possible enhancement for Search and Replace

Posted: 12 Mar 2013 15:07
by tatewise
OK, the existing FH API functions are:
ptr = fhGetItemPtr(...)
ptr = fhNewItemPtr()
so perhaps a better matching name is:
ptr = GetDataRefPtr(strDataRef,strRecTag,intRecId)

Even better would be a method:
ptr:MoveToDataRef(strDataRef,strRecTag,intRecId)
but I have not been able to work out how to do that.

Re: Possible enhancement for Search and Replace

Posted: 20 Oct 2013 10:51
by johnmorrisoniom
Is it possible for this plug to search and replace dates in source citations.

Mike's statistics plugin has highlighted a lot of invalid dates have somehow crept into my file (over 200 31 Nov 2008) I don't like have to use notepad to do the job.

Re: Possible enhancement for Search and Replace

Posted: 20 Oct 2013 11:21
by Jane
It's not idea to replace dates using the Text search and replace, but a Date search and replace should be possible.

There is already a plugin which searches and returns a result set
http://www.family-historian.co.uk/plugi ... try?id=289

Can you take a look and see if it can find your problem dates.

If so it should be possible to produce a replacing version.

Re: Possible enhancement for Search and Replace

Posted: 20 Oct 2013 15:36
by johnmorrisoniom
I have already tried that plugin as well. Neither will deal with a source citation date. (Not the date of the fact itself)

Re: Possible enhancement for Search and Replace

Posted: 20 Oct 2013 19:03
by tatewise
I have written a quick and dirty update to Search and Replace available from my SkyDrive Search and Replace MBT.
Double-click on popup to download and install.

It should cope with most Dates in any field, just leave the Dates option ticked to be on the safe side.

[EDIT]
I believe this version is now quite robust, and copes with any option settings, and works for any date formats, and validates the replacement date with optional override.

Re: Possible enhancement for Search and Replace

Posted: 20 Oct 2013 19:39
by Jane
Strange I have just put in a citation date of 2018 and the search found the citation date fine.

Are the dates you are looking for actually date phrases?

Re: Possible enhancement for Search and Replace

Posted: 20 Oct 2013 19:59
by tatewise
John said
Mike's statistics plugin has highlighted a lot of invalid dates
So, they can't be Date Phrases if my Show Project Statistics Plugin reported them as invalid Dates.

I have just tried the Plugin with a Citation Entry Date of 32 November 2000.
It would only find this date if I entered just the year 2000, but not if I entered November 2000 or 32 November 2000.
It did find such full dates in Fact Date fields, so something about Citation Entry Dates is not working.

The explanation is that this Plugin does not recognise invalid Dates and that is exactly what John is looking for!!
If I change the line:

Code: Select all

local days = {39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39, 39}
then it finds the invalid Dates OK.

Re: Possible enhancement for Search and Replace

Posted: 21 Oct 2013 06:19
by johnmorrisoniom
I had a similar date problem with the Change any fact plugin.

If i use the exact date of the fact I want to change, no facts are found. But putting in just the year does work.

Likewise with the place match option. If I put in just "Manchester", then no matches are found. The field has to be input as "Manchester, Lancashire, England" to be an exact match with my file

Re: Possible enhancement for Search and Replace

Posted: 21 Oct 2013 09:39
by tatewise
Replies to this last posting continue in thread Change Any Fact Tag filters (10861)...

Re: Possible enhancement for Search and Replace

Posted: 21 Oct 2013 12:02
by tatewise
A revised update to Search and Replace is available from my SkyDrive Search and Replace MBT.
Double-click on popup to download and install.

It should cope with dates in any field.

I believe this version is now quite robust, copes with any option settings, works for any date formats, and validates the replacement date with optional override.

Re: Possible enhancement for Search and Replace

Posted: 22 Oct 2013 16:39
by tatewise
John has successfully used this enhanced Plugin version, and I have run a few tests.

Jane, perhaps you could also give it the once over.
There are very few actual changes, and I have clearly marked them.
If all OK, perhaps you could put it in the Plugin Store.

Re: Possible enhancement for Search and Replace

Posted: 24 Oct 2013 11:50
by Jane
Hi Mike,

A couple of comments.

1. If you do something silly like swap JUN for HLP and click do all, you then can't abort the process when the invalid date field errors come up.

2. I have noticed the source is now double spaced in some places, if you look in an hex editor it has two line feeds followed by a carriage return. Are you using a text editor which is causing this as I can't get them in the Plugin editor.

Re: Possible enhancement for Search and Replace

Posted: 24 Oct 2013 13:46
by tatewise
1. Good point - Have changed the buttons to Yes No Cancel and included the context Details in message.

2. I am using the standard FH Plugins editor, but I tend to use tab chars a lot to indent code instead of space chars, so perhaps SkyDrive is wrapping the text. I have now converted all tabs back to spaces.

I have tried SkyDrive downloads and nothing gets changed for me.

Checked text using Notepad++ in Hex.
I could not find two LF (0A) and one CR (0D), but there are plenty of two CR (0D) and one LF (0A), and only in your original code, as my newly inserted code only appears to have one CR (0D) and one LF (0A).
All my own Plugins have one CR (0D) and one LF (0A).
Your original 'Search and Replace' appears to have two CR (0D) and one LF (0A) everywhere.
So not sure what is happening there.