Prioritize used enums in selection dialog
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- cpp
- Domain
- reverse-engineering
Research direction
No source file, test, or entry point is named. Start by locating the selection dialog implementation and determine how enum candidates are collected and ordered; done should make previously used enums easier to select while preserving a sensible ordering for unused enums.
Written by the indexing model from the issue text.
Description
What is the feature you'd like to have?
Please provide a clear and concise description of what you want.
With type libraries loaded, there can be a large number of enum types in a bndb. For example:
This UI is great, no problem. I select _IRP_MJ which is the correct one for this call site. Now, I go to the next use in this function:
This is reusing _IRP_MJ, but the UI does not prioritize recently used (or used at all) enums. I would like _IRP_MJ to be prioritized in some fashion to make it easier to select the second time.
I don't have any preferences as to how this is implemented.
Is your feature request related to a problem?
If applicable, please provide a clear and concise description of what the problem is.
Are any alternative solutions acceptable?
Please provide a clear and concise description of any alternative solutions or features you've considered.
Additional Information:
Please add any other context or screenshots that would help us understand your feature request here.
- Dominant language
- C++
- Stars
- 1.3k
- Forks
- 298
- Avg merge
- 5d 5h
- Merged PRs (30d)
- 19
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from Vector35/binaryninja-api
-
Difficulty 1/5 1-3 hours Newbie friendliness 88/100
Vector35/binaryninja-api#8540 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Vector35/binaryninja-api#8516 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 92/100
Vector35/binaryninja-api#8503 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Vector35/binaryninja-api#8446 ·
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Vector35/binaryninja-api#8444 ·
All issues in Vector35/binaryninja-api
Similar issues
-
Difficulty 1/5 1-3 hours Newbie friendliness 92/100
autowarefoundation/autoware_universe#13413 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
automated-analysis bug memory-safety
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
-
Sensor initialization takes very long when `--initial-sim-time` is set to current UNIX timestamp Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
gazebosim/gz-sensors#662 · 1 comment ·