Есть ли возможность использования ассоциативного массива в хиасме???
[flood]Для тех кто не понял о чем речь. Пример ассоциативного массива:
f=foot
c=close
m=tramvai
То есть вместо индексов используются символы.[/flood]
------------ Дoбавленo в 08.48:
Как сделать аналогию ассоциативного массива, я представляю, нужны два списка, в одном хранить ключ(строка) в другом данные.
Неужели это единственный вариант?

А в сторону обыкновенного ini-файла не смотрел?

Если (одиночные) то можно и так:
code_34348.txt

Если в качестве индекса используются наборы символов, то придется определять позицию разделителя ("=")
или применить IC - намного дешевле.

Так вроде, они с самого начала именно такими и были:

Galkov, о каком компоненте идет речь? С параметром "UseName" я видел только массив картинок.
Tad, я рассматривал вариант похожий на твой, но при большом количестве строк с перебором строк начинаются проблемы, он медленней работает чем сумма методов doGetIndex и doGetString у StrList.

Доп. файлы к экзешнику не рассматриваются, поэтому, либо все записывать в 1 список, либо разделять списки на категории(вроде отдельных файлов) и определять категорию, затем вытаскивать данные из нужного списка, то есть уже получается наглядный вариант вложенного массива.
В варианте с 1 списком, строк получается около 930.
В варианте с категориями, получается 10 категорий и уже по 93 строки.
В десяти категориях запутаться сложно, поэтому можно для каждой использовать индекс и для вытаскивания нужного списка использовать GetIndexData.
Я уверен что перебор массива спокойно и быстро обработает 930 строк, если бы не одно но... получится не 930, а 86490, объясню почему.
Выводится картинка, далее должен быть выведен текст к картинке, существуют 3 колонки, в каждой по 31(в среднем) картинке, вот и получается что, чтобы вывести текст к последней картинке в 3 колонке, необходимо 93 раза запустить перебор массива. Конечно можно стопорить перебор при нахождении, но чем дальше он перебирает, тем дольше он грузит.
А если использовать категории, то вместо 86 тысяч, получаем вполне адекватную цифру 93(и +1 за выбор категории)

А StreamArray, IntArray и RealArray разве не имеют "UseName"

nesco, спасибо, нашел. Но в них нельзя использовать строковой параметр в качестве данных, только числа

имеют.
Ввести имя - запросто.
А вот ввести в них строковое значение вроде не получится.

------------ Дoбавленo в 16.39:
knoot0279, опередил.

любой строковой параметр заменяется нулем
------------ Дoбавленo в 16.49:
code_34348.txt, Tad, почему одиночные? можно любой длинны, только в первом копировании мы ставим кол-во необходимых символов, а во втором смещаем позицию относительно ранее проделанных изменений

Так быстрее будет.
code_34351.txt
Намного.

Tad, а если учесть то, что я выше писал на тему категорий... по логике, с ними еще быстрее должно быть. при этом пропадает(в моем случае) необходимость использования ассоциативного массива
------------ Дoбавленo в 17.09:
code_34351.txt
было бы не плохо включить в стандартный набор хиасма))

По-честному из всего этого я нихрена не понял.

10 категорий
3 колонки
31 сообщение в каждой колонке
если все это загнать в виде ассоциативного массива, то получится 930 строк(банальное умножение)
если гонять все это перебором массива, то получаем лишние прогоны заведомо ненужной информации(той самой информации которую можно убрать в другую категорию и не трогать вообще, без надобности)
теперь компактней и вроде понятней
------------ Дoбавленo в 17.15:
на экран, в сумме, всегда выводится 93 сообщения

И эти 93 сообщения ещё и кому-то прочитать нужно... Дурдом конечно.

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

Каким бы сообщение компактным небыло - его нужно прочесть и осмыслить.
Не нравится мне такой подход.
И всё.