return ( ERR_INVALID_DATA);
}
return ( ERR_SUCCESS);
.
.
.
При использовании данных утверждений возникает труднообъяснимая проблемная ситуация, состоящая в том, что они разрушают значение последней ошибки (last error value). В только что показанном фрагменте при выполнении оператора
_ASSERTE ( FALSE != IRes)
(т. е. при вызове макроса с указанным параметром) выводится панель сообщения, а значение последней ошибки становится равным 0, так что в отладочных построениях UI-поток всегда кажется зависшим, тогда как в выпускных построениях бывают ситуации, в которых параметры, пересылаемые в функцию sendMessageTimeout, оказываются некорректными. Кому-то подобная ситуация может и не казаться такой уж проблемной, но мой собственный опыт был иным — с этой ситуацией оказались связанными две ошибки, на отслеживание и исправление которых пришлось потратить много времени. К счастью, представленное ниже утверждение SUPERASSERT позволяет решить эту проблему.
Макросы ASSERT_KINDOFw ASSERT_VALID
Программисты, использующие библиотеку классов MFC, наверняка встречались с двумя дополнительными, специфичными для MFC макросами утверждений, которые чрезвычайно полезны при профилактической отладке. Если классы объявлены с помощью макросов DECLARE_DYNAMIC или DECLARE_SERIAL, то макрос ASSERT_KINDOF позволяет проверить, на что ссылается указатель производного (от cobject) класса — на некоторый конкретный класс или на его производный класс. Макрос ASSERT_KINDOF — это просто оболочка метода cobject: :isKindOf. В следующем фрагменте исходного кода сначала проверяется параметр утверждения ASSERT_KINDOF, а затем выполняется реальная проверка ошибки параметра.
BOOL DoSomeMFCStuffToAFrame ( CWnd * pWnd)
{
ASSERT ( NULL != pWnd);
ASSERT_KINDOF ( CFrameWnd, pWnd);
if ( (NULL == pWnd) ||
{ FALSE == pWnd->IsKindOf ( RUNTIME_CLASS ( CFrameWnd))))
{
return ( FALSE);
.
.
.
// Выполнить некоторую работу для MFC-приложения; Гарантировано,
// что pWnd будет указывать на класс CFrameWnd или на класс,