Было бы неплохо узнать версию FoxPro, но, поскольку используется BROWSE-окно, то, скорее всего, речь идет о FoxPro for DOS.

Проблема в том, что FPD - это чисто процедурный язык. В большинстве случаев, в нем приходится симулировать события.

Команда BROWSE предназначена для отображения содержимого таблицы. В принципе, в ней можно добавить FOR-условие, чтобы она еще и фильтровала записи.

Дополнительная проблема в том, что BROWSE-окно в таком синтаксисе - это точка останова. Т.е. код следующий за ней будет выполнен только после закрытия собственно BROWSE-окна.

Насколько я помню, единственным способом перехватить нажатие клавиши в FPD была функция

ON KEY LABEL

Т.е. придется на каждую букву писать свою настройку ON KEY LABEL. Очень муторное занятие. Проще сделать одну горячую клавишу по которой открывается дополнительное окно для ввода текста фильтра.

Browse-окно в VFP - это прежде всего средство отладки . Т.е. разработчику нужно по быстрому посмотреть содержимое таблицы или проверить работоспособность некоего кода при модификации данных.

Основаная проблема BROWSE-окна в его неуправляемости. Тот же перхват нажатия клавиши для Browse-окна почти "неподъемная" задача. Browse-окно - это как бы "вещь в себе". Почти ничего не торчит снаружи, за что его можно было бы ухватить и "доработать напильником по месту"

Поскольку у тебя VFP5, то вместо BROWSE создай форму с Grid. Вот у него, для соответсвующего TextBox можно обработать событие KeyPress и никакой мороки с ON KEY LABEL.

Хотя, повторюсь, с моей точки зрения, сама постановка задачи некорректная. А если "рука дрогнула"? А запрос выполняетс несколько секунд?

Такие фильтры делаются как минимум, через дополительные TextBox, как максимум, отдельные формочки. Ввел ключ для поиска, затем нажал кнопку и получил результат.