DoDataExchange обновит вообще контролы и переменные, нафик это надо?

DJStealth все абсолютно правильно написал.

прикол в том, что особой пользы от т.н. "объектности" MFC я не чуствую...
и не только я...

посему обычно пользуюсь таким:



да, вот так, грубо и без проверок! :), даже на ассемблере не получу более лаконично.

обоснования "грубого подхода":
----------------------------------
1. если я написал int x=2*2; где x-локальная переменная, то я не стану в следующей строке писать if(x==4) {...}
т.е. если я нарисовал некий диалог, присвоил некое IDC_XXX контролу и диалог успешно загружен, мне этого достаточно.
(эта тема, в принципе, достойна отдельного обсуждения, когда надо ловить ошибки, а когда ловить ошибки ВРЕДНО)

2. WinAPI не выбрасывает exceptions, а возвращает целые коды ошибок, посему для отладочных целей вполне подойдет макрос VERIFY(SOME_API_CALL), который ничего не делает в релизе, т.е. вышестоящее можно просто завернуть в этот VERIFY().

--------
2 Ой Вэй

убивать, не убивать за такое... да как хошь, блин...
Компилятор скомпилит это как надо, static_cast при отсутствии множественного наследования или в случае преобразования от/к первому в списке базовых классов не играет рояли и нужен для того, чтобы компилятор не ругался. Да, SetWindowText , определенный в CWnd не переопределен в CEdit , и что, блин???? Ведь логически, если просто из документации известен факт наследования, отсюда не вытекают подробности реализации, это все тонкости WinAPI , которые прикладному программисту И НАФИК НЕ СДАЛИСЬ (тупое, нелогичное API).

Как программист, ориентирующийся на документацию, а не на исходники этого тупорылого MFC , DJStealth сделал ВСЕ ПРАВИЛЬНО , и тебе рекомендую начать пользоваться правилами "хорошего тона" при программировании на С++, независимо от познаний в WinAPI.

GetDlgItem() на статическом диалоге — свинство. Имеет полное право вернуть NULL.
Не имеет! Если ТЫ САМ проектируешь диалог, то прочти про 2x2 в первой части поста.

Чтобы этого не происходило, можно ассоциировать Edit'ы с переменными типа Control, т.е. окошками, и вызывать их SetWindowText().
vdimas скажет, что это лишняя память, и будет снова прав.
Да фиг с ней с памятью под контрол. Но засорять статические MFC-map-ы (тупые и жутко медленные map-ы) и производить subclassing ради 2-х строк использования в программе ... сорри, я на это не готов...

да и память, опять же...

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

2 Ой Вэй
Но засорять статические MFC-map-ы (тупые и жутко медленные map-ы) ...
Это, пожалуйста, поподробнее, а то я так дураком и умру.
Контрольный вопрос: сколько должно быть на диалоге edit'ов (все со статическими map'ами), чтобы на машине типа пентиум100 вызов DoDataExchange() занял 1 секунду?

Не ожидал подобного, тем более после демонстрации знаний внутренного устройства MFC... А как вообще каждое сообщение Wndows обрабатывается для subclassed контролов в MFC? И сколько сообщений в секунду получает твое приложение?

Готов послушать твои правила (только не надо посылать меня в поиск, я умею им пользоваться. И WinAPI тоже частично знаю).
Речь шла о том, что не стоит пользоваться знаниями об внутреннем устройстве библиотек, если это устройство не декларируется. Напр. в будущих версиях разработчик может поменять внутренние подробности, и твоя прога может не заработать (это общее правило).

static_cast - это тоже правило хорошего тона при преобразовании типов в C++, если корректность операции известна заранее. В данном случае именно так. В доке по MFC указаны диаграммы наследования, и MFC устроена именно так (внимание!!!), что, не смотря на то, что в ответ на GetDlgItem() приходит указатель на CTempWnd объект (если мы его не сабклассили), мы все-равно можем перевести его в указатель на некий тип MFC, соответствующий конкретному запрошенному windows-контролу (CEdit, например), и далее работать именно с ним.
Вот такие MFC-приколы...