Gramps 5.2.2/5.2.3 on Windows 10. When trying to (for instance) adding an existing place to an entry, clicking on the ‘Select an existing place’ icon causes the entire program to ‘freeze’ and become unresponsive. The only option is to exit using Task Manager, which requires the database to be unlocked when the program is restarted. Opening the Places window shows that the Places database table is accessible. Is there any way to fix or trouble-shoot this occurrence?
Start by creating loading Example.gramps and testing if the same issue happens.
Also mention how many places you have and if you are using the “Place tree view” or “Place view”?
Another thing to try is install the portable version of Gramps and import your family tree and see if the same issue occurs?
Thanks for the input. I have loaded the example database, and exactly the same problem happens, and using the calendar for date entry rather than keyboard entry does the same thing. The places window is set to Place Tree. 650 places in the list. Trying the portable version might take a little longer while I work out what is involved.
The following was unrelated to this issue.
I had a similar problem with my Place tree and I believe it was related to having some circular references in the hierarchy.
There is a hack to change the Place Tree selector to a ‘flat’ rather than a ‘hierarchical’ mode. (Thanks again to @DaveSch !) Would you be willing to try that?
Note that the symptom went away when I migrated from Windows to Linux with the same data.
The portable version of Gramps ‘starts’ and appears on the Taskbar, but cannot be accessed or terminated. Have to use Task Manager to shut it down.
I seem to have some sort of general problem with using intermediate buttons to access functionality. For instance, if I try to make a filter, I can create and name a filter, but, if I try to add a rule, the filter interface just turns pale, and you cannot interact further. At least, in this instance the whole application does not freeze, and you can back out to access other things.
OK. I begin to recognize your issue. I think that there is a modal dialog appearing offscreen.
When Gramps gets to the place where the text “greys out”, try pressing the Esc key instead of using task manager to exit. If control returns to Gramps, then dialog positions being saved in off-screen areas is the problem. You will want to close Gramps and rename the gramps.ini file in the Gramps User Directory.
Thanks. ESC does bring it back. Just rename the file? Nothing else?
OK. The Wiki is telling me that the user directory should be in AppData/ Local for Gramps 5.2 and above, but mine seems to be in Roaming, and I can’t find a .ini file.
A big thank you for the hint about dialog positions. At one stage, but never with Gramps, I had a dual screen set-up. For some reason, Gramps seems to have decided to place the various dialogs on the other screen. Is there any setting to tell it to only use the current screen?
1 Like
@harryb skip the following gramps.ini troubleshooting. It is often the cause with these symptoms. But it is a red herring for your problem
MS Windows users who upgraded Gramps (having used 5.1 and earlier) will continue to use %AppData% but fresh installs will use %LocalAppData%. It is a bit confusing. (There’s another thread that discusses a way to have Gramps report on where is stores various details. This ‘Gramps constant’ for the Gramps User Directory is USER_DATA. )
Look in the Gramps User Directory for gramps52/gramps.ini
Back with version 5.1.2, this bug was reported and fixed. See bug report 11831
@prculley did a patch for the a MS Windows port that recognized when the virtual screen size (supporting multiple screens or screen configuration changes) had changed. It would recognize when dialogs were saved in off-screen locations and ignore those preferences. It seems like you’ve found a way the break his fix.
@harryb skip the following gramps.ini troubleshooting. It is often the cause with these symptoms. But it is a red herring for your problem
WARNING
Renaming the gramps.ini is a temporary diagnostic method and is intended to help isolate a problem. (If the renaming changes the problematic behavior, then the necessary solution will be to revert the renaming test and manually clean the gramps.ini file using a text editor.) Since this .ini settings file contains vital customizations that include the “database path”, having Gramps regenerate a missing gramps.ini file can cause unintended consequences.
Also, if a previous version of Gramps is still installed, the regeration does not restore settings to a standard baseline. Instead, Gramps references the settings from that PREVIOUS version to generate the missing file!
Well, the problem IS with dialogs appearing off-screen due a changed screen configuration. But one piece of information tells us that the fault cannot be resolved by tweaking Gramps or its gramps.ini file.
The clue is that it is ALSO OCURRING for the Gramps Portable startup. And THAT chooses the dialog position from what the OS is calling the primary screen. But that screen apparently isn’t connected anymore.
(I wonder if you don’t have your computer set to have a bluetooth connection to your TV so you could watch a movie?)
So the objective is to fix your OS’ confusion about its external monitors, virtual screen layout and the primary screen selection.
The easiest way is probably to connect a 2nd monitor. Then set the multiple screen configuration to MIRROR content to all connected screens instead of allowing different content on different screens.
But make certain that you’re not still ‘casting’ to another display device wirelessly. You could be “screen mirroring” more than is wise.
Thank you emyoulation. The problem was in the system setup. For some reason (maybe related to a windows update?), what had been the secondary screen was allocated as the primary screen. I had only used the ‘secondary’ screen on a few occasions when I was transcribing information so no real idea how it came to be switched. Thinking back it probably happened some time ago because one reason that I moved to (firstly 5.2.2) was that the version I had been using (v5.1.?) ‘stopped’ working and I thought the new version might fix it. Ditto for moving to 5.2.3. The upgrading path explains why the files are still in roaming, as pointed out earlier. Thanks again everybody.
1 Like
Thank you for confirming a final resolution.
It both 1) reassures volunteers that their efforts have had some value to someone, and 2) helps others having similar problems find the most promising topics to review.