Редактируемые ресурсы в Кларионовских программах

Разработка программ на пес его знает на чем
Правила форума
При написании вопроса или обсуждении проблемы, не забывайте указывать версию Clarion который Вы используете.
А так же пользуйтесь спец. тегами при вставке исходников!!!
Ответить
Гость

Сообщение Гость »

Не бейте сильно по голове. Вопрос такой:

Есть ли у кого-нибудь опыт по внедрению в программу, скомпилированную на Кларионе ресурсов, аналогичным ресурсам программ С++ и другим.
Ну, про внедрение ресурса с версией - это известно.
Картинки-иконки - тоже.
Диалоги, понятное, дело, не впихнешь.
Интересуют ресурсы типа "String Table", которые можно было бы использовать для задания надписей на кнопках, пунктов меню, промптов, стрингов и т.д.
Соответственно, чтобы конечный пользователь уже в готовом EXE/DLL мог эти ресурсы редактировать (например - с целью создания иноязычного интерфейса программы).
То есть, интересует, во-первых, сам факт возможности вынедрения таких ресурсов. И во-вторых, способ увязки значения строки по идентификатору с переменной, задающей текст на экране или в отчете.

WBR, Игорь Смирнов.

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

Это решается проще. См. глобальные настройки ABC.
Иконки можно подменять, если их скомпилировать в отдельную DLL и заменять
стандартную на кастомизированную (это если не кидать их просто под ноги).

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

Prop:Use, Prop:FEQ

WBR, Nick Tsigouro mailto:nick@arsis.ru

Стоп-стоп. Вопрос был совсем не об этом.
Во-первых, иконки (и картинки) не интересуют вообще (к тому же их можно изменять и так - с помощью любого редактора ресурсов - хоть MS Visual Studio, хоть Restorator, хоть Catalyst).
Вопрос был о том, чтобы конечный пользователь (у которого нет Клариона и нет исходного Кларионовского проекта) мог изменить строковые ресурсы в уже готовом, скомпилированном модуле. Например, для нужд локализации (то есть, изменения языка интерфейса программы).
Пример. Есть, допустим, EXE, слепленный на MSVC++. Я могу открыть этот EXE Restorator'ом, найти там в строковых ресурсах значения "Yes" и "No" (которые отображаются на кнопках при работе программы) и заменить их на "Да" и "Нет". После сохранения этого EXE я получаю уже иноязычный интерфейс.
При этом у меня нет исходных кодов программы, и мне нет нужды связываться с разработчиком и клянчить у него "ну, пожалуйста, скомпилируй для меня другую DLLку...."
Я и спрашиваю - возможно ли так реализовать Кларионовскую программу?

Igor Smirnov

Да, можно. Только редактор ресурсов не нужен. Любым текстовым редактором правится текстовый файл перевода. Можно предусмотреть и подключение новых язфков.

WBR, Nick Tsigouro mailto:nick@arsis.ru

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

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

Посмотри, как это сделано в Linder Setup Builder...

---------------------------------------
C уважением,
Юрий Философов,
Главный программист
Корпорация "Диполь", Саратов
E-mail yufil@tacis-dipol.ru (служ)
yufil@mail.ru (дом)
ICQ#75924439

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

Для этого в Кларион существую шаблоны локализации.
Выбор достаточно велик: от стандартного для ABC до "самопальных".
В свое время я кидал такой в эху. (правда новую версию с динамической сменой языка никак руки не доходят довести)

------------------------------------------------------------
Igor Gubin (igor@quantor.com)
Quantor-Soft Metal
Phone/Fax: (+7 095) 234 4905
WEB: http://www.metaldata.info
http://www.metaldata.ru

1. Кажется в ABC-шных шаблонах есть класс позволяющий для контролов задавать языковые пары.
2. Как насчет GNU gettext? Программа в зависимости от системной локали меняет язык интерфейса. Кто-нибудь думал о связывании этой библиотеки с кларой?

--
Best regards,
Maxim Yemelyanov,
Enigma Soft Company
phone: (057) 7177977
WEB: http://enigmasoft.com.ua
e-mail: clalist@enigmasoft.com.ua
ICQ: 12253836

