Вверх ↑
Этот топик читают: Гость
Гость
Ответов: 17029
Рейтинг: 0
#46: 2008-08-26 13:42:16 правка | ЛС | профиль | цитата


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

0
Ответов: 5227
Рейтинг: 587
#47: 2008-08-26 13:53:09 ЛС | профиль | цитата
Tad я всёже предпочту открытую архитектуру ini файла, вводить пользователя в заблуждение или делать какие нибудь пакасти не мой профиль, такая форма записи (которую приводил выше) предпочтительней для реестра, чтоб более продвинутые пользователи меньше вопросов задавали.
карма: 4
Мой форум - http://hiasm.bbtalk.me/ схемы, компоненты...
0
Ответов: 16884
Рейтинг: 1239
#48: 2008-08-26 14:05:00 ЛС | профиль | цитата
andrestudio, давай соображения - есть 20 шт. Edit . Какие дать им имена
карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Ответов: 1926
Рейтинг: 172
#49: 2008-08-26 14:07:05 ЛС | профиль | цитата
Гость писал(а):
нафига она такая нужна

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

Tad писал(а):
чего тебе в "Options" не хватает

А того, что если сменить имя флажка по doCaption, то присвоится ли ему другой номер в ini? Не особо вникал в код Options, то думаю - нет. А тогда это будет уже флажок с другой функцией, и сохранять его надо под другим именем. Мой же вариант это позволяет.
карма: 9
0
Ответов: 16884
Рейтинг: 1239
#50: 2008-08-26 14:06:26 ЛС | профиль | цитата
andrestudio писал(а):
делать какие нибудь пакости
Значит HiAsmSettings.cfg - это пакости

карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Ответов: 1926
Рейтинг: 172
#51: 2008-08-26 14:08:19 ЛС | профиль | цитата
Tad писал(а):
Какие дать им имена

Имена, может, и никакие, но указать имя ключа - в моей доработке - можно с успехом.
карма: 9
0
Разработчик
Ответов: 26151
Рейтинг: 2127
#52: 2008-08-26 14:10:35 ЛС | профиль | цитата
3042 писал(а):
но указать имя ключа - в моей доработке - можно с успехом

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

0
Ответов: 1926
Рейтинг: 172
#53: 2008-08-26 14:17:07 ЛС | профиль | цитата
nesco писал(а):
А я вот я хочу сделать то же самое, но для любых контролов


Я тоже. Как раз этим и собираюсь заняться. Ну и ещё - см. выше - нужно, чтоб компонент при загрузке сразу устанавливал соотв. глобальную переменную (опционально).
карма: 9
0
Разработчик
Ответов: 26151
Рейтинг: 2127
#54: 2008-08-26 14:26:41 ЛС | профиль | цитата
3042 писал(а):
Как раз этим и собираюсь заняться

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

0
Ответов: 5227
Рейтинг: 587
#55: 2008-08-26 14:32:10 ЛС | профиль | цитата
Tad, а причём HiAsmSettings.cfg, там что ini format , имена всегда можно придумать.
nesco, универсальный вариант будет гораздо лучше
карма: 4
Мой форум - http://hiasm.bbtalk.me/ схемы, компоненты...
0
Ответов: 16884
Рейтинг: 1239
#56: 2008-08-26 14:47:45 ЛС | профиль | цитата
3042 писал(а):
Ну и ещё - см. выше - нужно, чтоб компонент при загрузке сразу устанавливал соотв. глобальную переменную (опционально).
А может "щи отдельно, а мухи отдельно"
Для глобальных переменных уже есть специальный компонент.


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

andrestudio писал(а):
а причём HiAsmSettings.cfg, там что ini format
суть та же - запомнить CheckBox-ы, RadioButton-ы и Edit-ы и больше ничего.
Зато сколько работы: считать данные, зашифровать, записать на диск. При последующих запусках: считать с диска, расшифровать, установить согласно считанным данным.
карма: 25
Немного терпения! Дежурный экстрасенс скоро свяжется с Вами!
0
Ответов: 9906
Рейтинг: 351
#57: 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
Разработчик
Ответов: 26151
Рейтинг: 2127
#58: 2008-08-26 16:17:22 ЛС | профиль | цитата
Galkov, странный ты человек -- я делаю из того, что мне дают, и автор эту технологию для этого и разрабатывал.

Galkov писал(а):
все, чего собирается сделать nesco (ума-то нету) собрано в одном элементе

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

Galkov писал(а):
которые среда не "отвергает", а наоборот -- передает в CodeGen.

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

0
Ответов: 9906
Рейтинг: 351
#59: 2008-08-26 16:25:58 ЛС | профиль | цитата
nesco, а я тоже человек "практический"
И именно в силу этой практичности - не люблю делать того, что грохнется медным тазом.
Более практичным считаю подумать на всю катушку ДО того, как делать чего-то, а не ПОСЛЕ
И даже настаиваю на том, что уж это-то -- я умею.

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

0
Разработчик
Ответов: 26151
Рейтинг: 2127
#60: 2008-08-26 16:29:30 ЛС | профиль | цитата
Galkov писал(а):
НО, я ни на чем не настаиваю - делай

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

0
Сообщение
...
Прикрепленные файлы
(файлы не залиты)