Нет, неверно. В функцию Create нужно передавать ID, который будет присвоен контролу, и по которому ты в любой момент сможешь его достать.
Но я не вижу, где ты его передаешь. Это волшебное число 137 что ли? Если так, то проблема вряд ли в этом.
Ты мог бы посмотреть отладчиком значения переменных ID и hWndCtrl какое именно условие не выполняется.

Кроме того, ранее ты говорил, что вылетаешь на строчек с функцией Create, так причем тут OnCommand? Действительно ли этот вызов находится во фрейме Create (т.е. где-то внутри Create -> посмотри стек). Если так, то похоже, что контрол при создании шлет извещение диалогу (проверь, что this в этот момент показывает на твой диалог), причем шлет его неправильно (не соблюдает соглашения о содержании WPARAM\LPARAM). Или может это твоя подкрутка?

В любом случае это не фатальная ошибка, если нажать Ignore, все должно продолжать работать, но ты этот видимо не пробовал.
Проверь, но в любом случае разобраться с Assert ом надо, ибо он указавает на некошерность поведения. 

137 - это id диалога на котором я хочу разместить созданное окно. а как узнать какой id должен быть у контрола? как узнать, что нужно вместо 137 передать?


Значение ID почемуто 10003, hWndCtrl тоже не пустое. Следовательно второе условие не выполняется.


да, в этот момент hwnd равно hwnd моего диалога. никакой подкрутки нет...


Я это пробовал, всеровно вылетает.

Прочти хотя бы одну книгу по MFC или по WinAPI, тогда не будешь задавать таких вопросов.

Любой, ты его сам назначаешь. Странно, если передаешь ты 137, а получаешь 10003... возможно это уведомление от другого контрола? Есть у тебя на диалоге контрол с таким ID? Или это все же этот?
А что касается hWndCtrl - стало быть, не выполняется IsWindow(hWndCtrl), т.е. не знает система такого окна. Нужно выяснить, кто посылает эту хрень. Я стек просила посмотреть.


Но ведь в другом месте? Где?

Добавлено через 4 минуты и 14 секунд
Кстати, о птичках... В WinAPI варианте ты никакого ID не передавал! Так зачем это делать в MFC-выарианте? Все параметры должны быть такие же, с учетом разницы hWnd - pWnd! Кто его знает, что у тебя за контрол? Например, тултипы тоже без ID создаются. Передай-ка вместо 137 0. И книжки почитай, не помешает...

Передавал.. тамже вылетает, с id равным 10003...


Нету контрола с таким id. Скорее это при создании такой id назначается этому контролу. В варианте с переопределением оконной процедуры и созданием контрола на диалоге с помощью WinApi, тоже после создания в оконную процедуру поступают сообщения WM_COMMAND с 10003 id.



Похоже после вызова этой функции идут сообщения WM_COMMAND в форму



По стеку понять чтото не могу, просто вызов от одной функции к другой передаётся, как посмотреть откуда вызов то был:

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


в этом же, просто при нажатии Ignore, программа проходит дальше, но потом снова присылается это сообщение с теми же параметрами и в этом же месте уже вылетает. (В варианте с переопределением оконной процедуры и созданием контрола на диалоге с помощью WinApi оно тоже несколько раз присылается, а после него ещё идут сообщения WM_COMMAND с id=10006 и id=10000)

Это сообщение отредактировал(а) Brodyaga - 5.3.2010, 13:17

Просто смотри дальше вниз, где-то должен быть твой Create.... но иногда среда может врать, съезжает у нее чего-то... я так понимаю, библиотека с контролом не твоя и кода нет.


Тоже самое сообщение тоже можно проигнорировать. Нажми Ignore столько раз, сколько нужно - либо пройдешь, либо вылетишь не на ASSERT, а на что-то посерьезнее. Я это к тому, что нужно проверить, стоит ли пытаться обойти эту бяку, или твой контрол вообще нельзя через MFC создавать. Дело в том, что MFC подменяет оконную процедуру, а в контроле может наступить какой-нибудь конфликт в связи с этим.

Можно еще попробовать сделать так: создавать через ::CreateWindow, как ты уже делал, но тоже в OnInitDialog. Нет никакой необходимости ради этого подменять процедуру диалога. Тогда ты получишь hWnd, но можно легко сделать из него CWnd*, если оно надо. Вызывая апишную функцию для создания контрола, ты избегаешь установки хука на создание контрола, подмены процедуры и т.д. Если получится, можно при желании сделать для этого контрола MFC обертку (с собственной функцией Create).

