Для позиционирования автономной формы около контролов уже открытой табличной формы, используется апи-функция GetFocus (Private Declare Function GetFocus Lib "User32" () As Long). По задаче координаты контрола должны вычисляться на события получения фокуса контролом. Но не вычисляются, вернее неверно вычисляются и все контролы формы (текстбоксы , комбо) имеют один и тот же hwnd. Подскажите, как найти hwnd контролов формы при получении ими фокуса?
Что интересно, если поставить GetFocus на событие Change и вручную, именно вручную внести данные в поле, то hwnd вычисляется правильно.
Как обойти этот затык? Где-то прочитал, что в каком-то календарике эта задача решена. Но не могу найти топик с решением.

Спасибо, guest_rusimport. Этот календарь я видел. Тот же гетфокус. Те же сны (с)

Ну, вот посмотрите. Сделал примерчик с табл.Сотрудники из борея. Если ходить по полям, то HWND не меняется. Если в любом поле поменять хоть что-то, то немедленно иной hwnd.

Может у меня глаза застило, может вы увидите где я ошибаюсь.

Не прикрепляется файлик. Попробую еще раз

Покажу на примере. Та же форма, что и прежде. Но на полях Фамилия и Имя в событиях SetFocus и Change вызывается форма, которая должна встать чуть ниже активного контрола. На Change все встает правильно. А на SetFocus форма совсем в другом месте. В отладке выяснил, что это из-за неверного вычисления HWND функцией GetFocus. Вот и прошу совета как заставить GetFocus показывать правильное значение. Или пойти другим путем, но каким?

Спасибо, guest_rusimport! Хотелось бы обойтись без таймера, но видимо не получится.
Но есть один неприятный момент. Если щелкнуть на пересечении записей (курсор при этом превращается в светлый крестик), то ситуация опять прежняя. Смотрите рисунок. Есть ли выход?

13-й квартал, желательно обойтись встроенными средствами Access. Из дополнительных только апи.

13-й кварталИли вы CommandBar тоже не будете использовать на основании того, что он описан в Офисной библиотеке?
Использование меню и контекстных меню не предполагается. Но спасибо за направление в отладке


Анатолий ( Киев )ИМХО, событие GotFocus возникает ПЕРЕД получением фокуса полем. Понял. Но тогда странно, что DoEvents, записанный после получения фокуса не исправляет ситуацию. Или я неправильно понимаю действие DoEvents?

Анатолий ( Киев )У вас что, автономная форма все время открыта и бегает по экрану следом за фокусом? Объясните вашу стратегию. Назначение формы?Это пожелание заказчика иметь интерфейс для связанных списков в табличной форме. Единственный контрол в ней это комбо, роусоурс которого меняется в зависимости от значений других полей в записи.

П-ЛИз табличной формы одним кликом попадаем в форму-карточку, в которой связанные списки программируются без проблем. Потом, тоже одним кликом - обратно. Или остаемся в карточке и в ней переходим на следующую запись, пока не захочется вернуться в табличную. Т.е. не соблюдая букву пожелания, вы соблюдаете его дух, не ухудшаете эргономику, делаете реализацию в разы быстрее штатными фичами. Вменяемому заказчику это легко обосновывается.Этот вариант рассматривался. Но было признано, что при большом объеме ввода нежелательно лишний раз прибегать к мышке (или клавиатурному сочетанию для перехода) и перемещать внимание оператора на другую часть формы. Разве не так?
В принципе и показ доп.формы на получении фокуса не столь обязателен, поскольку оператор начинает набирать текст и срабатывает Change, правильно фиксирующий доп.форму. Но как бы для порядка надо. :)

nord-woolfМожет попробовать посчитать с помощью SetCursorPos?То, что я находил, тоже не слишком надежно срабатывало. Или я неверно применял. :)
Может быть у вас есть хорошая ссылка? Был бы благодарен.

\\\\getfocus1, на вот 15165216 , у qwerty112 срисуй. Там, по моему, это между делом решено.А что там по ссылке есть? Только простые и ленточная форма. Табличной нет. А с простой и ленточной формами проблем нет.

guest_rusimport, очередное спасибо!
Но не осознал, что изменилось и где. Ткните носом, пожалуйста.

\\\\, это я увидел в ленточной и не понравилось. Не подойдет. Но спасибо.