Ghidra: Search All results goes behind main window, filter quality is poor

[mick-p1982]

Is your feature request related to a problem? Please describe.

Working with Search All results is difficult since clicking on Ghidra hides this window in the current release. Separate issue, when I search for "operands" and "data" I get many false results to wade through that Ghidra must know are irrelevant because it produces summary information in the results window. Like if I search for 0x80 Ghidra lists 0x8000 too, producing lots of noise that it has enough information to rule out.

EDITED: Just as an aside, a powerful feature I use with my own techniques is to search for a range of values. Guidra can only search for a single value, so it can't find addresses that are distributed over a record in a data structure.

[ryanmkurtz]

Did you know you can dock the search results window?

[ryanmkurtz]

Also, do you know about the Search for Scalars feature? You can specify a range there.

[mick-p1982]

No I didn't. Thank you. I think some buttons in the dock header to "stay on top" (if not desired) and to "dock" would help to avoid this kind of feedback in the future.

I think because using the search results necessarily requires clicking back and forth between the results and the main window to see the results this window should stay in front, and it's very useful to undock to be able to increase the size of the view of your results.

[ryanmkurtz]

Just for some background, the original GUI was designed for a big multi-monitor setup, which is probably why no one ever saw the need for things like stay on top. Now you have people running Ghidra on laptops and obvious problems are popping up like the splash screen or import result window not fitting on my macbook, or #566.

You may want to retitle this issue to something like "Docking windows should have option to stay-on-top"

[mick-p1982]

For the record, Search for Scalars didn't help me because it is locked into decimal numbers (dec) and even after converting hex to decimal it didn't find the numbers, so it's not clear where it's looking for them? I was expecting it to look in instruction operands.

Please feel free to tailor the title, etc. I think there's a lot of practical usability issues here.

big multi-monitor setup

I used to use one of those back when monitors were square. It seems impractical/ostentatious with widescreen displays.

[ryanmkurtz]

Are you running a Ghidra release or out of master? If you are running a release, you might be running into #1558. Try searching for scalars <=127. Hex or decimal should both work the same.

[emteere]

Also the Edit->ToolOptions... Tool->DockingWindowsOnTop might help you out.

[ryanmkurtz]

Also the Edit->ToolOptions... Tool->DockingWindowsOnTop might help you out.

Nice, didn't know about that. I think that addresses this issue nicely.

[mick-p1982]

Also the Edit->ToolOptions... Tool->DockingWindowsOnTop might help you out.

One caveat is doing this in the main Ghidra menu/project window either has no effect on the main CodeBrowser window or it applies to future project "imports" only.

This is a help but it's not a solution because it relies on people finding this setting which should probably be the default setting. Also DockableWindowsOnTop is better wording. Since there is an extra title bar in the windows there should be either a button to control this or a context-menu item, and a context-menu could expose the global setting. From a design POV my goal is always to make it so that issues aren't reported in the first place because usability features are visible at the point where the usability issue arises.

[mick-p1982]

Are you running a Ghidra release or out of master? If you are running a release, you might be running into #1558. Try searching for scalars <=127. Hex or decimal should both work the same.

No, I'm using the current stable release. It says "dec" in the input box, so I assume it doesn't understand hexadecimal. The last test I did was with 32-bit values, looking for instruction operands. I appreciate knowing there is work in the pipe on this.

[ryanmkurtz]

It says "dec" in the input box, so I assume it doesn't understand hexadecimal.

If you start your scalar with a 0x, that label should change to "hex".

[mick-p1982]

It says "dec" in the input box, so I assume it doesn't understand hexadecimal.

If you start your scalar with a 0x, that label should change to "hex".

It works! I guess it hadn't occurred to me to try that. The little "dec" emblem suggests you can change the mode by clicking on it but it's disabled, suggesting there is only one mode. Because it's called "Scalars" it suggests it's geared toward numerical values, and anyway I think range functionality ought to be in the regular search too.

I don't want to create a bunch of nitpicking issues, but I hope someone invested in the project reads this issue including the accessory topics it's raised.

One last thing, is it doesn't help that the "modal" Scalars window always comes preloaded with -2147483647 and 2147483647 because nobody wants to search for that, and it has to be deleted first before anything can be inputted, and this also contributes to the idea that "dec" is locked in. If the boxes were empty and "dec" appeared after typing then it would be interpreted as evaluating the input and not a mode. Plus, when selecting -2147483647 the minus sign isn't selected, so it requires extra work to press Backspace twice before you can type instead of just beginning typing.

[ryanmkurtz]

I wouldn't call it nitpicking...you are simply mickpicking :)

[mick-p1982]

I'll take that as a compliment :)