Dear Sir/Madam,
The search dialog window doesn't show up after upgrade from 5.0.99.0 to 5.1.99.0. Same holds true for 5.2.1.0. Same holds true for complete reinstallation. Downgrade resolves the issue.
Executing environment:
- OS: Windows 7 Enterprise
- OS Version: 6.1.7601 Service Pack 1 Build 7601
- Java: 1.7.0_45
- jEdit modules: QuickNotepad (5.0); TextTools (1.15)
I would be grateful if you could fix this.
Which search action are you invoking? Search in directory? Or "Find..." or what?
Is this related to your keyboard shortcuts changing to something else?
I need steps to reproduce this.
Tried both "Find ..." menu item and CTRL+F
tested with windows 7 professional. Unable to reproduce your issue with metal, nimbus, windows standard or windows classic look and feel. Can you reproduce this when running jEdit.exe with -noplugins or -nosettings?
It works for me.
Neither -noplugins nor -nosettings option works for me. But downgrade to 5.0.99.0 resolves the issue. I'm using windows classic theme. Can you suggest some other way to diagnose?
Tried fresh install on my home PC. Bug persists.
Differences in operating environment:
OS: Windows 7 Home Premium x64
you are saying with jedit -nosettings -noplugins, you are still unable to see the search dialog?
And you also have this issue with the latest daily build? That is so strange.
Because when I try that, I see the dialog centered nicely on top of the view.
still unable to reproduce.
Please try this:
1. Find out the path to Your settings directory: In jEdit, go to "Utilities -> Settings Directory" - the first item of the submenu is the path.
2. Exit jEdit
3. Ensure that no instance of jEdit (even no unvisible jedit server) is running. The safest method, I think, is to open task manager and kill all Java processes if any.
4. Rename the settings directory (so, jedit cannot find it anymore)
5. Start jEdit and the search dialog
6. Tell us that You see the search dialog :-)
Alan, Robert, switch to English language resolves the issue. The bug should be reproducible when language is set to Russian.
Robert, the proposed procedure didn't resolve the issue when language is set to Russian.
Confirmed.
Fixed in rev 23392