Да, можно. Только редактор ресурсов не нужен. Любым текстовым редактором правится текстовый файл перевода. Можно предусмотреть и подключение новых язфков.

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

В-общем, подводя итоги, делаем вывод: на поставленный вопрос ответа не было, но вместо этого был предложен так называемый Workaround - обход проблемы другим методом.

Для этого в Кларион существую шаблоны локализации.
Выбор достаточно велик: от стандартного для ABC до "самопальных".
В свое время я кидал такой в эху. (правда новую версию с динамической сменой языка никак руки не доходят довести)

Такой вариант все равно предусматривает "привязку" программы к разработчику - точнее, к настроенной среде разработки. И задача локализации полностью ложится на разработчика - то есть, порядок действий будет таким:
1) Разработчик распространяет в текстовом виде строки для перевода.
2) Какие-то энтузиасты делают перевод и присылают эти тексты ему обратно. Причем, вариантов много - для нескольких языков.
3) Разработчик заново для каждого языка перекомпилирует свою программу и рассылает готовые EXE/DLL клиентам.

При разработке новой версии программы все повторяется.
И т.д.

Igor Smirnov

(Добавление)

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

Ну ежели на тормоза нарвешься, то можно маленько переделать технологию.
Грузи при старте файл в очередь и работай с ней. Или закажи буферов столько, чтобы весь файл влез. Кстати с INI так и происходит. Он при открытии считывается в память, а записывается на диск при завершении проги.

В-общем, подводя итоги, делаем вывод: на поставленный вопрос ответ а не было, но вместо этого был предложен так называемый Workaround - обход проблемы другим методом.

Да ответ то простой. Не используются в Клаше отдельно компилируемые ресурсы,
поэтому и редактировать нечего.

WBR, Nick Tsigouro

Тормозов при СЧИТЫВАНИИ файла нет. Тормоза бывают когда открывается окно с большим количеством контролов (порядка 100). Тогда тормозит именно прорисовка (засекал). Выход в отказе от стандартного шаблона в этом окне: в моем случае большая часть контролов не нуждалась в локализации и локализацию в этой процедуре я писал ручками. Но это было еще во времена 486. Теперь тормозов не встречал.

------------------------------------------------------------
Igor Gubin

В-общем, подводя итоги, делаем вывод: на поставленный вопрос ответа не было

Отвечаю на поставленный вопрос.
1. Возможности сохранять сроки в ресурсы как таковые в Clarion нет и видимо не предвидется, поскольку не больно то и нужно.

2. Реализовать такие строковые "ресурсы" очень просто. Как, наверное, без того понятно, это глобальные строковые переменные (доступ к которым в DLL (например) можно получить либо экспортируя их, либо возвращая какой-нить спец.функцией GetResourceString(LONG StringID) ) :)

3. Редактировать ресурсы в EXE/DLL это уже хакинг, и сильно сомневаюсь, что после исправления "No" на "Нет" что либо будет работать. Подобным образом руссифицированные программы обычно вынуждены содержать переведенную строку размером не превышающую оригинал.

4. Использование строк-ресурсов для мультиязыковой поддержки для Clarion программ не есть стандартный вариант, хотя легко реализуемый (см. 2). Есть достаточно стандартных вариантов для нормальной мультиязыковой поддержки в Clarion приложении.

Удачи!
__________________________________
Владимир Якимченко (IСQ 16 993 194)

1) Разработчик распространяет в текстовом виде строки для перевода.
2) Какие-то энтузиасты делают перевод и присылают эти тексты ему обратно.
Причем, вариантов много - для нескольких языков.
3) Разработчик заново для каждого языка перекомпилирует свою программу и рассылает готовые EXE/DLL клиентам.

Отнюдь. СЭЭЭЭЭРРРР!
В моей версии (в отличии от стандартной) ВЕСЬ текст хранится во ВНЕШНЕМ текстовом файле (формат похож INI). Текст считывается во время открытия окна.
И для локализации вовсе не надо перекомпилировать программу. Клиенту достаточно открыть файл локализации ЛЮБЫМ редактором. Лучше всего подходит Notepad.
Если необходимого текста в файле нет - программа сама его туда допишет. Клиенту останется только доперевести.

