[Version 11.0.0] Name column becomes nearly invisible when resizing the Custom Dialog with a Details view

[rakunavi]

Hello all,

In version 11.0.0, the newly introduced custom "Open/Save" dialog has a critical layout flaw when the view mode is set to "Details".

When narrowing the dialog window, ONLY the "Name" column is forced to shrink, while the widths of all other columns (Date modified, Type, Size) remain completely fixed and unchanged.

As a result, the "Name" column quickly collapses down to about 2mm, displaying 0 characters of the filename due to column padding. The horizontal scrollbar only appears after the dialog becomes narrower than the combined fixed widths of the other columns.

• figure.png

This is a complete reversal of good UX design; the most important information (the filename) is destroyed first, while secondary information is protected.

Steps to Reproduce:

1. Open the file dialog and change the view mode to Details.
2. Gradually narrow the width of the dialog window.
3. Observe that only the "Name" column shrinks, collapsing to ~2mm and making filenames invisible, while other columns maintain their full widths.

• Animation.gif

Expected Behavior:
The "Name" column should have a strict minimum width (Min-Width) to ensure filenames remain readable. When the dialog narrows, either the less important columns on the right should shrink first, or the horizontal scrollbar should appear immediately to preserve the "Name" column's visibility.

Hoping that the above information will be of some help to you.
Thank you for your hard work on this great software.

Best regards,
rakunavi

- PDF-XChange Editor PRO Version: 11.0.0
- OS Version: Windows 11 Pro / Home 25H2 Build 26200.8457
- PC Model: GMKtec Nucbox M7 Pro with HUION Kamvas Pro 19 / Lenovo IdeaPad C340-15IWL

[Sunilkumar]

I can reproduce this behavior on my side as well, and I agree that the current resizing logic prioritizes the wrong columns from a usability standpoint.

From a UI/UX perspective, the “Name” column should ideally behave as the primary flexible column, but with a defined minimum width threshold. Right now it seems to be treated as the only flexible column without any lower bound, while the others act as fixed-width columns, which creates the collapse effect you described.

In most standard file dialog implementations (including Windows Explorer), the resizing behavior typically follows a different pattern:

The “Name” column expands and contracts first, but respects a minimum width
Secondary columns (Date modified, Type, Size) either have smaller minimum widths or begin to truncate earlier
A horizontal scrollbar is introduced as soon as the layout cannot maintain usability

What might help here is introducing a simple constraint model, for example:

Assign a MinWidth to the Name column (e.g., enough to display at least ~10–15 characters)
Allow proportional shrinking across all columns instead of isolating it to just one
Trigger the horizontal scrollbar earlier, based on total minimum widths rather than current fixed widths

Another option could be to dynamically prioritize columns based on importance—so when space becomes limited, less critical columns (like “Type” or even “Size”) could truncate or collapse first before affecting the filename.

[Daniel - PDF-XChange]

Hello,

Thank you both for the reports. This item is being bundled into Rakunavi's other the report here: viewtopic.php?t=49538
As the two are directly related to one another.

Kind regards,