Feature request: Add search/filtering functionality to the Components list

[Tom G]

Currently, Inno Setup supports basic incremental search in the components list (jumping to an item by typing its name). However, this behavior often conflicts with the installer's navigation hotkeys. In complex setups, typing to find a component can accidentally trigger a page change unless all hotkeys are manually disabled. Many times it works only for just few first letters and doesn't find all components

I would like to propose a more robust filtering system for the Components page:

1. Search UI: A dedicated search/input field that appears when the user starts typing or presses a shortcut (like Ctrl+F). This would provide visual feedback of what is being typed.

2. Dynamic Filtering: Instead of just jumping to the first match, the checklist should dynamically filter the view to display only the components that match the entered string.

3. Conflict Resolution: By having a focused search state, the installer could temporarily suspend global navigation hotkeys, preventing accidental jumps to the Next/Back pages while the user is searching.

This would significantly improve the UX for installers with large component lists, making the selection process faster and more reliable.

Best,
Tom

[Bill Stewart]

On Wednesday, January 14, 2026 at 4:50:09 AM UTC-7 Tom G wrote:

This would significantly improve the UX for installers with large component lists...

How many components would you consider to be a large number?

[Tom G]

One of my installer have around 1500 components, another one around 700.

[Gavin Lambert]

On Thursday, January 15, 2026 at 5:46:50 AM UTC+13 Tom G wrote:

One of my installer have around 1500 components, another one around 700.

That does sound a bit excessive.  Remember that (unlike MSI-based installers) not every file needs to be associated with a component -- you only need to declare a component and link a file to it when there is a meaningful choice that the user can make whether to include or exclude an optional feature.  Anything that is required for proper functionality can just be left without any component, and if a bunch of subcomponents are required for a particular component you can just link them all to the parent component without explicitly declaring them as a subcomponent.

Also, disk space is cheap, so it's often easier and simpler to unconditionally install features and then decide whether to enable them or not within the application settings, rather than forcing users to choose between things at install time (when they might not even know yet what the feature is and whether they want to use it or not).

An installer should not usually have more than about 10 or so components (maybe a few more if they're arranged into logical trees) because users will get decision paralysis.

[Tom G]

I'm using it to install a lot of game modifications, there is a lot of them. This cannot be reduced :D 

[Gavin Lambert]

On Thursday, January 15, 2026 at 11:38:11 AM UTC+13 Tom G wrote:

I'm using it to install a lot of game modifications, there is a lot of them. This cannot be reduced :D 

There are usually better tools for this purpose (such as MO2, Vortex, or Wabbajack) which also handle things like load order and checking for individual updates.