Handle not found (but it exists)

Gramps 5.1.3
MacOS 11.1

Copying (CMD-C) a source to the clipboard generates an unhandled exception error. The last line states a handle was not found. I was able to find references to the handle and the handle itself in a non-compressed export.

Any guidance on how to resolve the issue?

XML file snippets:

<citation handle="_e4df43aeacb76dc49dbc7d376a6" change="1597359571" id="C0378">
  <page>L ... a</page>
  <noteref hlink="_e4e0cb2cad4388cc30c15701960"/>
  <noteref hlink="_e4e0a4feeee2bb65c304737b6a6"/>
  <noteref hlink="_e464be1b88767acbf48cf78630a"/>
  <objref hlink="_e4df438d9b35c00ee98abc671fc"/>
  <objref hlink="_e4df4399a996b5faeb6818ea47"/>
  **<sourceref hlink="_e48f1a19962182181fc117a233f"/>**

**<source handle="_e48f1a19962182181fc117a233f" change="1610806523" id="S0080">**
  <stitle>Archdiocese of Seattle Associated Catholic Cemeteries</stitle>
  <sabbrev>Deaths US WA</sabbrev>
  <noteref hlink="_ea6735df72e5f13c2462adc6cfb"/>
  <reporef hlink="_e48f1c7ff123032e7e04662c3b2" medium="Book"/>

Error trace:

35572494: ERROR: grampsapp.py: line 156: Unhandled exception
Traceback (most recent call last):
File “/Applications/Gramps.app/Contents/Resources/lib/python3.8/site-packages/gramps/gui/views/navigationview.py”, line 476, in key_press_handler
File “/Applications/Gramps.app/Contents/Resources/lib/python3.8/site-packages/gramps/gui/views/navigationview.py”, line 491, in call_copy
return self.copy_to_clipboard(nav_type, handles)
File “/Applications/Gramps.app/Contents/Resources/lib/python3.8/site-packages/gramps/gui/views/pageview.py”, line 289, in copy_to_clipboard
File “/Applications/Gramps.app/Contents/Resources/lib/python3.8/site-packages/gramps/gui/clipboard.py”, line 1242, in object_drag_data_received
_ob = wrapper_class(sel_data)
File “/Applications/Gramps.app/Contents/Resources/lib/python3.8/site-packages/gramps/gui/clipboard.py”, line 470, in init
File “/Applications/Gramps.app/Contents/Resources/lib/python3.8/site-packages/gramps/gui/clipboard.py”, line 474, in refresh
citation = clipdb.get_citation_from_handle(self._handle)
File “/Applications/Gramps.app/Contents/Resources/lib/python3.8/site-packages/gramps/gen/db/generic.py”, line 1288, in get_citation_from_handle
return self._get_from_handle(CITATION_KEY, Citation, handle)
File “/Applications/Gramps.app/Contents/Resources/lib/python3.8/site-packages/gramps/gen/db/generic.py”, line 1270, in _get_from_handle
raise HandleError(‘Handle %s not found’ % handle)
gramps.gen.errors.HandleError: Handle e48f1a19962182181fc117a233f not found

Sometimes Gramps seems to forget underscore before the handle. Like in your error report.

I tried changing the handle from “_e48f1a19962182181fc117a233f” to “_test_handle” in the backup file (7 instances), re-importing and got “gramps.gen.errors.HandleError: Handle testhandle not found”. Interesting that the internal underscore was deleted too.

Then I replaced “_test_handle” with “testhandle” and got the same error, “gramps.gen.errors.HandleError: Handle testhandle not found”. It does not seem to mater if there is an underscore in the handle ID.

Is this an error in Gramps or an error in the data file, how can I determine which?

I am beginning to think this is a Gramps error. Perhaps Gramps is searching through the citations when I am trying to copy a source to the clipboard.

The problem happens in the “Citation Tree” view of sources when trying to copy a source. No problem copying a citation in the that view. No matter which source I select (I tried 3 or 4), the error happens. And the handle ID is the same as the source I’m trying to copy.

In “Sources” view, errors are not generated when copying a source to the clipboard.

There is a bit of inconsistency in the Clipboarding functions.

Drag’n’drop seems to operate a bit differently than than the keybinding.

You’ll notice that Clipboarding from some places will create a ‘Reference To’ the Object while others will just show the Object. (The ‘Reference to’ clipboard objects can only be applied in some places while the standard objects have no such limits.) It would be nice is ‘Reference To’ links would be automatically converted to the more capable version.

selected Text objects are moved (cut&pasted) to the clipboard but cloned (copy&pasted) when dragged directly from one field to another.

