Создал проект с использованием MFC.
В констркторе класса приложения ( class CMfc2App : public CWinApp )

CMfc1App::CMfc1App()
{
//делаю следующее:
    CString s;
    s.LoadString( IDS_STRING1 );
    // можно показать эту стрчку : 
    // MessageBox(NULL,s,"",0);

    // TODO: add construction code here,
    // Place all significant initialization in InitInstance
}

в результате возникает ASSERTION.
Вопрос : почему ? Помогите пожалуйста.
ЗЫ Если это сделать CMfc1App::InitInstance — то всё в порядке

Здравствуйте, YuryK, Вы писали:

YK>Создал проект с использованием MFC.
YK>В констркторе класса приложения ( class CMfc2App : public CWinApp )


...
YK>ЗЫ Если это сделать CMfc1App::InitInstance — то всё в порядке
Tam etomu kodu samoe mesto

Здравствуйте, den123, Вы писали:

D>Здравствуйте, YuryK, Вы писали:

YK>>Создал проект с использованием MFC.
YK>>В констркторе класса приложения ( class CMfc2App : public CWinApp )


D>...
YK>>ЗЫ Если это сделать CMfc1App::InitInstance — то всё в порядке
D>Tam etomu kodu samoe mesto

спасибо, но почему нельзя?
в чём проблема использования функций библиотеки MFC(в моём случае — обращение к ресурсам) констркторе класса приложения?

Здравствуйте, YuryK, Вы писали:

YK>спасибо, но почему нельзя?
YK>в чём проблема использования функций библиотеки MFC(в моём случае — обращение к ресурсам) констркторе класса приложения?

V ctor InitInstance eshe ne sozdana (initializatsia i t.p.), a v CMfc1App::InitInstance InitInstance uze proinitializirovana i gotova k ispolz.

V ctor mozno sdelati, no cherez standard Win32 API, a ne cherez MFC.

D>V ctor mozno sdelati, no cherez standard Win32 API, a ne cherez MFC.

Win32 API — это конечно хорошо, но...
Я так понимаю, что не инициализированы какие-то внутренние структуры MFC ( специалисты, подскажите — какие? ), —
ведь суть проблемы именно в этом! —
и может их можно "принудительно" проинициализировать каким-нибудт Afx*** вызовом?

Здравствуйте, YuryK, Вы писали:

YK> CString s;
YK> s.LoadString( IDS_STRING1 );

Судя по всему, в этот момент еще не инициализированы внутренние структуры данных, связанные с hInstance. Нажми на последней строчке F11, зайди в LoadString и поймешь, где вылазит ASSERT. Но вообще-то вопрос имеет чисто академический интерес.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Судя по всему, в этот момент еще не инициализированы внутренние структуры данных, связанные с hInstance. Нажми на последней строчке F11, зайди в LoadString и поймешь, где вылазит ASSERT. Но вообще-то вопрос имеет чисто академический интерес.

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

Здравствуйте, YuryK, Вы писали:

PD>>Судя по всему, в этот момент еще не инициализированы внутренние структуры данных, связанные с hInstance. Нажми на последней строчке F11, зайди в LoadString и поймешь, где вылазит ASSERT. Но вообще-то вопрос имеет чисто академический интерес.

YK>Если эти структуры возможно было бы инициализировать по другому (не знаю как — поэтому здесь и спрашиваю) — то тогда вызов загрузки ресурса — пройдёт нормально. — Почему же академический?

Потому что нормальный, предусмотренный архитектурой MFC, способ решить проблему — это загружать строку не в конструкторе, а в InitInstance. Если Вы хотите делать это именно в конструкторе, то, скорее всего, Вы не понимаете MFC и будете наступать на грабли и дальше.

Здравствуйте, Vadim B, Вы писали:

YK>>Если эти структуры возможно было бы инициализировать по другому (не знаю как — поэтому здесь и спрашиваю) — то тогда вызов загрузки ресурса — пройдёт нормально. — Почему же академический?

VB>Потому что нормальный, предусмотренный архитектурой MFC, способ решить проблему — это загружать строку не в конструкторе, а в InitInstance. Если Вы хотите делать это именно в конструкторе, то, скорее всего, Вы не понимаете MFC и будете наступать на грабли и дальше.

А где я мог бы прочитать, что загрузить ресурсную строчку в CString (или вообще использовать классы MFC?) в консрукторе нельзя? а именно InitInstance — место для "подобных" операций?

Ну так пояснили бы почему нельзя в конструкторе что ли...

Здравствуйте, YuryK, Вы писали:

YK>Ну так пояснили бы почему нельзя в конструкторе что ли...

К сожалению, где почитать, не подскажу, потому что об общей архитектуре MFC я последний раз читал больше 10 лет назад . Но общая идеология MFC такова, что в классе приложения, в оконных/диалоговых классах и т.п. вся серьезная инициализация делается не в конструкторе, а в специальной функции, которая вызывается для инициализации (InitInstance для приложения, InitDialog для диалога, OnInitialUpdate и т.п.).

Вот хотя бы такое соображение: единственная реализация класса приложения, унаследованного от CWinApp — объект theApp — это глобальный статический объект. Соответственно, его конструктор вызывается до того, как вызывается функция main/WinMain (в которой происходит инициализация run-time library — собственно, до ее вызова даже значение hInstance еще в Вашу программу не передано!), и в случайном порядке по отношению к конструкторам других статических объектов и библиотек (ну, не совсем случайном, но Вы им не управляете). Это уже знания даже не MFC, а С++ . Разве этого не достаточно, чтобы понять, что ничего серьезного делать в этом конструкторе нельзя?

Здравствуйте, YuryK, Вы писали:

YK>Вопрос : почему ? Помогите пожалуйста.

Все очень просто — объект-потомок CWinApp является глобальной переменной и создается до вызова _tWinMain(), где MFC "узнает" дескриптор модуля (HINSTANCE) и запоминает его в поле m_hInstance для дальнейшего использования (в том числе, и для принятия решения, откуда именно загружать заданный ресурс). Как уже справедливо отметили наши коллеги, самым правильным местом для загрузки ресурсов (и всей прочей инициализации, завязанной на дескриптор исполняемого модуля) является метод InitInstance().