Русские шрифты в программе в среде с отсутствием поддержки русских шрифтов

[eugrita]

Программа разрабатывалась в нормальной среде например в Windows XP на C++ Builder с поддержкой
русских шрифтов Cyr, т.е в ее итерфейсе (подписях, названиях меню, справке) использовался русский язык. Надо  чтобы она корректно отображалась в том числе и при работе на компьютере скажем, в другой стране с отсутствием русскоязычной поддержки.

Какие могут быть в этом случае рекомендации? Только лишь сменить русский язык?  или как-то может
с самого начала разработки использовать Unicode ?
Сейчас знакомые в США, которым я передал программу не могут прочитать обозначения интерфейса
из-за проблем с русским шрифтом. Был передан лишь exe без всяких инсталляторов

[Джон]

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

[resource]

Я вот кстати изначально по книжкам пытался писать типа кроссс-код какой-то чтоли: <tchar.h> типы TCHAR, LPTSTR, макрос _T() и всё такое. Прошло с тех пор много время. Могу сказать что смысла в этом нет абсолютно никакого, наоборот даже иногда путаница возникает. Особенно для функций аля чегото_printf. Не известно порой что передавать %s или %S. Приходится писать #ifdef UNICODE и обрабатывать оба варианта. Короче гемморой. Лучше сразу писать в юникод с W-функциями. Разницы никакой серьезной в процессе написания не ощутишь. И получишь нормальный юникод в любом случае. Кстати говоря, многие (наверное даже очень многие)  ANSI-функции сначало переводят параметры в юникод и затем вызывают W-версию

[Джон]

Ага, разницы совсем никакой. А потом приходит к тебе клиент и говорит, а у меня в цеху Nr XYZ стоит двести компов с Win 98, а на них прога почему-то не запускается. Пожалуйста, к завтрему исправьте, а то у меня всё производство стоит и убытков от этого... по самое нихочу. В такие моменты понимаешь, что разница всё-таки есть, а смысл-то какой!

Поэтому лучше всё-таки с макросами и объектами, которые сами разбираются что к чему. Путаницы не возникает, если пользоваться чем-то одним. А "#ifdef UNICODE" самому обрабатывать действительно геморрой, это уже и так во всех макросах и типах сидит. Чего же более?

[eugrita]

"достаточно откомпилировать прожку в юникоде"
т.е как это в среде Borland C++Builder 6.0 или Delphi 7  откомпилировать в юникоде?

Чтобы как-то улучшить поддержку Unicode в Delphi 7 или BCB 6  Скачал TNT-компоненты,
Вроде по отзывам они работают с Unicode
Установил в интерфейсных элементах (TNTButton, TNTLabel,TNT Memo)
Font=Arial Unicode MS  
Не знаю будет ли это работать?
(насколько я понимаю, шрифт Arial Unicode MS
имелся в Delphi и BCB  еще до установки TNT-компонент)
Возможно я неправильно с ними работаю, не использую их возможности

[RXL]

eugrita, штатный VCL библиотеки в BCB6 и D7 используют 8-битные строки типа AnsiString, а юникодным соответствует тип WideString. Т.ч. смена шрифта не поможет. Надо читать доку на предмет использования юникода - может можно что-то сделать...

[resource]

Джон, это всё тебе 

Часть 1.  Ситу Ация