Это всё что есть. Библиотека не моя, примеры её использования есть только на WinApi.


Это первое, что я попробовал. Вылетает именно на ASSERT, так как на следующую после него строку я поставил брекпоинт, после первого игнора на него программа переходит, но после второго вылетает не переходя на поставленный брекпоинт.


А вот тут самое интересное. Я потому и сталподменять процедуру диалога, так как если это делать в OnInitDialog, то вылетает в том же месте(на ASSERT в wincore.cpp, Ln 2598) с теми же симптомами. А при переопределении оконной процедуры диалога всё работает. Подозреваю, что это изза того, что я не передаю управление старой оконной процедуре с помощью CallWindowProc после своих действий, а при ненужных мне сообщениях передаю управление DefWindowProc.

Кстати при WM_COMMAND туда же сообщение уходит:

И всё нормально.

Сейчас попробовал отдать управление старой оконной процедуре диалога. Тоесть после создание окна контрола в WM_INITDIALOG, как и раньше присылаются сообщения WM_COMMAND с id=10003, но в мою переопределённую процедуру, но оттуда я отдаю управление старой процедуре:

Вылетело с теми же симптомами, что и раньше!(тоесть всё там же на Ln2598). Что скажете?

Это сообщение отредактировал(а) Brodyaga - 5.3.2010, 16:12

Куда вылетает-то? Ты используешь "вылетает" для самых разных ситуаций, попробуй пойми. Есть ASSERT'ы, есть исключения. Дело в том, что обойти первый ассерт довольно легко. Иногда сам факт останова на ASSERT (т.е. появление MessageBox) вызывает дальнейшие проблемы. Ибо нет после того ASSERT'а ничего фатального, на первый взгляд... Но нужно понять точно. Фактически, получается, что контрол посылает WM_COMMAND с LPARAM, которая не является окном... Странно, конечно.
Попробуй обойти так: В диалоге переопредели OnCommand и отфильтруй это сообщение (т.е. если флаг стоит и сообщение от этого контрола сразу выходим). Проще всего сделать это с помощью флага, который будет ставится перед созданием контрола, а потом сниматься. Это чтобы по-быстрому проверить. Если поможет, то можно будет думать о том, чтобы менее криво сделать. 

Никуда. Просто программа прекращает своё выполнение.

Сделал так:


Wnd - это объект типа CWnd*, обёртка для моего контрола. Создаю так:


ID равный 10008 включил, так как с ним потом тоже пошли сообщения, при обработке которых CDialog::OnCommand(wParam,lParam), вылетало всё на том же ASSERT'е. Правда после нажатия Ignor в этот раз прога продолжила своё выполнение без проблем.. ну да ладно.. всеровно решил управление ::DefWindowProc передать.
Вообщем так заработало, но что интересно hWndCtrl(ID элемента управления посылающего сообщение) и hWndControl(ID контрола) никогда не равны между собой. hWndCtrl всегда меняется.. тоесть сообщения всегда приходят от разных элементов управления.. Я думал что их контрол должен слать моему диалогу... разве не так?

Строго говоря, да. Но это всего лишь соглашение - что при посылке WM_COMMAND в LPARAM должен быть HWND посылающего контрола. А соглашение можно и нарушить. Это ведь сам контрол делает, т.е. его автор. И чего он там написал - хз. По твоим словам получается, что LPARAM содержит совсем не HWND, а какую-то другую фигню. Осталось непонятным, откуда берутся ид-ры 10003 и 10008, которые не ты назначаешь. Посмотри Спаем на контрол после создания диалога - возможно он содержит вложенные элементы или сам состоит из нескольких частей... Еще интересно, чему равен NotifyCode, число из любопытства.
Кстати, я думаю, что вызов DefWindowProc можно простить, вернуть просто TRUE (или FALSE) - вряд ли там есть какая-то разумная обработка, раз соглашение о параметрах нарушено.

Всегда 0. Хоть с каким ID(10003, 10008)

Также там ещё приходят сообщения с 10006 и 10000, но с ними не вылетает.


Не приходилось таким пользовался, это программа шпион специальная? дайте название конкретной программки тогда

Да так и называется - Spy. Есть в поставке Visual Studio. Очень удобно для исследования окон, как своих, так и чужих.

Боюсь это не поможет... У меня программа запускается на эмуляторе...