Добавлено: 27 Август 2004, 14:36
Не бейте сильно по голове. Вопрос такой:
Есть ли у кого-нибудь опыт по внедрению в программу, скомпилированную на Кларионе ресурсов, аналогичным ресурсам программ С++ и другим.
Ну, про внедрение ресурса с версией - это известно.
Картинки-иконки - тоже.
Диалоги, понятное, дело, не впихнешь.
Интересуют ресурсы типа "String Table", которые можно было бы использовать для задания надписей на кнопках, пунктов меню, промптов, стрингов и т.д.
Соответственно, чтобы конечный пользователь уже в готовом EXE/DLL мог эти ресурсы редактировать (например - с целью создания иноязычного интерфейса программы).
То есть, интересует, во-первых, сам факт возможности вынедрения таких ресурсов. И во-вторых, способ увязки значения строки по идентификатору с переменной, задающей текст на экране или в отчете.
WBR, Игорь Смирнов.
(Добавление)
Это решается проще. См. глобальные настройки 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 - обход проблемы другим методом.
Такой вариант все равно предусматривает "привязку" программы к разработчику - точнее, к настроенной среде разработки. И задача локализации полностью ложится на разработчика - то есть, порядок действий будет таким:
1) Разработчик распространяет в текстовом виде строки для перевода.
2) Какие-то энтузиасты делают перевод и присылают эти тексты ему обратно. Причем, вариантов много - для нескольких языков.
3) Разработчик заново для каждого языка перекомпилирует свою программу и рассылает готовые EXE/DLL клиентам.
При разработке новой версии программы все повторяется.
И т.д.
Igor Smirnov
(Добавление)
Ну ежели на тормоза нарвешься, то можно маленько переделать технологию.
Грузи при старте файл в очередь и работай с ней. Или закажи буферов столько, чтобы весь файл влез. Кстати с INI так и происходит. Он при открытии считывается в память, а записывается на диск при завершении проги.
Да ответ то простой. Не используются в Клаше отдельно компилируемые ресурсы,
поэтому и редактировать нечего.
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)
Отнюдь. СЭЭЭЭЭРРРР!
В моей версии (в отличии от стандартной) ВЕСЬ текст хранится во ВНЕШНЕМ текстовом файле (формат похож INI). Текст считывается во время открытия окна.
И для локализации вовсе не надо перекомпилировать программу. Клиенту достаточно открыть файл локализации ЛЮБЫМ редактором. Лучше всего подходит Notepad.
Если необходимого текста в файле нет - программа сама его туда допишет. Клиенту останется только доперевести.
Igor Gubin
Ну, если программа так и так использует Дикшнери и к ней при сборке прилинковывается драйвер БД, то этот вопрос кое-как решаем.
Но ради комплектации программы дополнительным файлом БД добавлять к ней лишние килобайты драйвера этой БД.... Кларионовские программы
(в локальном варианте сборки) и так отличаются значительным весом...
На самом деле идеальным был такой вариант - тексты всех контролов задаются через переменные.
Например:
Имеется переменная GLO:Txt, представляющая собой CSTRING-массив с N измерениями (ну, сколько реально надо - может 50, может 100)
Отработка - по событию открытия окна.
?ButtonNext{PROP:Text}= GLO:Txt[25]
Соответственно, в начале программы надо этот самый массив GLO:Txt "набить" значениями, взяв их откуда-то...
Вот и вопрос в том - откуда? Если из внешнего текстового файла, то это очень утомительно по времени для процессора. Из внешней БД -
во-первых, лишний драйвер в памяти; во-вторых, у конечных пользователей вряд ли окажется средство чтения экзотических файлов TPS.
Можно, конечно, использовать более-менее стандартный драйвер DBF, но, ИМХО, с ним тормозов будет еще больше.
Самое интересное, что в скомпилированный Кларионовский ЕХЕшник можно (!!!!!) добавлять ресурсы. В том числе и строковые.
Но как бы их читать в самой программе???
Igor Smirnov
А режим отладки при сборке был выключен?
[q[Вот и вопрос в том - откуда? Если из внешнего текстового файла, то это очень утомительно по времени для процессора.[/quote]
Ну не больше же, чем exe-шник надо считать. Стало быть и время загрузки будет не больше. А если начнет тормозить, то есть буфферизация и чтение через WinAPI, а не через кларин драйвер.
Если он лишний, что ьывает редко, то WinAPI.
TopScan можно поставлять в комплекте с прогой. Личензия позволяет. А все культурные рантайм переводчики интерфейса содержат спец редактор для создания/редактирования переводов.
Не надо мудрить лишнего. Проблема была решена еще во времена CW20 и SX проциков с частотой 25-33 Мгц. Правда с мелкими шероховатостями.
WBR, Nick Tsigouro
Ну, в свое время (помнится, гда два или четыре назад), втставал вопрос о прилинковывании к Кларионовскому ЕХЕ/DLL ресурса с информацией о версии (ну, в Проводнике по правой кнопке мыши - Свойства, Версия). Тоже поначалу говорили "нельзя", "не используется"....
Оказалось, что вполне можно. И более того - кто-то разработал соответствующие шаблоны. И не один разработчик, а несколько - выбирай на вкус, как говорится.
Чуть попозже и номер билда научились в ресурс версии прописывать. А ведь тоже поначалу говорили, что невозможно.
Вот ресурсы с картинками-иконками-курсорами Кларионовские программы же используют. То есть, где-то в ЕХЕ прописывается обращение типа "показать иконку с таким-то идентификатором". И обращение-то это идет не к какому-то внешнему файлу, а к своим "родным" ресурсам.
Так что я считаю, что можно научиться читать (и показывать на экране и в распечатке) ресурсы и стрингового типа.
Голова только умная нужна. К сожалению, моя голова умна не настолько.
Igor Smirnov
Написал: ClaList(2)
Есть ли у кого-нибудь опыт по внедрению в программу, скомпилированную на Кларионе ресурсов, аналогичным ресурсам программ С++ и другим.
Ну, про внедрение ресурса с версией - это известно.
Картинки-иконки - тоже.
Диалоги, понятное, дело, не впихнешь.
Интересуют ресурсы типа "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)