Total Commander

sa писал(а):А как правильно

Правило одно - направления сортировки по дате/имени должны совпадать. У меня в первом коде задана вот именно что обратная сортировка в цикле. Поэтому смена числа к такому эффекту и приводит. В новом же варианте направление меняется в зависимости от его выбора параметром.

А где-то можно посмотреть это правило - про необходимость совпадения направления сортировки по дате/имени (в панели TC, например, сортировка по имени прямая, вне зависимости от направления сортировки по дате)?

Я не утверждаю, что это правило работает везде. Исхожу лишь из логики порядка создания. Допустим, файлы создавались в одно время с некой нумерацией. При совпадении времени модификации лучше их приблизить к порядку создания, который более вероятен. Это, конечно, не 100% вероятность, но тем не менее файлы не должны обрабатываться в обратном именном порядке, как в твоём случае.

Коли имеются некоторые допущения по нумерации файлов, которые имеют не 100% вероятность, то, следуя твоей логике оценки решения задачи, ситуации, когда результаты выполнения скрипта будут неверными, возможны во всех предложенных вариантах.

Вероятность должна быть в любом случае максимальной.
Например, почему сортировка по типу в ТС меняет и сортировку по базовому имени? Принципильного же отличия от даты нет.
И, если cледовать логике файлменеджера, спорным может быть только исходный случай до появления нового запроса, а твой будет в любом случае некорректен для второго.

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

Итог ложен. Я привёл к более вероятному, ты - наоборот.

Я без привязки к своей правке. Только оцениваю твои скрипты по твоей же методике. А отсутствие 100% вероятности нумерации под тебя ты уже признавал.

Я не вижу довода, где в моей методике приведения к большей вероятности я ошибаюсь. Одно утверждение.

Flasher писал(а):где в моей методике приведения к большей вероятности я ошибаюсь

Об этом у меня речи не было.

Я твоими же словами утверждал, что, "Есть ситуации, где результат будет неверным".
Ты отрицаешь наличие таких ситуаций при использовании твоих скриптов (без каких-либо моих правок)?

Я отрицаю твой итог, сулящий, что в обоих скриптах я ошибаюсь.
Ошибка может быть там, где есть место инвариантности.

Flasher писал(а):При совпадении времени модификации лучше их приблизить к порядку создания, который более вероятен. Это, конечно, не 100% вероятность

Сам же писал, что не 100%.
Пользователь, например, мог переименовать файлы, привязываясь не к порядку создания, а к рейтингу файлов-снимков, по их качеству в серии:
20170627-101723_001 --> 20170627-101723_3
20170627-101723_002 --> 20170627-101723_1
20170627-101723_003 --> 20170627-101723_2

Ещё хотел спросить (пока нас не прикрыли): как ты относишься к тому, что, если в тестовом примере выставить даты нескольких файлов не 2016, а 1816 годом, то сортировка у тебя становится неверной?

sa писал(а):Сам же писал, что не 100%.

Это ничего не меняет.

sa писал(а):Ещё хотел спросить (пока нас не прикрыли)

Спроси лучше себя, когда появились ЭВМ.

Flasher писал(а):Это ничего не меняет.

Если вероятность верного результата не 100%, значит, результат может быть ошибочным.

Сам удивляюсь, зачем в VBA сделали такой допустимый диапазон дат: если не ошибаюсь, то -657434 соответствует 1 января 100, а 2958465 - 31 декабря 9999. Соответственно, 0 это 30 декабря 1899.

Добавлено.
Думаю, стоит подправить скрипт, чтобы он правильно работал во всём допустимом диапазоне. Либо указать ограничение о поддержке дат только позже 30 декабря 1899.

sa писал(а):значит, результат может быть ошибочным.

не равно

sa писал(а):в обоих скриптах ты ошибаешься

Хорошо вчитайся во второе предложение.
Про диапазон что-то читал, но уже не помню где. Искать лень.