Igor Gubin

Посмотри, как это сделано в Linder Setup Builder...

Ну, если программа так и так использует Дикшнери и к ней при сборке прилинковывается драйвер БД, то этот вопрос кое-как решаем.
Но ради комплектации программы дополнительным файлом БД добавлять к ней лишние килобайты драйвера этой БД.... Кларионовские программы
(в локальном варианте сборки) и так отличаются значительным весом...
На самом деле идеальным был такой вариант - тексты всех контролов задаются через переменные.

Например:
Имеется переменная GLO:Txt, представляющая собой CSTRING-массив с N измерениями (ну, сколько реально надо - может 50, может 100)
Отработка - по событию открытия окна.
?ButtonNext{PROP:Text}= GLO:Txt[25]

Соответственно, в начале программы надо этот самый массив GLO:Txt "набить" значениями, взяв их откуда-то...
Вот и вопрос в том - откуда? Если из внешнего текстового файла, то это очень утомительно по времени для процессора. Из внешней БД -
во-первых, лишний драйвер в памяти; во-вторых, у конечных пользователей вряд ли окажется средство чтения экзотических файлов TPS.
Можно, конечно, использовать более-менее стандартный драйвер DBF, но, ИМХО, с ним тормозов будет еще больше.

Самое интересное, что в скомпилированный Кларионовский ЕХЕшник можно (!!!!!) добавлять ресурсы. В том числе и строковые.
Но как бы их читать в самой программе???

Igor Smirnov

Но ради комплектации программы дополнительным файлом БД добавлять к ней лишние килобайты драйвера этой БД.... Кларионовские программы (в локальном варианте сборки) и так отличаются значительным весом...

А режим отладки при сборке был выключен?

