На каком событии можно отловить перемещение формы VB?

[0xy]

Resize не ловит, а больше ни чего похожего я не заметил.

[Хакер]

Штатно — нельзя.

[Денис]

Только если устроит такой вариант: по таймеру отслеживать у формы Top и Left. И если одно из них изменилось, поднимать самодельное событие. Но очевиден минус. Событие поднимется как минимум при следующем поднятии события таймера, а не в момент изменения Top или Left.

[Хакер]

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

Сказал только из познавательных соображений, крайне предостерегаю от замысла действительно так сделать. Например, можно сделать проект так, чтобы под отладкой в IDE использовал этот извратный метод, а в скомпилированном файле работал вариант, работающий через сабклассинг. Выигрыш в том, что под IDE при внезапном стопе не снятый WP не вызовет крах.

[arthur2]

не снятый WP не вызовет крах

Ты же сам мне рассказывал, что это не WP вызывает крах

Например, можно сделать проект так, чтобы под отладкой в IDE использовал этот извратный метод

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

[Хакер]

Ты же сам мне рассказывал, что это не WP вызывает крах

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

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

Ты не понял, что-ли? Под IDE ради одного такого дела городить сабклассинг, вокруг которого городить меры по его безопасному снятию — это чересчур не оправдано.

Или ты с тех пор написал таки плагин для обеспечения безопасных Callback-ов?

[arthur2]

Или ты с тех пор написал таки плагин для обеспечения безопасных Callback-ов?

Я пользуюсь им в том виде, в каком и оставил viewtopic.php?p=6726674#p6726674 Ни какие энды ему не страшны, просто не удалось добиться классического вида winproc. Но и то, что было до этого - с классическим видом wp - тоже почти безопасно

его уже нет, а он ещё значится

На сколько я понмю, его уже нет и он уже даже не значится, но крах всё равно происходит...

если в своей WP первым же делом снять сабклассинг и вызвать End, то среда всё равно закроется. И это при том, что на момент вызов End'а всё будет в ровно таком же положении, как до установки сабклассинга.

Кроме того, я проверил, возвращается ли выполнение из процедуры, в которой был вызван End, туда, откуда вызвана процедуры и убедился, что не возвращается. Так что возврат в выгруженный код сразу надо исключить.

Под IDE ради одного такого дела городить сабклассинг, вокруг которого городить меры по его безопасному снятию — это чересчур не оправдано.

Ты предлагаешь под ИДЕ пользоваться каким-то левым мутным способом, который будет вести себя совсем не так, как в релизе субклассинг? Ты предлагаешь вставить в релиз субклассинг, код которого вообще никак не будет отлаживаться (потому что на время отладки он заменен на что-то мутное)? Ты как-то сам на себя не похож

[Хакер]

На сколько я понмю, его уже нет и он уже даже не значится, но крах всё равно происходит...

Это если вызывать End из события, обработчик которого вызван из WP, которой больше нет.

[arthur2]

По теме топика:
http://forum.sources.ru/index.php?showt ... &p=2305010

[arthur2]

Выигрыш в том, что под IDE при внезапном стопе не снятый WP не вызовет крах.

И всё-таки - карх вызывает не неснятых wp :

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

Option Explicit

Declare Function CallWindowProc Lib "user32" Alias "CallWindowProcA" (ByVal lpPrevWndFunc As Long, ByVal hwnd As Long, ByVal msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
Declare Function SetWindowLong Lib "user32" Alias "SetWindowLongA" (ByVal hwnd As Long, ByVal nIndex As Long, ByVal dwNewLong As Long) As Long

Public Const GWL_WNDPROC = (-4)

Public OldWindowProc As Long

Public Function NewWindowProc(ByVal hwnd As Long, ByVal msg As Long, ByVal wParam As Long, ByVal lParam As Long) As Long
   Debug.Print msg
   NewWindowProc = CallWindowProc(OldWindowProc, hwnd, msg, wParam, lParam)
End Function


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

Option Explicit

Private Sub Form_Load()
   OldWindowProc = SetWindowLong(Command1.hwnd, GWL_WNDPROC, AddressOf NewWindowProc)
End Sub


Возвращения старой WP в коде - вообще нету. И тем не менее - проект не сдохнет ни по закрытии окна, ни по стопу

[Хакер]

И тем не менее - проект не сдохнет ни по закрытии окна, ни по стопу

Это заявление вместе с кодом имеет такую же силу, какую бы имело заявление «можно писать в абсолютно любое место в памяти», написанное после кода, в котором запись делается по адресу Int(Rnd*size_of_address_space), и который, о чудо, пару раз отработал и не вызвал крах.

[arthur2]

и который, о чудо, пару раз отработал и не вызвал крах

Этот код не умирает, потому что на момент стопа ничего внутри WP не происходит. Поэтому никакого чуда.

Если End поставить в обработчик клика субклассируемой кнопки - проект сдохнет, если End поставить в обработчик клика формы - ровным счетом ничего особенного не произойдет.

[Хакер]

Этот код не умирает, потому что на момент стопа ничего внутри WP не происходит.

И?
1) Разве я не об этом говорил?
2) Разве это не является случайным фактором?

[arthur2]

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

[Хакер]

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

Откуда нужно исключить выгруженный код?

[arthur2]

Откуда нужно исключить выгруженный код?

исключить - как причину краха. Исключить из списка возможных причин краха. Исключить не код, а возврат в код.

Не спрашивай, как хранится этот список

[Хакер]

В этой теме я такого не говорил. Что я говорил в той теме, я точно не помню. Сейчас я не считаю, что это нужно исключить из списка возможных причин.

[arthur2]

viewtopic.php?p=6726657#p6726657