баг в TPictureList.FFileNames

[GoogleCodeExporter]

Во многих скриптах нужно вызывать makename, что 
влечет за собой ситуацию, когда кол-во 
совпадающих имен уменьшается, но имена у 
некоторых изображения не изменяюстя. На 
примере:

fname(1)
fname(2)
fname(3)
fname(4)
fname(5)
aname(1)
aname(2)

каунтер для имени - 5
вызывается makename для fname(2), каунтер 
уменьшается на 1, получается 4.
вызывается makename для fname(3), каутнер падает до 
3.
fname(4) не изменяется.
aname(1) меняется на fname, и получается имя fname(4), 
совпадение с уже существующим.

Нужно изменить пересчет совпадающих имен 
(как-то считать "пропущенные" цифры?).

Original issue reported on code.google.com by catgirlfighter on 26 Sep 2013 at 12:51

[GoogleCodeExporter]

короме того, каунтер не уменьшается вообще, 
в ffilenames хранятся оригинальные имена, а в 
процедуре передается уже модифированное (с 
$fn$) имя.

Original comment by catgirlfighter on 26 Sep 2013 at 12:52

[GoogleCodeExporter]

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

Файлов в списке может быть ОЧЕНЬ много, и, 
теоретически, совпадений может быть 
столько же, сколько файлов (допустим, 1000+). 
Листать файлы и искать пропущенные не 
вариант... Результат в виде file(1), file(2), 
file(5),file(15),file(16) без промежуточных мне не 
нравится. Особенно когда все "начальные" 
просто пропущены, типа когда отсчет 
начинается сразу с 15, а 1-14 просто нет.

Можно добавлять дополнительный список к 
именам, где будут храниться номера 
"пропущенных", и брать номера из этого 
списка. Это существенно ускорит поиск, т.к. 
нужно будет только проверять наличие 
значений в этом списке, и выбирать самый 
первый, если существует.

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

Original comment by catgirlfighter on 10 Oct 2013 at 1:43

[GoogleCodeExporter]

Уменьшать номер всех номеров выше 
пропущенного тоже не вариант по той же 
причине, что и "листание списка" для поиска 
пропущенного номера (а то и хуже). Разве что 
переименовывать последний вариант списка 
сразу же после появления "пропущееного". 
Тем самым список пропущенных вообще не 
надо будет вести, их не будет, разве что 
надо будет запоминрать адрес изображения, 
получившего имя последним. Кроме того, 
изображения должны запоминать адреса тех, 
которые были созданы перед ними, чтобы 
можно было получить адрес "нового 
последнего" (т.е. предыдущего) изображения 
для последующей подстановки.

Original comment by catgirlfighter on 10 Oct 2013 at 1:50

[GoogleCodeExporter]

Для файлов с новыми именами тоже нужно 
создавать заплатки с указателем на 
оригинал.

Вообще не подумал на счет "других 
паттернов". Т.е. когда имя получается 
одинаковым чисто случайно, по другим 
правилам. В этом случае не правильно давать 
ему счетчик от другого паттерна.

Original comment by catgirlfighter on 14 Oct 2013 at 12:49

[GoogleCodeExporter]

В общем, решил оставить такой механизм:

name (формат 1)
name_1 (формат 1)

файл с именем name_2 с другим форматом уже 
будет называться name_2_1. Если же вдруг 
случиться, что будет совпадение имен 
включая счетчики, т.е. форматы будут вроде 
name_$fn$_1 и name_1_$fn$, то считать это проблемой 
пользователя, ака совпадение будет 
корректным.

Original comment by catgirlfighter on 15 Oct 2013 at 8:30

[GoogleCodeExporter]

Да, неучтенных мелочей на много больше. 
Нужно "следующей" пикче тоже как-то 
поменять адрес на "предыдущую" при смене 
промежуточной, т.е. надо добавить ссылку на 
"следующую", + надо делать ссылку на 
заплатку, если такая существует, чтобы 
пикчи, для которых эта ссылка является не 
заплаткой, а родитлем, не "терялись", т.е. при 
удалении заплатки, дочерняя пикча смогла 
унаследовать нулевую позицию вместо пикчи, 
создавшей заплатку, для сохранения цепочки.

Original comment by catgirlfighter on 15 Oct 2013 at 1:50

[GoogleCodeExporter]

Может, в счетчике имен кроме одного 
последнего элемента хранить две ссылки: на 
первый и последний? Проще будет управлять 
заплатками и менять нулевые элементы. 
Всяко лучше, чем для каждой пикчи добавлять 
ссылку на следующий элемент в цепочке от 
заплатки.

Original comment by catgirlfighter on 15 Oct 2013 at 1:54

[GoogleCodeExporter]

Особенно с учетом того, что счетчик для 
заплатки создает только если у заплатки 
появляются ведомые элменты.

Original comment by catgirlfighter on 15 Oct 2013 at 1:55

[GoogleCodeExporter]

Кроме того, нужно добавить условие. Сейчас 
Имя у последнего элемента 
"пересчитывается" сразу же после изъятия 
промежуточного элемента из цепочки. Нужно, 
чтобы имя файла пересчитывалось в момент 
необходимости (т.е. перед началом закачки 
пикчи). Иначе временые имена могут 
переприсваиваться "лишний раз" до 50% от 
размера списка.

Original comment by catgirlfighter on 15 Oct 2013 at 1:59

[GoogleCodeExporter]

Original comment by catgirlfighter on 15 Oct 2013 at 2:57

• Changed state: Fixed