guest_rusimport,
guest_rusimportдругой путь - субклассирование , ловить сообщение окна формы WM_HSCROLL
а я как раз недавно подобным и занимался - 20774213


JavaStudent,

В общем, взял этот пример за основу, переделал на скорую руку за 1,5 часа. Вроде работает. Если что - можно подправить.
Но я бы, наверно, применял бы таймер. Куда более безопасней чем субклассирование. И там и там функции обратного вызова, какая по большому счету разница?

Пример во вложении. Три версии: Scroll_2000.mdb, Scroll_32-bit.accdb, Scroll_64-bit.accdb
Запустите на выполнение не открывая редактор кода. В ролике поста, на который сослался выше и в самом коде файла объяснил почему придется соблюдать более жесткие правила, субклассируя форму. Нельзя открывать редактор IDE, если в этот момент идет субклассирование. Откроете - завесите Access. Если хотите посмотреть код или редактировать, сначала закройте формы, по которым запущено субклассирование, а только потом открывайте среду IDE. В этом примере я тоже ввел константу, определяющую режим отладки. Здесь она называется Scroll_DebugMode. Если хотите отлаживать и писать свой код, установите ее значение в True. Тогда Access будет работать стабильно, т.к. перехвата событий прокрутки не будет. А чтобы посмотреть как работает ваш код, установите Scroll_DebugMode = False, закройте проект и запустите, помня, что теперь редактор кода открывать нельзя. Захотите открывать - снова закройте все формы, по которым запущено субклассирование и тогда открывайте. Но открыв среду IDE хоть раз, запускать проект на выполнение, если Scroll_DebugMode = False нельзя, - завесите Access.

Я обращался и на Stackoverflow и на Social.msdn:
https://stackoverflow.com/questions/45854403/i-cant-subclass-ms-access-form-if-the-window-of-ide-has-been-opened?noredirect=1#comment78705743_45854403
https://social.msdn.microsoft.com/Forums/office/en-US/4cf1d113-d905-4cdf-9f82-eb2c8d3666ed/setwindowlong-on-a-ms-access-form-what-happens-if-ide-window-is-open?forum=accessdev
в надежде, что подскажут, как работать без риска краха, но ответа нет.

На Stackoverflow мое внимание обратили на нежелательность использования SetWindowLong, с предпочтением в пользу применения SetWindowSubclass. Мне сложно это комментировать. Я просто решил сделать как советуют:
IInspectableSubclassing controls using SetWindowLong has been wrong since the first 64-bit Windows OS (Windows XP 64-Bit Edition, released in 2001). Likewise, subclassing controls using SetWindowLongPtr has been wrong for more than a decade and a half (see Subclassing Controls for the safe and sane alternative). – IInspectable Aug 24 at 19:56
И адресовали меня вот сюда:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb773183.aspx?f=255&MSPPError=-2147217396
А тут действительно Microsoft ратует за использование SetWindowSubclass.

Хотя, что интересно. Когда в тестах я использовал SetWindowLong, то в этом случае не нужно было ждать пока форма загрузится полностью. Там не нужны были вот эти финты с таймером - 20780320 , в то время как используя SetWindowSubclass субклассировать форму можно только, как я говорил, тогда, когда она полностью загружена, иначе, Access падает.
Но я все равно остановился на SetWindowSubclass, почитав, что многие расхваливают эти API функции, мол, это безопасный подход, к тому же примеры с SetWindowLong, которые я видел, все используют Lib "user32", а как это будет работать на 64-bit, да, и вообще, что там дальше с судьбой этой Lib "user32", не понятно.

У меня вообще-то есть еще мысли как можно было бы попробовать сделать по-другому. Если найду время - попробую, расскажу.

20780341 код в этом примере чего-то конечно ловит, но только процентов 15 возможных ситуаций. И эти 15% требуют доработки.
Вакшуль СергейУ меня вообще-то есть еще мысли как можно было бы попробовать сделать по-другому. Если найду время - попробую, расскажу.
Я сделал по-другому. Без субклассирования окна формы. Т.е. редактор кода может быть открыт.
Перехватываются и обрабатываются:
- прокрутка формы при клике по полосе прокрутки
- прокрутка формы колесиком мыши
- прокрутка формы при использовании middle button(нажатие на колесико и удерживание)
- прокрутка формы в результате смены фокуса, как при использовании клавиатуры(tab, стрелки и т.п.), так и мыши. Тот случай, когда прокручивание происходит в результате получения фокуса контролом, который частично или полностью не виден, выходя за границы формы

Не обрабатывается:
- горизонтальная прокрутка формы, вызываемая наклоном колесика в сторону(tilt) мыши Microsoft
События мыши перехватываются с помощью SetWindowsHookEx. Особенность функции в том, что системные сообщения о наклоне колесика мыши в сторону(tilt) эта функция не перехватывает. К сожалению. Во всяком случае сообщения моей мыши Microsoft не перехватываются.

Плохо обрабатывается:
- прокрутка формы при использовании middle button(нажатие на колесико и удерживание). В принципе работает, но возможна ситуация, когда клики вниз и вверх уже отработали, а форма "разогнавшись" продолжает прокручивание и останавливается когда ей заблагорассудится. Я заложил для борьбы с этим определенное время ожидания, но, как уже сказал, событие может не перехватится.

