alter interface дважды

[Шевцов Владимир]

Доброго дня.
Есть настройки интерфейсов (откомпилированные cnf+vip), сделанные ранее. Подключаются дополнительным ресурсником.
Сейчас хочу сделать дополнительные настройки - поверх первых. С возможностью включать/отключать новый ресурсный файл.
Работает ли такая схема?
Или второй доп. ресурс заместит первый и изменения первого потеряются?
Возможны ли рантаймы при таких двойных донастройках?

[Masygreen]

зачем????? настройки каждый раз пересчитывать ? ???

[edward_K]

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

[LaaLaa]

Доброго дня.
Есть настройки интерфейсов (откомпилированные cnf+vip), сделанные ранее. Подключаются дополнительным ресурсником.
Сейчас хочу сделать дополнительные настройки - поверх первых. С возможностью включать/отключать новый ресурсный файл.
Работает ли такая схема?
Или второй доп. ресурс заместит первый и изменения первого потеряются?
Возможны ли рантаймы при таких двойных донастройках?

Лучше не надо. Запутаете себя и компилятор.

[Шевцов Владимир]

Лучше не надо. Запутаете себя и компилятор.

Да.
В итоге, скрепя сердце, продублировал старые доработки в новом vip-файле, добавил в него новый функционал, подключаю с бОльшим приоритетом и работает.

[edward_K]

Ну можно было не все. Есть инклюды дефайны объекты

[Шевцов Владимир]

Ну можно было не все. Есть инклюды дефайны объекты

Я и спрашивал - можно ли иметь в разных ресурсах два "алтера" на один интерфейс и два обработчика события на один скрин.
Причем одна докомпиляция живет всегда, а вторую подключать поверх первой при необходимости.
Причем добавляю обработку событий, которые не изменяются в первой докомпиляции.
Ответ получен - "лучше не надо".
Если есть вариант - можно описать в двух словах?
Потому что.. сами знаете почему

[edward_K]

главное помнить, что докомпиляция целиком перетаскивает фейс в ваш рес - исходя из этого и думайте.

[Den]

"
Я и спрашивал - можно ли иметь в разных ресурсах два "алтера" на один интерфейс
"
Можно накомпилять хоть в 100 ресурсов Alter-ов одно и того же инте-са, то подгружаться при работе в Галактике будет один какой-либо.

"
и два обработчика события на один скрин.
"
Обработчики событий связаны со скринами постоку поскоку...можно конечно в панели описать скрин и сделать панельный обработчик. Нужно просто понять просто правило - табличные события описываются в tableevent, оконные - в окошковых . Если Вы укажите в screen-е table блаблабла, то все табличные события, которые Вы будите генерить при работе в этом визуальном формате будут улетать в описанный tablelevent блабла.
Другое дело что Вы, в конкретные координаты этого скрина, например, можете встраивать/связывать по условию экранные элементы других интер-фейсов, и ес-но, тогда работа в этом визуальном формате будет организована по правилам обработчика событий, встроенного интр-са.

[Алексей]

Ну можно было не все. Есть инклюды дефайны объекты

Я и спрашивал - можно ли иметь в разных ресурсах два "алтера" на один интерфейс и два обработчика события на один скрин.
Причем одна докомпиляция живет всегда, а вторую подключать поверх первой при необходимости.
Причем добавляю обработку событий, которые не изменяются в первой докомпиляции.
Ответ получен - "лучше не надо".
Если есть вариант - можно описать в двух словах?
Потому что.. сами знаете почему

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

[Шевцов Владимир]

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

Алексей, это я уже и сделал. Но мне как раз так и не нравится.
По сути это дублирование информации, которое создает разные проблемы.
Т.к. первоя докомпиляция должна всегда работать - почему последующие алтеры не могут в качестве исходного интерфейса тянуть стандартный+все подключенные меньшим приоритетом доработки?
Тогда по указанию inherited :: handleEvent - программа постепенно бы допрыгивала до самого ядра и все были бы довольны.

[m0p3e]

Ну а кто мешает собрать первую докомпиляцию в ресурс и при сборке второй интерфейс брать из только что созданного ресурса?
OpenResources играем...

[Алексей]

Владимир, Эдвард верно объяснил, когда вы докомпилируете интерфейс, он собирается в ресурс ВЕСЬ. Даже внося минимальное изменение, компилятор пихает туда весь интерфейс из подключенных ресурсов где он живёт + ваше изменение. Т.е. нет такого что вы добавили кнопку, гал-ка подгрузила стандартный, увидела в другом интерфейсе вашу кнопку и добавила. Она либо возьмёт интерфейс из стандартного ресурса целиком, либо целиком из вашего.

Кстати я так и не понял, что вам не нравится в том, как Вы сделали... размеры ресурсов напрягают?!

[Шевцов Владимир]

Алексей, ну как бы не нравится мне что я должен пихать в новые доработки все предыдущие, которые и без того работают.
В итоге иметь одинаковые куски кода в разных местах, усложненную процедуру установки прав, удвоение работы по корректировке файлов в случае изменений базовых ресурсов. И это всего две донастройки. А если понадобится их несколько вариантов поддерживать..
И вообще, не по программистки это как-то.
Попробую поиграть с openresources, как советовал предыдущий оратор.

[edward_K]

по программистки нужно добавить пользовательскую настройку и в зависимости от нее плясать. А одинаковые куски кода должны лежать в одном файле всегда, а не в разных. CreateTune.vih смотрите.