я в Delphi делал так... («Телесистемы»: Конференция «Микроконтроллеры и их применение»)

Разработка, производство и продажа радиоэлектронной аппаратуры

| Карта сайта | Пишите нам | В избранное

Требуется программист в Зеленограде
- обработка данных с датчиков; ColdFire; 40 тыс.
e-mail:jobsmp@pochta.ru

Телесистемы | Электроника | Конференция «Микроконтроллеры и их применение»

я в Delphi делал так...

Отправлено A_R_V (172.20.20.23,87.117.1.141) 11 февраля 2011, г. 10:48
В ответ на: в BCB6 как сделать, чтобы динамически изменять подписи элементов (Label и Captions и т.д.) на разных языках ? Можно тупо через массив указателей, но хотелось бы встроенными средствами IDE отправлено MegaJohn 11 февраля 2011, г. 09:43

каждый компонент имеет уникальное свойство Name - латинскими буквами, это поле совпадает с идентификатором соответствующего объекта в программе. так вот, я написал в методе OnCreate формы функцию, которая просматривает все дочерние компонеты (контролы) формы и записывает в ini-файл в группу [Form.Name] строки вида Controls[i].Name = Controls[i].Caption
то есть получается что-то типа
Label13=Введите число:
это делаю для каждой формы. тогда после запуска программы создается ini-файл, в котором выписаны все элементы управления и их соответствующий текст.

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

итак, мультиязычность делается так:
1. пишем прогу по упомянутым правилам
2. запускаем ее, она создает файл типа default_lang.ini
3. после запуска полученный Ini-файл дублицируем нужное кол-во раз и правим каждую строку, переводя текст на нужный язык. файлы переименовываем в english_lang.ini и т.д.
4. добавляем в прогу функцию установки языка, которая открывает указанный ей ini-файл и делает свои черные дела.
5. если кроме интерфейса надо что-то еще транслировать на другой язык - это делается аналогично в том же ини-файле...

не знаю, понятно ли объяснил...

Составить ответ | Вернуться на конференцию

Ответы

