Any other alternative to column limits imposed in the newest version?

[gallickgunner]

Hello ocornut. I just read the changelog and found that the number of columns have been limited between 1-64. Just wanted to know, Is there any other alternative for it? Are you planning to remove columns API from the future versions or something, what's the future plan?

Since my file dialog uses a column-based design, as shown in the screenshot,instead of pure vertical list based (purely aesthetical I guess) It's entirely possible to exceed 64 columns depending on the amount of files and directories present in a specific folder and the size of the dialog itself. Thanks.

[ocornut]

Hello,

1. My initial intent was to make the Columns API call into the upcoming Tables API (New Tables API (alpha available for testing) #2957), which has a limitation of 64 columns for various reasons (which could be lifted down the line). However when I tried to implement this Columns to Tables wrapper I found that Columns has many sublte odd/specific glitches that may be difficult or unhealthy to try to replicate "as-is" using the Tables API, so I may drop that idea and leave Columns as-is, and document them as "old API, prefer to use tables". Either way, the columns api won't be removed soon, if ever.

2. On your specific use case: since you are seemingly using one cell par column (submitting vertically before going to the next column) what you are doing could also be achieved by positioning the cursor and altering the clip-rect. The extra benefit you get from Columns is the resizing, which we should aim to provide other primitives for (Splitter #319). I think it would also be good if we made it easier and more natural to implement your use case even without using the columns api.

I haven't totally dropped the idea of the "Columns to Tables wrapper" though, but right now it seems unlikely. I'll keep this issue open for a while, because I'd like to think about (2) and I'm still working on Tables. Depending on the outcome I may keep the Columns API as-is and remove the assert introduced in the last version.

[ocornut]

Hello @gallickgunner ,
After some consideration I have decided to undo that change since it is unlikely I would be able to provide a perfect Columns>Table API transition.
Removed this assert now.