Вверх ↑
Ответов: 9906
Рейтинг: 351
#1: 2008-08-26 16:14:16 ЛС | профиль | цитата
Tad писал(а):
nesco будет смеяться, но в таких случаях (сохранение и чтение из ини в глобальную переменную) не помешала бы GlobalVar точка onChange
Тогда без никаких линков (имитация)

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


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

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

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

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

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


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

0