Ужос! У каждого элемента есть специальное поле Tag, в котором удобно хранить номер строки, все пронумерованные строки хранятся в языковом ini-файле. Не надо вытаскивать имена компонентов в файл :) - Токовый клещ (11.02.2011, 11:52:46 95.25.192.31, пустое)
- к тому же поле Tag очень удобно для других целей :) - A_R_V (11.02.2011, 12:10:1 172.20.20.23,87.117.1.141, пустое)
- ага, особенно удобно потом по номеру вспоминать, что к чему... добавить новый компонет - надо вспомнить номер самого большого Тега, чтобы не дай бог не задвоить... мой метод - практически полная автоматика, а ваш - один гемор... - A_R_V (11.02.2011, 12:08:40 172.20.20.23,87.117.1.141, пустое)
  - Гемор - это не иметь мозгов :) Сначала лезешь в файл и дописываешь ещё одну строку в самый конец, и только потом этот полученный номер пишешь в tag - Токовый клещ (11.02.2011, 12:42:52 95.25.192.31, пустое)
    - там, где обычно бывает гемор - там мозгов и быть не должно :))) а если Tag уже занят - тогда как быть? ;) - A_R_V (11.02.2011, 13:00:33 172.20.20.23,87.117.1.141, пустое)
      - а что у тебя там? - Токовый клещ   (11.02.2011, 15:16:5 95.25.192.31, пустое)
        
        хотите об этом поговорить? ;-) - A_R_V   (11.02.2011, 15:50:1 172.20.20.23,87.117.1.141, пустое)
        
        да я не о твоих мозгах cпрашиваю, а о поле Tag :) Чо ты там хранишь, если оно у тебя занято? - Токовый клещ   (11.02.2011, 16:06:59 95.25.192.31, пустое)
        
        а я ою этом поле и говорю :))) - A_R_V   (11.02.2011, 16:17:52 172.20.20.23,87.117.1.141, 680 байт)
        
        То-то я удивился, откуда нашлось применение полю Tag, которое при правильном программировании не находит осмысленного применения кроме случая локализации строк. - Токовый клещ   (11.02.2011, 16:30:8 95.25.192.31, 310 байт)
        
        а если не должен видеть? ;) поле Tag мною еще и для хранения указателей используется - самое оно... у меня мышление узкими рамками не ограничено :)))) - A_R_V   (11.02.2011, 19:47:38 87.117.1.198, пустое)
        
        это вообще клинический случай :) - Токовый клещ   (11.02.2011, 21:02:12 95.25.192.31, пустое)
  - Можно предложить ещё вот что: - Тумблер (11.02.2011, 12:24:38 194.190.167.185,194.190.160.201, 452 байт)
    - не такой уж он и возможный... добавить параметр к готовым компонентам нельзя, придется делать наследника - а это будет гемор почище написания самой программы... - A_R_V (11.02.2011, 12:33:41 172.20.20.23,87.117.1.141, пустое)
      - Для Борландов - да, а для MS VC самое то. - Тумблер   (11.02.2011, 12:41:31 194.190.167.185,194.190.160.201, пустое)
        
        Это как? Не создавая нового компонента, ты его модифицируешь неведомым образом (runtime!), и далее имеешь возможность визуального конструирования формы?! Похоже на безграмотно-понтовый бред поклоника мелкософта. - POV   (11.02.2011, 13:23:15 217.150.45.109, пустое)
        
        Что за глупости ? Можно унаследоваться от любого класса и добавить новые свойства и методы. - Тумблер   (11.02.2011, 13:53:45 95.143.115.166, пустое)
        
        Например, наследуемся от класса TThread и делаем класс-поток для конкретной задачи. - Тумблер   (11.02.2011, 14:00:34 95.143.115.166, пустое)
        
        Так это всё делатся идентично в любой системе. Причем тут/борланды/мелкософты? - POV   (11.02.2011, 14:00:7 217.150.45.109, пустое)
        
        Вероятно, не совсем - Тумблер   (11.02.2011, 14:05:11 95.143.115.166, 427 байт)
        
        Компонент - это класс. От него наследуешь так же точно. Но для визуального проектирования новый компонет нужно проинсталлировтаь на паллитру компонентов. А в случае же динамического их создания не вижу разницы. Язык один и тот же. - POV   (11.02.2011, 14:09:46 217.150.45.109, пустое)
        
        Не спорю, но A_R_V считает иначе. :) - Тумблер   (11.02.2011, 14:13:19 95.143.115.166, пустое, ссылка)
        
        Правильно он считает. Я ж н сказал, что компонент модифицируется. Я сказал , что его надо проинсталлировать. Т.е. новый компонент с новыми возможностями. - POV   (11.02.2011, 14:29:42 217.150.45.109, пустое)
        
        проинсталлировать - это мелочи по сравнению с тем, что, например, в моей палитре компонентов 160 с гаком компонентов, и что, я должен их ВСЕ ПЕРЕОПРЕДЕЛИТЬ по-своему?! а у некотороых строковых полей БОЛЕЕ ОДНОГО, так что наследование будет очень непростым... это решение в стиле "разрушим до основания и построим с нуля лучше". - A_R_V   (11.02.2011, 15:06:16 172.20.20.23,87.117.1.141, пустое)
        
        Что за бред?! Если тебе нужно что-то новое, то ты наследуешь либо с нуля пишешь ручками. Или у тебя среда разработки с распознаванием мыслей? - POV   (11.02.2011, 15:36:22 217.150.45.109, пустое)
        
        у меня активно используется около 80 компонентов из имеющихся 160. сколько компонентов я должен переопределить, чтобы получить желаемое? ответ: ВСЕ 80 или 160! к сожалению, невоз-можно влезть в иерархию наследования, чтобы изменив только одного предка получить сразу во всех наследниках новые свойства. а дописывать все компоненты ручками - это пусть делает кто угодно, мне проще отказаться от мультиязычности интерфейса :))) - A_R_V   (11.02.2011, 15:49:12 172.20.20.23,87.117.1.141, пустое)
        
        Используй множественное наследование. - Тумблер   (11.02.2011, 16:56:31 95.143.115.166, 153 байт)
        
        особенно если учесть тот факт, что СТАРЫЕ компоненты ни сном ни духом не будут знать о существовании НОВЫХ МОДИФИЦИРОВАННЫХ, что сделает почти невозможным заложенное в них взаимодействие (если и его не переопределить, конечно) - A_R_V   (11.02.2011, 15:12:18 172.20.20.23,87.117.1.141, пустое)
        
        Бля. Ты об чём вообще? Я тебе про то, что если ты в своём проекте наследуешь от класса, то все изменения в исходном сами собой будут и в твойм детище. Но визуальное конструирование будет недоступно. Только ручками (в коде) объект на форме размещать. - POV   (11.02.2011, 15:37:56 217.150.45.109, пустое)
        
        Думаю, совсем легко сделать так : - Тумблер   (11.02.2011, 14:19:1 95.143.115.166, 278 байт)
        
        боюсь, что если бы вы не ограничились только размышлениями, вы бы поняли бессмысленность этого подхода в смысле трудозатрат... - A_R_V   (11.02.2011, 15:08:14 172.20.20.23,87.117.1.141, пустое)
        
        Да я делал подобное неоднократно. 80 контролов ? Да, это не даром. Но и ничего особенного. - Тумблер   (11.02.2011, 16:48:32 95.143.115.166, пустое)
        
        Кстати, вот подсчитал - в одном из последних моих проектов 168 .cpp файлов (классов), многие из них - именно контролы. - Тумблер   (11.02.2011, 17:00:4 95.143.115.166, пустое)
        
        я не спорю, классы, файлы - это хорошо. но делать такое количество только ради генерации иностранных строк?! ведь предложенный мной подход избавляет именно от этой тупой необходимости... раз - написал функцию, два - откорректировал файлы, три - написал еще одну функцию и интегрировал ее в интерфейс. и все. и более никаких забот - не надо ни классы переопределять, ни чего-то еще... что вы спорпите? вам охота делать лишнюю работу? делайте. мне не охота - и я не делаю. оплачиваемая лень - двигатель прогресса, а не неоплачиваемое трудолюбие :))) - A_R_V   (11.02.2011, 20:19:8 87.117.1.198, пустое)