Доброго дня, коллеги! Можно ли перехватить передачу фокуса из области выделения? Ситуация такова: кликаем по области выделения, фокус остается там (в обл.выд.) и не передается контролам. НО в обработке события формы KeyDown прописано применение метода me.requery при определенных условиях. Так вот, после requery фокус падает-таки на контрол с индексом 0. Как бы вот этого не допустить? Или вернуть в область выделения...
___________________________________________________________________
"Нихера у вас запросы!!!" - сказала база данных и повисла.

Всё не так: тычка мышой в область выделения ленточной формы -> фокус остается в области выделения (если вообще без вмешательства в какие-либо события). Мне бы его там и оставить. Но у меня (как раз-таки из-за вмешательства в событие KeyDowm формы) при этой тычке срабатывает requery, из-за которого фокус передается первому контролу (с индексом по таб 0). А нужно, чтоб не передавался.

Это как раз у меня и прописано сразу после реквери. На запись переходит, а фокус все-равно соскакивает на первый контрол. Хотя опять же, в других случаях (без реквери) после этих манипуляций фокус остается в области выделения.

Да, после рефреша фокус не передается из области выделения. Но рефреш оставляет на экране удаленные записи (перед requery (или refresh) прописано, что может сработать запрос на удаление, именно эту ситуацию я обыгрываю, в иных случаях и так все работает).

А при чем тут удаляемая запись? она исчезает с экрана. Для вертежа с FindNext считывается id из события GotFucus полей, либо KeyDown и Click формы. Т.е. попадаем на ту запись, куда "ткнул" юзер. Тут вся проблема: если refresh не применялся, то при клике по области выделения, фокус остается там (см. scr1.jpg), а если форму рефрешнули, то фокус сваливается на контрол с индексом по Tab = 0 (см. scr2.jpg). Джипеги в приложении.

второй скриншот

Субформа ленточного типа содержит 1 комбобокс с тремя столбцами (назовем его cmbx1) с ограниченным списком, два текст-бокса для заполнения (txt1 и txt2) и два задизэбленных текст-бокса (txt3 и txt4). Необходимо чтобы:
1) пользователь не оставлял записи с пустым комбобоксом (такая запись удаляется, если юзер уходит с записи).
2) после выбора значения в комбобоксе, заполнялись поля txt3 и txt4 из доп.столбцов комбобокса
Реализовано посредством обработки событий
- BeforeUpdate комбобокса (заполнение полей);
- GotFocus комбо- и текстбоксов (удаление косячных записей);
- Click, DoubleClick, KeyDown субформы (удаление косячных записей);
- Exit элемента управления с этой субформой в модуле материнской формы (удаление косячных записей).
Как именно. Юзер тнкул мышкой в субформе, не важно куда -> фиксируем (записываем в переменные)
- id той записи, куда ткнул юзер
- значение me.NewRecord
- значение me.ActiveControl (т.е. куда ткнул юзер)
Это все в событиях GotFocus контролов и в событиях Click, DoubleClick, KeyDown субформы. После этого там же в тех же событиях перебегаем в самопальную процедуру (назовем ее DellNull). Тут-то самая тусня. Разветвленный под разные ситуации код. Используется флаг для срабатывания проверки наличия "косячных записей", если они есть, то их удаление (запросом на удаление методом execute), затем рефреш формы/возвращения к записи, в которую ткнул юзер (т.к. рефреш отправляет в начало рекордсета)/возвращения фокуса контролу, куда ткнул юзер (по той же причине). Если ткнули в задизбеленный контрол или в область выделения, возвращения к записи после рефреша нужно, а вот фокус никакому контролу не передается, остается в области выделения. Если ткнули в новую запись, она удалится рефрешем, а после рефреша - me.AddNew и в тот же контрол. Если ткнули вообще "в молоко", то только удаление и рефреш. Перед самым обновлением формы флаг принимает отменяющее значение.
Короче, все работает как надо, кроме одного момента: авторЕсли ткнули в задизбеленный контрол или в область выделения, возвращения к записи после рефреша нужно, а вот фокус никакому контролу не передается, остается в области выделения. Вот это после рефреша не работает. Фокус таки передается первому по списку Tab контролу. Без рефреша не передается, а вот после него да. Конечно, я уже сделал всё, чтобы это не играло никакой роли, и пошел дальше. Но хотелось бы все-таки решить эту проблему, чтобы в будущем не поднимать обсуждение снова, если прижмёт.

