andrestudio, а можно ли использовать Label больше одной?

Андрей., можно. В чем проблема?
в соответствующие места скрипта добавь
Case "Label2" : SDK.SetProp(SDK.Item(i), "Caption", "Метка2")
Case "Метка2" : SDK.SetProp(SDK.Item(i), "Caption", "Label2")

Перевод будет у любых элементов которые имеют свойство Caption, и как отметил Sniper36 для этого нужно отредактировать строчки в скрипте (я думаю что это не так сложно) только нужно учитывать что ScriptEvents работает только в составе своего контейнера.

менеджер пользовательских настроек (например)..

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

вот схема включения code_13614.txt, прошу высказываться..

Редактировалось 4 раз(а), последний 2021-05-21 05:16:48

Выше - это я.

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

GVarContainer, по моему, полностью удовлетворяет этому условию.

Почемупо честному - нифига не понял.
Почему нельзя применить другой (второй, третий и т.д.) GVarContainer с другим списком переменных "для других форм настроек"?
Если список переменных один и тот же, то почему переменные "для других форм настроек " не могут лежать в другой секции ?
Почему нельзя, при запуске программы, переключать название секции?
Извини Андрей., видно нужно знать конечную твою цель, а то что-то почему-то очень много "почему".

Tad, в моём случае ini-файл содержит относительно много секций, и Settings - одна на все формы настроек (сейчас их 7, но это не конечный вариант). К тому же GVarContainer не намного упрощает схему (если не наоборот) позиционная запись в контролы всё равно остаётся, или я не прав?

Иметь в одном мульте GVarContainer для чтения переменных и StrList для индивидуального их сохранения недопускает отсутствие у GVarContainer способности загружать список переменных, а иметь во внешних свойствах мульта 2 списка и возлагать на прогера обязанность следить за их идентичностью - дурной тон имхо.
------------ Дoбавленo в 12.10:
рад интересным вопросам (сегодня есть время)

Андрей., честно - не доходит. При чем здесь, что и чего 7?
code_13622.txt

нормальная схема - я примерно так и делал сначала.
а теперь сравни вот это code_13623.txt и это code_13624.txt - какая схема читабельнее?

Вопрос провокационный
Кроме читабельности нужна еще и надежность.
Для меня - без мультика. Все на виду и понятно. Никаких надписей типа: "check не понимает текст" которая, как ты говорил ? Вот сейчас все три CheckBox выбраны, а в ini -файле записан только один.

т.е. именно ты возлагаешь "на прогера обязанность следить за их идентичностью (соответствием данных)- дурной тон имхо"
в скобках - моё.

именно снижение колличества элементов на рабочем поле было причиной.

в моём варианте изменения сохраняются сразу, а не при завершении проги. Что надёжнее?

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

у меня всё нормально


PS: теперь я верю коллегам, которые говорят, что я не умею объяснять, а иногда так вообще ххх какую-то говорю

Согласен, именно изменения, но сделать сохраниение после каждого чиха - не проблема. Проблема сохранять только тогда, когда чих что-то изменил.
удали eee.ini, запусти свой пример, напиши что нибудь в одном из Edit, закрой прогу и посмотри,что в eee.ini.
После этого повторно запусти прогу и посмотри что на экране.
Пользователь твоей програмы может и не знать, что для записи состояний, нужно пощелкать всеми чеками, что-то написать в Edit-ах и подергать рычажки Scroll-ов.

Хотя тут и я маху дал тоже - перед сохранением нужно опросить состояние всех компонентов, а потом сохранять. Позор

------------ Дoбавленo в 16.02:
Вот это высказывание видно зацепило. А строго соблюдать порядок подключения к ChanelToIndex соответственно списку в StrList (или наоборот) это не "возлагать на прогера "

вот за это тебе +
Обычно я создаю ini-шник со всеми нужными значениями ключей при первом запуске и такая ситуёвина исключается, но по условиям темы лучше это решить в мульте, но я пока не знаю как..
------------ Дoбавленo в 16.12:
без этого никак..