Как узнать в каком ресурсе лежит программа?

[cruger]

Сергей Головчак
Сомнений в понимании назначения нет. Есть непонимание у меня - зачем это нужно вообще?

Такой, кхм, пристрастный допрос объясняется хотя бы тем, что в настоящее время в управлении разработки открыт проект по обеспечению поддержки пользовательских и партнёрских доработок. Наша цель - предоставить технологию (не только в виде инструмента, но и в виде регламента) доработок, позволяющую управлять этими доработками, устанавливать обновления на них и прочее.
Штука в том, что в настоящее время возможностей построения технологий своих доработок полно, но нет одной разумной, эффективной, эргономичной, поддерживаемой на уровне ядра по умолчанию. В итоге наблюдаем картину "кто в лес, кто по дрова". Конечно, существующие возможности никто обрубать не собирается, но мы хотим обобщить опыт и потребности пользователей и партнёров, и на основе этого обобщения предложить некий компромисс, покрывающий основные потребности.

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

Так же вопрос интересен ввиду того, что начиная с появления репозитария в Галактике внедрён компонентный (не в части именованных vip-компонентов, хотя это тоже, а в части ресурсов) подход. Который в частности требует: если объект появился в системе в составе какого-то компонента, то далее он может быть только в нём. Далее, нет новой версии объекта, есть новая версия компонента.

При таком подходе вопрос с тем, из какого же ресурса грузится интерфейс, вообще говоря не возникает. Конечно, существуют всякие userXX.res & debug.res, но если пользователь устанавливает всё через Менеджер обновлений, то он и не имеет возможности файловых манипуляций с ресурсами (на этапе установки). Смысл применения указанных ресурсов вообще пропадает.

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

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

[Peter]

Еще не подскажете, как подключить ресурс после загрузки Галактики, хочу реанимировать AddResourceByName.

Функция простая, все как писал Фёдор, но чтобы откомпилить нужны dcu-файлы Атлантиса.

[Peter]

Как все-таки подключить ресурс после загрузки Галактики. Это нужно только для облегчения отладки.

[m0p3e]

Фёдор Терсин
Вот теперь понятно. :)
Проблема возникает в случае, когда площадка, для которой выполнена доработка удалена и подключение ресурсов выполняет другой человек. В результате высылаешь новую версию ресурса, и тот самый другой человек забывает его подключить или подключает коряво. Начинается выяснение почему функционал работает не так. Механизм точной идентификации подключенного ресурса частично снял бы данную проблему.
А от себя могу предложить продумать механизм автоматического инкримента номера версии ресурса при сборке. Т.е. общий номер где-то лежит (та же самая директива #version), но компилятор добавляет номер сборки. При таком раскладе каждая сборка будет иметь свой уникальный номер. Но вот как это организовать технически - пока не представляю. Нужно поэкспериментировать - хочется систему удобную в работе. А не как репозиторий - вроде все есть, а пользоваться жутко неудобно.

Петр Кузьмин
dcu имеются. Если не жалко, вышлите на m0p3e(at)mail.ru. Даже если и не пригодится, то для общего развития лишним не будет. :)

[cruger]

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

А в чём заключается неудобство репозитария?

[cruger]

Петр Кузьмин
Вы компилируете отлаживамые интерфейсы в ресурсы со случайным именем???

[vadim]

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

IMHO, все давно организовано - на уровне ОС. Каждый вновь создаваемый файл имеет текущие (уникальные в общем-то) дату и время. Эти реквизиты видны в отчете о системе. Или нужно что-то большее?

[m0p3e]

Фёдор Терсин
Зашивать дату/время сборки в номер версии (по настройке, например Compilers.FullVersion=ON) вариант удобный, но слишком уж длинная версия получится. Z_Staff версия 8.10.69.0-20100210131259 - некрасиво, но лично для меня сняли бы много проблем. :)

С репозиторием так просто и не сформулируешь. Слишком шаткая система по сути своей.

Вадим Володько
Время/дату создания файла легко изменить. Хочется чего-то более надежного.

[cruger]

Сергей Головчак
Хех, версия 8.10 - это версия ресурсов Галактики, зачем вам её использовать?
По сути вам номер версии не нужен, важно лишь что бы он инкрементировался. Будет, например, какой-нибудь 2010.41.904.0 (год.номер_дня_в_году.минута_дня.0).

Помимо даты файла есть размер, его так просто не поменяешь.

Всё же попробуйте сформулировать что-то про репозитарий. В чём именно шаткость?

[larin]

Как все-таки подключить ресурс после загрузки Галактики. Это нужно только для облегчения отладки.

На мой в взгляд. Такой режим логичнее всего реализовать в отладчике VIPER.

VIPER уже сейчас умеет редактировать код, откомпилировать код, запустить на исполнение процесс Галактики, производить пошаговую отладку процесса Галактики.

Да, к сожалению Галактика довольно долго стартует.

Следующий шаг развития средств отладки VIPER хотелось бы сделать такой:

Когда уже запущен процесс отладки Галактики, продолжить редактировать код в VIPER, снова выполнить компиляцию, ресурс автоматически переподключится в запущенную Галактику, продолжаем отладку не тратя время на повторную загрузку.

Третий шаг развития отладчика VIPER можно опробовать сделать так, чтобы просто подключиться к Галактике в любой момент ее работы, когда идет длительный расчет (когда кажется, что ваш алгоритм просто завис или зациклился).

По момему мнению логично выделать задачи разработки в отдельную удобную удобную среду разработки.

Хаос с подключением не протестированных ресурсов в продуктивном окружении сразу в промышленную БД недопустим.

Программист должен тренироваться в разработке своих алгоритмов на тестовой копии БД. На отдельном наборе EXE-шников. В своей изолированной "Песочнице". Его разработки переносить на промышленную БД можно только поле выполнения формальных процедур тестирования.

На развитие VIPER нужно время.

[LnStep]

Напимер можно в Фейс вставить кнопку ВЕРСИЯ

Код: Выделить всё

...
  Buttons
  cmPRGVersion;
<<
  <. Версия? .>

...

cmPRGVersion : message('Трасляция на #__TOOLVERSION__ от #__DATETIME__');

А узнав версию Ресурсника что делать?!
Это надо каждый отданный Ресурсник Архивировать вместе с исходниками

[cruger]

Алексей Шунин
Так мы узнаем версию streams_.dll (или ecc_ - не помню сходу), с которой компилировался этот обработчик.