В целом пример рабочий, но как и предлагал guest_rusimport, гораздо проще просто обойтись таймером.

Во вложении два файла: accdb32-bit и mdb2000. mdb2000 на XP не работает. Там низкоуровневые сообщения мыши не перехватываются. Но на семерке mdb2000 работает.

JavaStudent,
JavaStudentНе разобрался почему h=2 при крайнем левом положении бегункаЭто просто факт. Не знаю есть ли тут логика. У подчиненной формы крайнее значение, считываемое функцией GetScrollPos, действительно не равно нулю, но очень близко. А вот у основной формы крайние значения полос прокрутки таки равны нулю. Остается только констатировать это явление :)

JavaStudentто, что удалось отловить самый левый номер столба и самый верхний номер строки в зависимости от положения ползунка, которые видны тут не понял. Вы имеете ввиду, что вы у себя реализовали такой функционал?

Вакшуль СергейПлохо обрабатывается:
- прокрутка формы при использовании middle button(нажатие на колесико и удерживание). В принципе работает, но возможна ситуация, когда клики вниз и вверх уже отработали, а форма "разогнавшись" продолжает прокручивание и останавливается когда ей заблагорассудится. Я заложил для борьбы с этим определенное время ожидания, но, как уже сказал, событие может не перехватится.
Уже потом, когда описывал плюсы и минусы решения, понял как можно устранить описанный выше недостаток. Если очень, очень надо могу доработать код в этом плане. Просто так - не хочется.

JavaStudent,
вы правы, там действительно оказывается :) есть связь между значениями v/h и номерами видимых строк/столбцов
я даже не обратил на это внимание. Вернее, напрочь забыл.

JavaStudentИспользовать Hook не хочется. Я как понял он грузится и начинает слушать все события, я не разбирался только в форме или вообще все приложение.Насчет примененной у меня функции SetWindowsHookEx.
Используемый тип процедуры фильтра - WH_MOUSE_LL, т.е. мониторятся не все сообщения, а только "low-level mouse input events".
Этот же тип определяет и область мониторинга: "Global only", т.е. слушаются клики не только внутри приложения.
Также нужно иметь ввиду, что перехватив сообщение, долго тянуть с его обработкой нельзя. MSDN на этот счет говорит следующее:
авторThe hook procedure should process a message in less time than the data entry specified in the LowLevelHooksTimeout value in the following registry key:
HKEY_CURRENT_USER\Control Panel\Desktop
The value is in milliseconds. If the hook procedure times out, the system passes the message to the next hook. However, on Windows 7 and later, the hook is silently removed without being called. There is no way for the application to know whether the hook is removed.
Я собственно ни к чему не призываю. Решайте сами. В реальном бою свой код не проверял, а комментарии MrShin насчет использования таймера вы видели.

По поводу области действия, "Global only". Да, хотелось бы, что бы фильтр был наложен внутри потока, но, увы. Я немного поэксперементировал с другими типами фильтра: WH_MOUSE, WH_MSGFILTER и, по-моему, WH_CALLWNDPROC, область действия которых "Thread or global", но ничего там толком не добился, использовать их в решении у меня не получилось. А вот с WH_MOUSE_LL все как по маслу. Ну да, он глобальный, но посмотрите код, там в два коротких шага(WindowFromPoint и GetAncestor) проверяется пришелся ли клик на окно Access или на другое приложение. Если в другое, сразу выход. Работая не в Access, а снаружи, влияния эти двух шагов на действия мыши, я не заметил. Вообще было ощущение, что приоритет Access ушедшего в фон резко понижен, установленный фильтр никак себя не проявлял. Хотя работая внутри Access я заметил некоторое подтормаживание при попытке выделения текста мышкой(в самом начале этого движения).
В принципе, в момент переключения в другое приложение, фильтр можно снять, а при возвращении - восстановить. Например, поставив еще один хук :), отслеживающий переключения между приложениями/окнами. Я даже сделал набросок, но потом, взвесив, решил, что преимущества ничтожны и вообще спорны (вы действительно не заметите работая извне, что Access, находящийся в фоне, фильтрует сообщения мыши).

Но вот о чем, действительно, мне кажется, нужно позаботится, так это о том, чтобы handle установленного фильтра, сохраненный в переменной, не был потерян, если в результате неперехваченной ошибки выполнения глобальные переменные "слетят". Если его сохранять в Tempvars, то проблем не будет. Я проверял. Tempvars работает железобетонно. В коде не использовал Tempvars только потому, что думал о совместимости с предыдущими версиями Access. А зря. На XP в 2000-ом применить SetWindowsHookEx все равно не получилось.
Если опасаетесь, что ваша программа зависнет, процесс придется снять, а установленный фильтр по-прежнему будет мучить систему, то опасения напрасны. Фильтр будет снят системой.
У меня в коде фильтр на сообщения устанавливается и удерживается ровно столько, сколько открыта форма, чья прокрутка отслеживается. Вы можете сделать еще жестче и снимать фильтр, если форма деактивируется(хотя если форма всплывающая, то отследить это проблемно), и устанавливать при ее активации.

Остальные комментарии по теме я оставил тут: 20797575 20897125 20899090 20899392 .