Редактировалось 5 раз(а), последний 2021-06-22 14:24:45

Tad я всёже предпочту открытую архитектуру ini файла, вводить пользователя в заблуждение или делать какие нибудь пакасти не мой профиль, такая форма записи (которую приводил выше) предпочтительней для реестра, чтоб более продвинутые пользователи меньше вопросов задавали.

andrestudio, давай соображения - есть 20 шт. Edit . Какие дать им имена

Пусть прога работает правильно, но если с самой Видной что-то не так. Зависла там или ещё что? Да хоть свет вырубили! И все 70-80 настроек пропадут.


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

Значит HiAsmSettings.cfg - это пакости

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

А я вот я хочу сделать то же самое, но для любых контролов и что бы еще и в реестр могла писать, как MainForm

Я тоже. Как раз этим и собираюсь заняться. Ну и ещё - см. выше - нужно, чтоб компонент при загрузке сразу устанавливал соотв. глобальную переменную (опционально).

Без знания технологии построения менеджеров, это будет на уровне радиолюбительства -- так, для себя сделать

Tad, а причём HiAsmSettings.cfg, там что ini format , имена всегда можно придумать.
nesco, универсальный вариант будет гораздо лучше

А может "щи отдельно, а мухи отдельно"
Для глобальных переменных уже есть специальный компонент.


------------ Дoбавленo:

суть та же - запомнить CheckBox-ы, RadioButton-ы и Edit-ы и больше ничего.
Зато сколько работы: считать данные, зашифровать, записать на диск. При последующих запусках: считать с диска, расшифровать, установить согласно считанным данным.

не знаю про nesco, а я смеяться не буду, а просто скажу: тяжело жить с деревянной головой
Тебе же (именно тебе) выкладывали Ex, который будет правильно работать в твоей "картинке", даже если изменения переменных делаются из другого контейнера.

---

Про элемент Option - помню.
А не пошел он по простой причине: все, чего собирается сделать nesco (ума-то нету) собрано в одном элементе. И не пошел вовсе не от того, что "собрано", а от того что "всех элементов"
Разбиение кода одного на некие составные части в разных файлах вовсе не способствует их синхронизации, и устойчивости к неким изменениям.
Мягко говоря.
Не думаю, что ситуация принципиально изменится, если эти "составные части" будут лежать не в одном файле, а в двух сотнях
Это только начиналось в этом элементе все просто: ай, вот один общий PControl, все одинаково, как все замечательно!!!
А на деле, чем дальше в лес, тем толще партизаны
Это при том у "леса" еще и граница не показалась на горизонте.
Буквально на следующий день, после какой-нибудь альфы, появится "ну очень надо" и для не визуальных контролов

А если подумать, внимательно, то у каждого св-ва любого элемента должен появиться признак как наличия метода doProp, так и доступность св-ва для чтения (что совершенно не факт)
Плюс к этому, некоторые св-ва необходимо устанавливать исключительно ДО создания элемента, а некоторые обязательно ПОСЛЕ (это просто еще один признак св-ва).
Ну и в идеале - контекстное меню на каждом св-ве с птичками на пунктах типа Save/Restore
А "должен появиться", означает, что в INI-файле элементов должны появиться некоторые записи, которые среда не "отвергает", а наоборот -- передает в CodeGen.
Только после этого можно было бы аккуратно в нем отработать необходимые присваивания, даже индивидуальной кодогенерацией одного элемента типа контейнера этих опций...

Но это, если подумать, что, к сожалению, нынче не модно
Такое, может и стоило бы затрат серого вещества

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

А затея с "технологией построения менеджеров" - грохнется медным тазом, чего-то мне так пока кажется.
Ровно по той же причине, что и Option - персональный код под КАЖДЫЙ элемент, необходимый к сопровождению

---

P.S. Да, вот еще, наблюдение: красивые и непонятные слова чаще всего применяются, когда хотят, чтобы окружающие НЕ поняли отсутствие мыслей за этими словами.
"Технология", блин

Galkov, странный ты человек -- я делаю из того, что мне дают, и автор эту технологию для этого и разрабатывал.


Я не делаю процессоров сейчас, а менеджер банально будет записывать в секции, которые каждый контрол ему и будет давать. Менеджер тупой, ему дали -- он записал, все, и никаких хитростей.


И где это, у тебя в голове, в среде-то этого нет, и, возможно, никогда не будет, судя по реакции автора проекта

nesco, а я тоже человек "практический"
И именно в силу этой практичности - не люблю делать того, что грохнется медным тазом.
Более практичным считаю подумать на всю катушку ДО того, как делать чего-то, а не ПОСЛЕ
И даже настаиваю на том, что уж это-то -- я умею.

НО, я ни на чем не настаиваю - делай.
Мои предсказания про "технологию" - тебе известны

Я, кстати, тоже -- могу и не делать. Оно мне надо, хотя, может быть и пригодилось бы