[q[Вот и вопрос в том - откуда? Если из внешнего текстового файла, то это очень утомительно по времени для процессора.[/quote]
Ну не больше же, чем exe-шник надо считать. Стало быть и время загрузки будет не больше. А если начнет тормозить, то есть буфферизация и чтение через WinAPI, а не через кларин драйвер.

- во-первых, лишний драйвер в памяти; во-вторых, у конечных ...

Если он лишний, что ьывает редко, то WinAPI.

... пользователей вряд ли окажется средство чтения экзотических файлов TPS.

TopScan можно поставлять в комплекте с прогой. Личензия позволяет. А все культурные рантайм переводчики интерфейса содержат спец редактор для создания/редактирования переводов.

Можно, конечно, использовать более-менее стандартный драйвер DBF, но, ИМХО, с ним тормозов будет еще больше.

Не надо мудрить лишнего. Проблема была решена еще во времена CW20 и SX проциков с частотой 25-33 Мгц. Правда с мелкими шероховатостями.

WBR, Nick Tsigouro

Ну, в свое время (помнится, гда два или четыре назад), втставал вопрос о прилинковывании к Кларионовскому ЕХЕ/DLL ресурса с информацией о версии (ну, в Проводнике по правой кнопке мыши - Свойства, Версия). Тоже поначалу говорили "нельзя", "не используется"....
Оказалось, что вполне можно. И более того - кто-то разработал соответствующие шаблоны. И не один разработчик, а несколько - выбирай на вкус, как говорится.
Чуть попозже и номер билда научились в ресурс версии прописывать. А ведь тоже поначалу говорили, что невозможно.
Вот ресурсы с картинками-иконками-курсорами Кларионовские программы же используют. То есть, где-то в ЕХЕ прописывается обращение типа "показать иконку с таким-то идентификатором". И обращение-то это идет не к какому-то внешнему файлу, а к своим "родным" ресурсам.
Так что я считаю, что можно научиться читать (и показывать на экране и в распечатке) ресурсы и стрингового типа.
Голова только умная нужна. К сожалению, моя голова умна не настолько. :(

Igor Smirnov
Написал: ClaList(2)

Гость

Сообщение Гость »

3. Редактировать ресурсы в EXE/DLL это уже хакинг, и сильно сомневаюсь, что после исправления "No" на "Нет" что либо будет работать.
Защищенные проги точно не будут. Они контроллируют собственную целостность, да так просто такую прогу не декомпилируешь, и обратно не соберешь.
Чуть попозже и номер билда научились в ресурс версии прописывать.
А ведь тоже поначалу говорили, что невозможно.
А разве это средствами языка Кларион делается? Разве при этом используется компилятор ресурсов? Нет тупо генерится бинарник. Отсюда масса ошибок и глюков в этих разработках. Кто-то не разобрался со структурой и имеем неизвестно что.
Опять же, это стандартный виндовый ресурс который обязан быть. Он же не для юзанья в клаше делается.
Вот ресурсы с картинками-иконками-курсорами Кларионовские программы же используют. То есть, где-то в ЕХЕ прописывается обращение типа "показать иконку с таким-то идентификатором". И обращение-то это идет не к какому-то внешнему файлу, а к своим "родным" ресурсам.
Единственное счастливое исключение, т.к. без него было бы совсем грустно. И то работает в мультиDLL кривовато.
Так что я считаю, что можно научиться читать (и показывать на экране и в распечатке) ресурсы и стрингового типа.
А зачем? Чем глобалы вынесенные в отдельную DLL не устраивают? Только тем, что не декомптлируются и не правятся юзером? А может это в какой-то степени благо и позволяет отдавать ему на редактирование только то, что _мы_ считаем возможным отдавать, а не то, что ему хочется?

WBR, Nick Tsigouro

Некоторые сообщения можно и *.ENV например CLABUTTON="Да".......
Некоторые сообщения можно через переменные запихать в INI фаил

Liudvikas Jagucanskis lwj@wireless.lt

(Добавление)
Защищенные проги точно не будут. Они контроллируют собственную целостность, да так просто такую прогу не декомпилируешь, и обратно не соберешь.
Ну вот только перегибать не нужно в этом вопросе.
Я ж говорю - моя основная работа (то, за что я хлебушек с маслицем кушаю) - это локализация ПО.
Так что на редактировании ресурсов в скомпилированных библиотеках я не одну собаку съел.
Более того - производители того софта, с которым я так, по мнению некоторых, хакерски поступаю, сами в своих инструкциях по локализации пишут: Откройте DLL в MS Visual Studio в режиме редактирования ресурсов. Исправьте строки, отредактируйте диалоги. При необходимости можете изменить размеры контролов, если строка на Вашем языке не помещается.
И так далее, и тому подобное.
Так что редактирование ресурсов в готовом исполняемом модуле - никакой не взлом и никакое недокументированное дело, а самая обычная работа.
Относительно защищенных программ (а также упакованных всякими АСПаками и прочим) - говорить не будем.
2. Реализовать такие строковые "ресурсы" очень просто. Как, наверное, без того понятно, это глобальные строковые переменные (доступ к которым в DLL (например) можно получить либо экспортируя их, либо возвращая какой-нить спец.функцией GetResourceString(LONG StringID) )
О! Вот это - здравая идея.
Срочно лезем в MSDN и ищем подходящую API-функцию (если таковая имеется)

Igor Smirnov
Написал: ClaList(2)

Гость

Сообщение Гость »

Пару лет я назад я уже выдирал из любого exe или dll список всех ресурсов (мне нужны были правда только иконки (тип RT_14)

Сейчас немного подрихтовал, чтобы строковые ресурсы тоже вытаскивались.

Лови проектик

--
С уважением,
Дмитрий Осипов mailto:Dima_Osipov@km.ru
ICQ 14543897
Написал: ClaList(2)

Гость

Сообщение Гость »

Спасибо!!!!!

Igor Smirnov
Написал: ClaList(2)

Гость

Сообщение Гость »

Классная вещь!
Правда, почему-то отлавливает не все ресурсы - часть пропускает.

Игорь Смирнов
mailto:igor.smirnov@documentum.ru
Написал: ClaList(2)

Ответить