"Косячные записи" это те, где значение комбобокса = -1. Не могу оставить это на ответственности юзера. История не нужна. Каждое утро для не которых записей главной формы удаляются все записи субформы и вносятся актуальные.


Ну вариант, конечно, пусть и совсем уж альтернативный. Рефреш формы в этом случае будет не нужен. Но все это слишком усложнит работу пользователя, и будет сильно тормозить его. Он, как оператор, должен быстро вносить записи, а тут я ему еще и кнопок напихаю. Сортировка на глазах юзера тоже вещь зловредная, он же с бумажного носителя вносит, должен видеть на экране тоже, что и на бумаге. txt3 и txt4 должны быть видны на экране. Нужно оставить возможность выделять несколько записей в области выделения, для удаления. В целом, я довел интерфейс этой формы до нужного и удобного вида, учел все потребности, обыграл все ситуации. Кроме одной вот этой загвоздки. Пока шел на работу, подумал, что дело не в самом рефреше, а в том, что он вызывает собитие подформы, при котором фокус передается "первому" контролу. Любую форму когда загружаем, получаем фокус в первый по списку контрол. Попробую сейчас выяснить, где это происходит. Load, Current...

vmag, я все же сделаю по Вашему предложению тоже. Весьма интересный способ. Пусть не приживется сейчас к этому случаю. В другом месте пригодится)

-1 означает, что не выбрано значение в комбобоксе (это у контрола). Запрос на удаление таких записей содержит в качестве одного из критериев: "... WHERE ([поле-источник комбобокса]) Is Null"
Прошу прощения, забыл ответить на этот вопрос. Источник формы - сохраненный запрос с открытым доступом к таблице-источнику. Простая выборка + поле с функцией. Главная форма фильтрует эту выборку по значению поля связи. А у комбобокса в свойстве "данные" прописан sql-запрос вида "SELECT то-то FROM оттуда-то WHERE такое-то;", опция LimitToList в значении true. В качестве "оттуда-то" отдельная таблица-каталог. Но к чему это всё? Зачем вся БД? В данном вопросе фигурируют 2 формы - одна подчиненная для другой. Три таблицы: источники для главной, для подчиненной и для комбобокса. Те, что для форм, связаны по одному полю. Связь отражена в схеме данных. Но я всё же не пойму, зачем копаться в схеме БД. Я описываю вам поведение фокуса в событиях контролов и формы после применения методов requery (в ходе обсуждения я запутался и стал говорить вместо него refresh) и FindFirst. Вот я поковырялся в событиях субформы и здесь и в других проектах, где применялись requery и FindFirst. Дошло до того, что назначил сочетания клавиш для этих действий, чтобы проиграть их без событий, которые могут перемещать фокус куда-либо. Оказалось, что оба эти метода вызывают событие Current формы и неминуемо передают сначала фокус контролу с индексом по tab=0, а потом уже все остальное. Видимо, это нельзя отменить или перехватить и обработать. Всё что прописывается в обработку Current происходит после передачи фокуса "первому" контролу. Неприятная истина. Все-таки придется мудрить с кнопками. Ну как минимум кнопку для удаления выделенных записей, а удаление в форме запретить. Во всем остальном данная проблема либо отсутствует, либо не мешает.

Да нет там ключевого поля. Простая выборка, типа [наименование][тип][ед.измерения]. С ключом появляется проблема с подбором значений по первым буквам. Вообщем, это лишнее тут. А пустое значение может появиться, если "ткнуть" на новую запись, сразу проставляется значение в поле связи и значения по умолчанию двух других полей (с числовым типом данных). А еще юзер может и изменить значение какого-нибудь поля, при этом не трогая комбобокс. Ну это можно решить, включив опцию обязательное поле. Можно не обсуждать даже, хотя помню, как это вызывало весьма неадекватную реакцию пользователя, когда он не мог уйти с записи, не мог понять, что от него требуется, давай акс вырубать, кнопку "ресет" жать...

Нет, это ищет по ключевому полю, т.е присоединенный столбец - ключ. А иначе зачем об вообще? Но вы опять же не туда повели мысль. В "косячных записях" речь идет о пустом значении как раз-таки присоедиенного столбца в таблице-источнике формы, а не в источник самого комбобокса. Там и без ключей не будет пустых значений. Это обеспечивается интерфейсом формы редактирования этого каталога. Без этого, конечно, ключ был бы неприменно. Но повторюсь, к "косячным записям" это отношение не имеет. Само поле комбобокса (ControlSource) не может быть ключевым. Тут разве что опция "обязательное поле"...