Another irritating behavior is when you drag a text object from the clipboard to a text field. If you drag across the tab bar, the active tab changes. And if you re-activate the tab with the original field, the Insertion Point changes to a select all of text. So you can only overwrite the text, not insert.

The main clipboard window is supposed to be on the top of the Gramps layer of windows. But sometimes is is pushed down, disappears occasionally when the Gramps application layer is not selected, or even draws half the dialog if is stafford 2 display devices.

And the collection clipboards behave differently again. When I drag’n’drop extended selections to the Collections Clipboards, 2 copies of each object will appears. This is content that has at ‘uniqueness’ check when on the main Gramps clipboard. Only one incidence may occur on that list.

And there are times the OS clipboard fights with the 2 varieties of Gramps clipboards too.

More than likely, these inconsistencies (and occasional odd behavior) will persist until it aggravates someone enough that they become compelled to consolidate & harmonize the feature. (Which is not likely to happen soon. It will be a lot of coding & testing for an improvement that few will notice or appreciate.)



The sometimes unexpected behavior of the clipboard is fine, the programmers get to decide how the software works. I have no complaints about that. But this was the first time using the clipboard that an error message popped up and made me think my database was corrupted. I spent a day trying to figure out what was wrong with the database until stumbling on the source/citation difference in the Citation Tree view. And I am only 95% confident it is a programming issue.

I would expect, even in a volunteer development program, that the developers would want to gracefully deal with errors instead of having an unhandled error window pop up.

I will file a bug report.


My point was too abstract.

Although the bug seems relatively straight-forward, the complex implementation of Clipboards means your bug will need a VERY rigorous reproduction. Or the developers may not be able to find the offending subroutine.

Moreover, it may exist from some object source tabs but not others.

I had not thought about other tabs. The only other tab that has a view where items are organized by different types is the people tab with the Grouped People view. But that is a last name type grouping, and not a real object. CMD-C when a family is selected seems to be ignored by the clipboard.

Bug report: 0012170: Unhandled exception using clipboard from the Citation View in Sources - Gramps - Bugtracker – Free Genealogy Software

In the bug report #12170, this is another problem. You are on a citation view and not on a source view.
If you try to copy a citation, it works. If you try to copy a source in the clipboard, you get a “Handle not found” because you try to get a citation from a source handle.
If you want to copy the source, you need to drag the source into the clipboard.

In this case, this is very hard to solve.

1 Like

It is the same issue, I started the Discourse discussion and then created the bug report. Both state the problem happens when Sources are displayed in Citation Tree mode, and there are no problems when Sources are displayed in Sources mode (the display modes have confusing names but that is what tool tips displays when I hover over the buttons in the tool bar, I am using an English installation of Gramps). The initial part of the Discourse discussion was vague about when the problem happened because I had not isolated it to copying sources and not citations.

I take your word that this very hard to solve. Is there any way to trap and ignore the error and just do nothing? That’s what happens (nothing) when a last name is highlighted on the People display in Grouped People display mode and CMD-C is pressed. Then I would not get scared that my database is corrupted.

By the way, I appreciate the effort you put into developing Gramps. Thank you.

There’s definitely interest in isolating the problem. You’re seeing a generic error handler message. Which indicates the clipboard programmers hadn’t anticipated the action you are doing.

So defining the exact step-by-step task sequence & intention will help. It saves the time that Developers would spend guessing the steps to reproduce.

You’re on Mac. I will try to replicate the process using Windows & the Example.gramps tree. Then, when isolated to the minimum step, amend the report with a reproduction process.

Regarding the Views & modes… The Views are for displaying Categories of Records. The modes break down different ways of navigating those records. Some Views have only have one mode so far. (Like the Dashboard View.) Most views navigating the records via a table have grouped & flat list modes.

The Visual Guide to the Gramps Interface will introduce you to the terminology of the interface. Using the same vocabulary can save time & confusion.

First try to solve that: See PR: #1175

1 Like

CMD-C is not one of the Mac Keybindings in Gramps.

I am on Win10 and Gramps 5.1.3 so cannot say what is happening on a Mac but…

If I am in a list view, Ctrl+C opens the clipboard but does not copy anything to the clipboard. Ctrl+B is the Gramps keybinding and does the same. If I am on text within a field, the Ctrl+C copies the text to the OS clipboard.

From within the Citation Tree view, I can drag-n-drop a Source to the clipboard, I can also d-n-d a Citation to the clipboard. I can then use these entries on the clipboard to add a Source/Citation to another object. Either the full citation or the source of a new citation.


