Проблема с русским шрифтом в Caption элементов Visual C++ 6.0

[FallenSoul]

Добрый день.

Тема наверняка уже поднималась, но не нашёл. Когда размещаю элементы (Static Text, Group Box) на шаблоне окна и задаю им Caption- отображается нормально, однако при запуске приложения после компиляции на их месте иероглифы. Искал по опциям проекта и шрифтов приложения,- без результатов.

MFC проект.

[Алексей++]

когда только создаётся проект, там все уже созданные ресы имеют свойство язык - English. У ВСЕХ ресов поменяй на русский, сохрани (все надписи, которые уже покоцаны - придётся переписать)

[FallenSoul]

Спасибо. Переписывать кстати ничего не пришлось, а за MFC и в самом деле сила Намного удобнее чистого API

[Алексей++]

дык!

Только не пользуйся UpdateData(0/1) , вообще не пользуйся, а то внезапно разочаруешься А этого никак нельзя

[FallenSoul]

Незнаю что связано с UpdateData, но перед присваиванием Static Text'у строки,

Код:

m_StaticSumma.SetWindowText(buf);

без этого не получается,-выдаёт 0 в таком случае.

Попробовал объявить переменную типа CString для этого элемента, и присваиванием

Код:

m_Summa=buf;

, но не получилось.

Так об чём разговор был про UpdateData, и мб как-то предпочтительнее можно делать присваивание строк тому же Static Text'у?

[Алексей++]

Код:

GetDlgItem(IDC_mystatic)->SetWindowText(buf);

[Джон]

Только не пользуйся UpdateData(0/1) , вообще не пользуйся, а то внезапно разочаруешься

Суеверия всё это. Нормально всё работает. В конечном итоге она просто вызывает DDX макросы и всё сводится к тому же SetWindowText.

FallenSoul, у тебя нет связки твоего объекта с ресуром. Именно это делает макрос DDX_Control. GetDlgItem(IDC_xxx) позволяет напрямую обратится к контролу. Если ты хочешь только иногда обновить текст, то можно использовать GetDlgItem, если же нет, то лучше сделать объект мембер. Более того, ты никуда не денешься, если захочешь сделать контрол, наследованный от стандартного. Например CEdit.

[Алексей++]

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

[Джон]

Они требуют привязки объекта к ресурсу. А как ты это быстро по другому сделаешь?

Я не отрицаю, что механизм DDX не панацея на абсолютно все случаи жизни. Всегда можно придумать условия, при которых любая ф-я не будет корректно работать. И чем сложнее ф-я, тем шире спектр таких условий. Это как раз именно то, в чём всегда MFC и обвиняют. Но при нормальном грамотном использовании всё работает великолепно. И не надо раньше времени запугивать. А может FallenSoul как раз-таки научится грамотно с ними обращаться и горя не будет знать. Надо только чётко себе представлять как работает механизм обмена данными от объекта к ресурсу и наоборот. Я лично НЕ использую этот механизм только в исключительных случаях (даже затрудняюсь примеры привести, пожалую только когда действительно надо редко или примитивно обращаться к контролу). И очень часто использую адаптированные для моих нужд макросы. Например, при проверке граничных значений показывать сообщение не окошке, а выводить в статик на диалоге рядом с контролом. Или проверка экзотических значений. Или, что очень часто случается, когда отображаемое значение не совпадает с реальным значением. Например, комбобокс со скоростями для плоттера. Пользователь видит в комбобоксе "быстро" "медленно" "нормально", а реально это команды VS1 VS2 VS3. Ну и тд и тп

[Алексей++]

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