Что за сообщения &H7C и &H7D?

[Antonariy]

Леплю к проекту GSerg'евский subclasser, сабклассю юзерконтрол. При компиляции происходит инициализация юзерконтролов, сабклассинг включается, проскакивают сообщения:

Код: Выделить всё

WM_WINDOWPOSCHANGING(70)
WM_NCCALCSIZE(131)
WM_WINDOWPOSCHANGED(71)
WM_SIZE(5)
WM_WINDOWPOSCHANGING(70)
WM_124(124) - &H7C
WM_125(125) - &H7D

И после &H7D IDE падает. Единственные константы с этими значениями - VK_F13 и VK_F14, но это не WM.
Ни CallWindowProc ни игнор ситуации не меняют.
Пока что сделал так:

Код: Выделить всё

Private Sub UserControl_Show()
    If Not UserControl.Ambient.UserMode Then lSubclass.AddSubclass UserControl.hwnd, Me
End Sub

но эта ситуация мне не нравится.

ADD:
Const WM_STYLECHANGING = &H7C
Const WM_STYLECHANGED = &H7D
Однако это не объясняет, почему IDE падает.

[alibek]

А что делает контрол при сабклассинге?
Не во всех режимах можно использовать все функции.

[Хакер]

Antonariy
Т.е. ты хочешь сказать, что простая передача управления оригинальному WindowProc-у даёт крах?

[Antonariy]

alibek
Обрабатывает WM_NOTIFY, остальные сообщения отдаются оригинальному WindowProc-у .

Хакер
Ага. И это только при компиляции.

[Хакер]

Antonariy
Если исключить из WindowProc-а вообще всё, кроме перехода к оригинальному, то такое поведение останется?

Если да, то каков код исключения?

[alibek]

Обрабатывает WM_NOTIFY, остальные сообщения отдаются оригинальному WindowProc-у .

А если закомментировать эту обработку, все сообщения передавать в оригинальную WindowProc, тоже падает?

[Antonariy]

Очень странно, но если закоментить или сделать Exit Function в начале, то ошибки нет. Вот весь код:

Код: Выделить всё

Private Function ISubclass_Callback(ByVal hwnd As Long, uMsg As Long, wParam As Long, lParam As Long, ByVal PrevProc As Long) As Long
Dim uNMH     As NMHDR
Dim uHDHTI   As HDHITTESTINFO
    If uMsg = WM_NOTIFY Then
        Call CopyMemory(uNMH, ByVal lParam, Len(uNMH))
        If uNMH.hWndFrom = pvHeaderhWnd Then
            Call GetCursorPos(uHDHTI.pt)
            Call ScreenToClient(uNMH.hWndFrom, uHDHTI.pt)
            Call SendMessage(uNMH.hWndFrom, HDM_HITTEST, 0, uHDHTI)
            Select Case uNMH.code
                Case HDN_ITEMCLICKA
                    BrowsersHub.FireColumnClick Me, CInt(uHDHTI.iItem), vbLeftButton
                Case NM_RCLICK
                    If (uNMH.hWndFrom = pvHeaderhWnd) Then BrowsersHub.FireColumnClick Me, CInt(uHDHTI.iItem), vbRightButton
            End Select
        End If
    End If
End Function

Я сабклассер немного подправил, если ISubclass_Callback = 0, то вызывается CallWindowProc. Еще я пытался обрабатывать WM_STYLECHANGED в самом сабклассере, все равно вылетает.

[alibek]

Не вызывается ли контекстное меню при клике правой кнопкой?

[Antonariy]

Ни до какого меню дело вообще не доходит. Падает при компиляции.

[Хакер]

Antonariy
Ну выясни, до какого места выполняется и начём падает. И вообще, код исключения какой?

[Antonariy]

Падает после сообщения WM_STYLECHANGED.
Какой код исключения не известно - "приложение выполнило недопустимую операцию и будет закрыто". Содержимое Application log:

Ошибка приложения vb6.exe, версия 6.0.97.82, модуль vba6.dll, версия 6.0.0.9782, адрес 0x00179a39.

[Хакер]

Не после какого сообщения, а на каком месте в коде.

Hint: найти OllyDbg, во время краха нажать [Отладка], посмотреть что-там будет в статусной строке (а там будет очень интересаня и полезная информация), и выложить сюда.

[Antonariy]

OllyDbg отсутствует в списке отладчиков.

[Хакер]

Options --> Just-in-time debugging --> Make OllyDbg just-in-time debugger.

[Хакер]

А вообще, у меня есть такое предположение, что дело в следующем:

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

Предположение возникло потому что адрес 0x00179a39 с очень большой вероятностью принадлежит либо стеку потока, либо куче.

Переход на стек вряд-ли возможен (потому что если бы он был возможен, он бы происходил и не при компиляции, а постояно), а вот то, что это переход на дин. код, лежащий в куче -- вполне возможно.

Хотя со стеком вариант тоже нельзя стопроцентно исключить, посмотри, везде ли прототипы API-функций совпадают с реальными.

[Antonariy]

Access violation

[Хакер]

Блин, это кишки p-кодного движка -- фиг в них разберёшься

Попробуй в своём коде перед каждым вызовом API-функции вставить DebugBreak.

Тогда на первом же вызове DebugBreak ты вылетишь в отладчик (и окажешься на строчке int3 внутри функции DebugBreak). Жмёшь два раза F8 (выходишь в таким образом из DebugBreak) и выполнение уходит опять в твой код. И так каждый раз, когда будет вызов DebugBreak.

Твоя задача - посчитать, сколько раз вызывается DebugBreak, прежде чем выполнение улетает в pcode-ный движок.

Соотнеся это число с кодом (сколько и где ты там вставишь вызыовов DebugBreak), можно сказать, после вызова какой функции выполнение улетает не туда, куда надо.

А там уже дальше надо будет копать, расставляя брекпоинты внутри этой функции, ловя место, где something will go wrong.