Вот тебе ситуация (я с таким на практике сталкивался не раз). Получаешь ты в своей программе строку откуда то извне. Не важно в чем эта строка, в юникод или анси. Главное в чём то одном (всегда) и заранее известно в чем, и поскольку строка эта извне то как бы ты не компилил с вою прогу (с #define UNICODE или без оного), на формат строки которая "извне" это никак не повлияет. Для конкретики предположим что строка "извне" в формате анси. На самом деле можно было и в юникод, смысла это не меняет, но чтоб всё таки на чем то остановиться пусть будет анси.

Часть 2. Макросы

Есть у тебя к примеру такой банальный момент:

Код:

_tprintf(_T("макросы это круто и я щас покажу эту строку: %s\n"), strIzvne);

Как видно вся проблема в %s. Если ты будешь компилировать эту прогу в юникоде, то получится лажа, ведь strIzvne в анси.
Это как раз то, о чем я и говорил. Придется тут вручную писать #ifdef UNICODE и всё сопутствующее. В итоге выигрыша от макросов тут никакого.

Часть 3. Win98 (а что это такое?)

Надо ли тут вообще чего то писать. Ну уж раз начали... Дело в том, что писать серьезный системный софт, совместимый как с 98 так и с XP (и выше) это само по себе уже не правильно, т.к. эти ОС различаются даже на уровне API, и не только. Эти системы вообще как чукча и китаец, оба от макрософт  , но реально разные. Если конечно ты не юзаешь API, то тут тебе проще. Но поддержка Win98 это дело такое.......в общем если тебе это выпало, то просто не завидую. Ну с другой стороны, хорошо хоть  не навесили  на тебя Win 3.x 

[Sla]

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

[Вад]

resource, никто же не мешает конвертировать всё, что приходит извне, во внутреннюю кодировку (если это Unicode - то в юникод, если это multibyte - то в мультибайт). Определить, куда конвертировать - тем же макросом. А конвертировать в любом случае придётся. Иначе лихой код

Код:

printf("я щас покажу эту строку: %s\n", strIzvne);

споткнётся на utf-8, или на чём похуже.

[resource]

Вад, ты не понял этот момент

А "#ifdef UNICODE" самому обрабатывать действительно геморрой, это уже и так во всех макросах и типах сидит. Чего же более?

Я изначально и говорил о том, что всё равно придется самому писать #ifdef UNICODE если работаешь со строками "извне". В том числе и при конвертировании. Ведь надо или не надо конвертировать строку зависит от того как ты скомпилил свою прогу, с UNICODE или без него.

Sla, разумно. И я согласен, что если ты работаешь исключительно со строками, определенными внутри своего кода, то макросы имеют смысл.

Ну поскольку я на win98 не ориентируюсь, то я сразу пишу конкретно юникодный софт

[Джон]

Джон, это всё тебе  

Часть 1.  Ситу Ация

Вот тебе ситуация (я с таким на практике сталкивался не раз). Получаешь ты в своей программе строку откуда то извне. Не важно в чем эта строка, в юникод или анси. Главное в чём то одном (всегда) и заранее известно в чем, и поскольку строка эта извне то как бы ты не компилил с вою прогу (с #define UNICODE или без оного), на формат строки которая "извне" это никак не повлияет. Для конкретики предположим что строка "извне" в формате анси. На самом деле можно было и в юникод, смысла это не меняет, но чтоб всё таки на чем то остановиться пусть будет анси.

Ну и что? Что ты пытаешься этим доказать? Речь не о ситуациях, а о изменении кода при возникших ситуациях. И если ты изначально используешь только только w-ф-ции или только ANSI-ф-ции, то тебе придётся переписывать код при необходимости. При использовании _t-ф-ций этого не придётся делать. Поспорь с этим.

Часть 2. Макросы

Есть у тебя к примеру такой банальный момент:

Код:

_tprintf(_T("макросы это круто и я щас покажу эту строку: %s\n"), strIzvne);

Как видно вся проблема в %s. Если ты будешь компилировать эту прогу в юникоде, то получится лажа, ведь strIzvne в анси.
Это как раз то, о чем я и говорил. Придется тут вручную писать #ifdef UNICODE и всё сопутствующее. В итоге выигрыша от макросов тут никакого.

CString stIzvne = CString(strIzvne);

и дальше работаю с stIzvne. Каждый решает (создает) проблемы в силу своей неграмотности. Но опять таки это к существу разговора не относится.

Часть 3. Win98 (а что это такое?)

Надо ли тут вообще чего то писать. Ну уж раз начали... Дело в том, что писать серьезный системный софт, совместимый как с 98 так и с XP (и выше) это само по себе уже не правильно, т.к. эти ОС различаются даже на уровне API, и не только. Эти системы вообще как чукча и китаец, оба от макрософт  , но реально разные. Если конечно ты не юзаешь API, то тут тебе проще. Но поддержка Win98 это дело такое.......в общем если тебе это выпало, то просто не завидую. Ну с другой стороны, хорошо хоть  не навесили  на тебя Win 3.x  

На это могу только сказать - отмазка плоская, ибо в стиле: "это не существует т.к. мне это не нравится". Если ты дествительно СЕРЬЁЗНО работаешь, то знаешь, что заказчику - единственному источнику твоих доходов - глубоко наср... на твои абмиции и твоё мнение. И ты делаешь так как он захочет, а не так как тебе нравится. Вот и вся философия.


Посему ещё раз, открытым текстом: использование макросов избавляет тебя от ненужного переписывания кода, если вдруг возникнет необходимость, а вот вреда от них за много лет я так и не увидел. Кстати, твои примеры тоже его не выявляют.

[resource]

CString stIzvne = CString(strIzvne);

и дальше работаю с stIzvne.

Посему ещё раз, открытым текстом: использование макросов избавляет тебя от ненужного переписывания кода.

Ну если CString для тебя это макрос, то это уже совсем бессмысленный разговор. И чего тут уже говорить о моей безграмотности.
Я в общем-то MFC хотя и не пользую, но вот интересно, как оно будет когда, инициализируешь CString строкой анси, но программа при этом скомпилирована с _UNICODE (или наоборот). В MSDN написано, что надо передавать строки обёрнутые _T(). Так, что есть подозрение, что всё это неправильно.

а вот вреда от них за много лет я так и не увидел. Кстати, твои примеры тоже его не выявляют

Я про вред ничего и не говорил. Я говорил о том, что макросы, порой не избавляют тебя от того чтобы вручную писать #ifdef UNICODE и всё сопустствующее (два варианта).

[Джон]

CString stIzvne = CString(strIzvne);

и дальше работаю с stIzvne.

Посему ещё раз, открытым текстом: использование макросов избавляет тебя от ненужного переписывания кода.

Ну если CString для тебя это макрос, то это уже совсем бессмысленный разговор. И чего тут уже говорить о моей безграмотности.

Где это я говорил о ТВОЕЙ безграмотности? В данном случае можно говорит только о невнимательности:

Поэтому лучше всё-таки с макросами и объектами, которые сами разбираются что к чему.

В данном случае CString - это объект, который сам умеет разобраться что к чему.

Я в общем-то MFC хотя и не пользую, но вот интересно, как оно будет когда, инициализируешь CString строкой анси, но программа при этом скомпилирована с _UNICODE (или наоборот). В MSDN написано, что надо передавать строки обёрнутые _T(). Так, что есть подозрение, что всё это неправильно.

А я не подозреваю, а пользую. И если что-то неправильно, то виной всему будет объект CString, а мой код останется неизменным.

а вот вреда от них за много лет я так и не увидел. Кстати, твои примеры тоже его не выявляют

Я про вред ничего и не говорил.

Ну... бессмыслицу и путаницу нельзя отнести к полезностям, отсюда - вред:

Могу сказать что смысла в этом нет абсолютно никакого, наоборот даже иногда путаница возникает.

Я говорил о том, что макросы, порой не избавляют тебя от того чтобы вручную писать #ifdef UNICODE и всё сопустствующее (два варианта).

Сначала ты сказал, что ПРИХОДИТСЯ, и предложил как лучший вариант использовать только юникодные ф-ции, с чем я категорически не согласился.

[resource]

И если что-то неправильно, то виной всему будет объект CString, а мой код останется неизменным.

Это если ты правильно используешь CString. Но вообще тут CString то и не при чем вовсе. Речь то о макросах.

Но раз уж тут каким-то образом возник CString, то еще раз

CString stIzvne = CString(strIzvne);

и дальше работаю с stIzvne.

Допустим что strIzvne в формате анси, а ты компилируешь программу в юникоде (т.е. #define UNICODE). CString ведь будет ждать в этом случае юникодную строку, а ты передаешь ему анси строку. Ну и ктож тут виноват.

[Джон]

И если что-то неправильно, то виной всему будет объект CString, а мой код останется неизменным.

Это если ты правильно используешь CString. Но вообще тут CString то и не при чем вовсе. Речь то о макросах.

Ещё раз (последний), внимательно читаем #3:

Поэтому лучше всё-таки с макросами и объектами, которые сами разбираются что к чему.