adamvazquez reported on the bug report that the problem was duplicated on windows. And I added step-by-step instruction there also.

Thanks for the link to the screen parts.

1 Like

Thank you SNoiraud.

Do I replace the clipboard.py in my installation to check out the fix? Obviously in a copy of the installation and on a test database, not on my real data.


I’d argue that it is not a listed Mac keybinding. CMD-C opens the clipboard (if closed) and copies in the currently selected object. CMD-B opens the clipboard.

CMD-C only works in a few areas, such as the Display Area on the main screen.

1 Like

There are 3 different view Categories with Grouped/Tree listings:

  1. People - Placeholder listing with surname (no handle)
  2. Places - a place listing with enclosed sublistings of the same object type (handle)
  3. Sources - a source listing with referenced sublistings of the different (citation) object type (handle)

Selecting an object and triggering a Copy behaves differently in each View category:

  1. For People, both drag’n’drop and Copy to clipboard keybinding action are suppressed
  2. For Places, both drag’n’drop and Copy to clipboard keybinding action add the Place to the Clipboard
  3. For Sources, drag’n’drop adds the Source to the Clipboard, Copy to clipboard keybinding action generates an error

The suppression in People makes contextual sense. There is nothing that can be clipboarded.
The Clipboarding success in the Places also makes sense contextually.

But the error (or the action suppression for the new patch) for the Copy keybinding in Sources does not make sense since Drag’n’drop works.

A question asked earlier was why someone would clipboard a Source instead of a Citation. This was not answered. There is an added functionality for Sources in the Clipboard… it creates a new Citation opportunity where the Source is already defined. All the user has to do is add a date and/or page reference.

I use this extensively for my Hometown newspapers while filing Obituaries. And the same with County history books.

With FamilySearch/WikiTree/FindAGrave as a clipboarded Source, I add the profile Reference ID as the page number and the date is the date the website was accessed.

So, if I do a lookup in my hometown public library’s periodical index for Surname,Given listings containing “Cullough”,“Rob” it returns the following list of New Castle New newspaper articles:

Article id Last Name First Name Spouse Parent Newspaper Page Date of Marriage Announcement Date of Death Announcement
111548 McCullough Robert D., Sr. Marguerite McCullough NCN 5 02-22-1999
143844 McCullough Robert Dale Karin Marie Nussbaum NCN 10 06-15-1979
191044 McCullough Robert O. Elsie Beals ncn 2 12-30-1958
191047 McCullough Robert Daniel marguerite Thompson ncn 11 1-23-1958
229500 McCullough Robert F. Arsenath McCullough NCN 9 9-8-1938
229501 McCullough Robert Orr Elsie E. Beals NCN 3 9-19-1934
319992 McCullough Robert J. Frances D. Alexander NCN A-3 3-10-2010
323310 McCullough Robert L. Elizabeth McCullough NCN 7 3-3-1916
I can clipboard my "Newspaper; New Castle News" source, search my People for the same Surname & Given & drag those sources to each of those people. When the new Citation dialog pops, I add the page & publication date.

Then I can go to the Citations, sort on date and then filter for “Newspaper; New Castle News” title. Any duplicate page numbers for the same date can be merged. When apply my “Citations with <count = ‘<1’ > media” custom filter, Gramps gives me a working list of Newspaper page scans that need to be acquired from the Public Library.

(I’ve learned to acquire full page scans for Newspapers instead of individual articles. This tends to have a header with periodical name, date, day of week & page number. And If I have a scan for that page logged, I can be certain that I won’t need to find it on Newspapers.com again.)

This is a programming problem. In the bug case, we are in a citation view, so only citations are selected with shortcuts. If you use shortcuts on the source, we use the source handle to search a citation.
You always got a Handle exception. If we want to do what you think, we need to create a new class including source and citation. Too complex for a bug. In this case, it’s a feature request.

False. You can copy persons using shortcuts but not grouped persons. it makes sense.
we should be able to drag persons.


I was one speaking only of the Surname group line of the People view’s Grouped mode.

You can certainly copy the people (with an extended or individual selection).

But that expandable/collapsible surname line isn’t a real record object… so the copy is correctly suppressed on it.

Actually… in the bug case, we are in the Source view but the Citation Tree mode. (Which Link correctly pointed out is confusing. That type of Tree mode would make more sense if it was a mode under the Citations category view.) I would’ve expected Sources to be grouped by Repository or (perhaps in the future) by the library Type of material: Internet, Book, video, periodical, etc.

Unlike the People view’s Grouped/Tree mode, the the Source view’s Citation Tree mode has valid object on the expandable/collapsible row too.