Создаю немодальный диалог гдето так:


Удаляю так:


И обработчики OnClose и OnDestroy невызываются.

OnDestroy вызвался только когда при открытом немодальном диалоге я нажал на кнопку закрытия главного окна.

Вообще задачя сохранить положение и состояние окна в реестре (это проблем не вызовет).
 

Я точно не помню, но вроде немодальное окно при нажатии его крестика не закрывается, а прячится. 

Ну на счёт крестика у меня проблемма обычно при нажатии на крестика окна у меня вызывалась функция OnCancel и такой расклад вполне нормален.
А щяс почемуто не вызывается (потом задам такой вопрос если что   ), я пока поставил кнопку "Отмена" и в ней нодительскому окну посылаю сообщение о просьбе закрыть немодальный диалог и он зарывается набраным мной кодом (см. выше). 

это обработчики сообщений винды WM_CLOSE и WM_DESTROY и естественно что они не вызываются - они же не посылаются окну.. Немодальные окна следует уничтожають вызовом DestroyWindow
 

vvpC, попробывал тогда WM_DESTROY приходит, это хорошо, спасибо, а другие альтернативы есть? 

WM_DESTROY всегда посылается перед уничтожением окна. Только вот, если просто делать delete, происходит это в деструкторе CWnd, когда от твоего класса рожки да ножки остались.
Так что vvpC прав: нужно явно вызывать DestroyWindow. Кстати, если бы ты внимательно смотрел сообщения в output-окне, то увидел бы предупреждение, что-то вроде: "Караул! Вызов DestroyWindow в деструкторе CWnd!". Чтобы не писать каждый раз DestroyWindow, можно делать это в деструкторе своего класса. Тогда можно просто писать delete pWnd. 

  
Что и говорить - глупое проектирование MFC. Конструкторы не создают окошки, деструкторы не разрушают   
 

глупо...

не глупо! 

Напиши свой деструктор, который будет разрушать окно. Почему стандартный деструктор C++ должен разрушать какие-то окна? И MFC тут непричем: ее сложно назвать идеалом, но в данном случае - это твоя личная глупость. Нужно просто изучать матчасть. Или писАть на бейсике.
 

Не надо ссорится.   

Я (с вашей помощью пришол к выводу) в начяле вызывааю функцию DestroyWindow а потом делаю delete указалелю. Теперь принажатии на крестик приходит событие OnClose и тоже самое делаю при нажатии не кнопку "Отмена".

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

Rapalex, внимательнее читай: добавь вызов DestroyWindow в деструктор своего класса окна, и пиши только одну строчку (delete pWnd). 
Есть еще MFC-альтернатива: делать delete this в обработчике PostNcDestroy, как делают многие MFC-классы. Тогда тоже можно будет писать одну строчку (DestroyWindow). Но это не очень хорошо с точки зрения ООП (где-то хранящийся указатель может стал недействительным без видимых причин). Впрочем, раз MFC так делает, то не стоит пытаться быть святее папы римского. Все зависит от контекста: иногда это вполне удобно. 

Потому что разработчики MFC должны были это предусмотреть ;)


ПОЧЕМУ??? 

Вдруг надо в экземпляр производнова от окна класса записать какие-нибудь настройки и только потом создать окно. 

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

Ну и пусть вызываются всякие виртуальные функции вроде PreCreateWindow.  


Млин, ну я же не совсем дурак... Я имею в виду, что это должен делать класс CWnd => и все наследованные от него (хотя конструктор наследуемого класса можно конечно и игнорить). Во всех библиотеках делается именно так, по моему, достаточно разумно. Ещё лучше пусть будет метод Create. Безаргументным конструктором он не вызывается, но есть конструктор с аргументами автоматом вызывающий Create. Аналогично можно разрушать окошко когда хотим, но если мы этого не сделали, то пусть деструктор будет добр поработать за нас. Вспомните классы std::fstream - мы можем сразу открыть файл, а можем и не открывать; можем закрыть, если нужно, а можем смело забить на это. Таким образом класс действительно инкапсулирует в себе все нужные операции. MFC-шные классы окошек спроектированы так, будто окошко существует независимо оот объекта. Допустим оно действительно может существовать независимо, но это совсем другая история... Проектируя библиотеку ГУИ надо было позаблтиться о единстве объекта и физического окошка.