Выше я.

Тут, кстати говоря, есть небольшая заморочка с Дельфячим LowerCase (их таких два в коде).
Он некорректно работает с русскими буквами. Точнее - вообще не знает про них.
Корректно работает Виндячий. Но он может попортить не только то, чего ты хочешь... Но и не понять какой оригинал строки.

Стоит возиться, или нет

А зачем возиться - изменить обе на AnsiLowerCase. Даже с "Ё" никаких проблем.
С AnsiLowerCase из каталога в котором подкаталогов 1271 и файлов 23283 отобрало 150 файлов за 750 ms
Почему отрабатывает быстрее, чем с LowerCase - непонятно.

Для прикола запустил с AnsiLowerCase на компе внука с ивритским Windows
Каталогов 38552, файлов 362105. Отобрало файлов 1673 (по расширениям на моей картинке выше) за 16250 ms
Там есть названия на иврите, арабском, русском и английском.

А что, бывают расширения на кириллице, вот уж никогда не встречал

Тоже верно.
P.S. http://delphiworld.narod.ru/base/kol_lesson12.html

*Головачев*
*Golovachev*
*Головачёв*
*Golovachyov*
А расширение любое.

flint2, это вообще-то не расширение файла, а его имя. Но согласен, что в маске могут присутствовать кириллические символы, если надо найти по части имени. Но вот тут всплывает недочет основного автора компонента, тк свойство обозначено как именно расширение

а то, что код ищет вообще все подряд по маске, так это получается уже недокументированная фича. Кстати, которая вполне может быть аннулирована авторами и приведена в соответствие со свойством, вне зависимости от стенания пользователей.
Вот если бы это свойство изначально называлось Mask -- маска поиска файлов, то никаких разночтений не возникало бы.

Тык я об чём. Не расширением единым.


Формально -Да, по сути нет.

По коду и так понятно. Зовите меня просто - Mask

Поправка: LowerCase -- это KOL-овская фишка (а не Дельфячая)
В общем, если делать "по правильному", то будет примерно так: (см аттач)

Смотрите, думайте: стоит оно того, или нет ...

А че вторую функцию LowerCase убрал, она что, не нужна? Те cFileName уже приведен к нижнему регистру, получается?

Работает шустро.
Но было бы правильно при _prop_Include = Dirs и All директории тоже фильтровались, а не выводились все подряд.
И только при _prop_Ext (и Ext) = '*' выводились все подряд.
Очень часто надо найти папку и приходится городить огород.
+ Нужна точка для внешнего задания значений _prop_Include.
Это лучше, чем дублировать компонент в схеме с другим значением.

Не убирал.
А запихнул внутрь multiCmp эти пляски с бубном
------------ Дoбавленo в 14.28:

В общем-то -- ДА.
Но это нарушение обратной совместимости. Хотя, и ничего сложного:

Galkov, а мне кажется, что при '*' по умолчанию совместимость полная, или мне кажется?
А ещё одна точка "Include" на совместимость вообще не влияет.

А если нужно отдельно найти файлы с расширением *.TXT, *.txt, *.Txt, *.tXt, *.txT
Т.Е. с учетом регистра.

Tad, С расширением не тот случай, когда лучше перебдеть, чем недобдеть.
Регистр расширения никак не может быть препятствием в взаимоотношениях.