Sandwich
Извините, Маэстро
Причем здесь Valid или LostFocus?

Кхм. Ещё раз по буквам.
В момент срабатывания InteractiveChange значение из контрола (которое уже есть в его .Value) ещё НЕ ПЕРЕНЕСЕНО в ControlSource (не суть важно переменная там, или свойство объекта). Соответственно вызов .Refresh бессмысленен, если другие контролы привязаны или как-то используют значение переменной/свойства указанных в ControlSource. Хотя если они будыт ссылаться на Thisform.combo1.Value то таки увидят новое значение.
Valid тут при том, что к моменту его срабатывания значение уже перенесено из .Value в связанное свойство/переменную - соответственно .refresh прописанные в Valid решат проблему. Если что - Valid для комбо срабатывает при "выборе значение" - ещё до потери им фокуса. Я не думаю что ты сможешь найти принципиальную разницу между .Refresh в Valid и в InteractiveChange.

Про LostFocus я упомянул по другой причине - оно может применяться если данное комбо это своего рода фильтр или условие отбора. И только лишь для того, чтобы не нагружать систему бессмысленной работой по перевыборке данных до тех пор пока пользователь "не определился" со своим выбором. В других случаях вполне подойдёт и Valid - он будет срабатывать многократно при "телодвижениях" внутри комбо.

Sandwich
Вопрос принципа: почему нужно для тривиального действия использовать этот бубен в виде таймера и пр.?

Бубен нужен как раз для НЕтривиальных случаев. Наподобии подсказок в поле поиска в браузере - было бы весьма расточительно дёргать гугл по вводу каждого символа в это поле - потому запрос делают лишь если пользователь "задумался" на несколько секунд, а не при каждом нажатии кнопки. Тут сходная ситуация - если пользователь колёсиком мышки или "стрелками" прокручивает список комбо, то расточительно и нецелесообразно делать перезапрос на каждое такое действие - и таймер тут весьма неплохое решение. НО это именно для случаев если комбо выполняет роль фильтра - если это просто ввод данных, и в соседних контролах ничего тяжёлого не выполняется при изменении выбранного значения, то будет как раз "тривиальный случай" решаемый рефрешем в Valid.

Sandwich
Почему поведение комбо зависит от "глобальности" этой переменной?

Оно не зависит от этого. Просто использование глобальных переменных - крайне дурной тон при разработке на VFP.

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

Igor Korolyov
Просто использование глобальных переменных - крайне дурной тон при разработке на VFP.

Хочется добавить. На любом языке, где это возможно.

Спасибо за ответы.
С Vaid и InteractiveChange согласен полностью - затупил.
А вот насчет этого:

Аспид

Igor Korolyov
Просто использование глобальных переменных - крайне дурной тон при разработке на VFP.

Хочется добавить. На любом языке, где это возможно.

Как поступить, когда переменная носит именно глобальный характер по своей сути? Например в этом моем случае:в системе несколько магазинов. Любой пользователь работает единомоментно только в одном из них. Без переменной ТекущийМагазин не обойтись. В программе десяток форм и сотня функций, почти в каждой из которых используется эта переменная. Если её не "глобалить", то передавать из каждой функции в другую?

Sandwich
Спасибо за ответы.
...
А вот насчет этого:

Аспид

Igor Korolyov
Просто использование глобальных переменных - крайне дурной тон при разработке на VFP.

Хочется добавить. На любом языке, где это возможно.

Как поступить, когда переменная носит именно глобальный характер по своей сути? Например в этом моем случае:в системе несколько магазинов. Любой пользователь работает единомоментно только в одном из них. Без переменной ТекущийМагазин не обойтись. В программе десяток форм и сотня функций, почти в каждой из которых используется эта переменная. Если её не "глобалить", то передавать из каждой функции в другую?

Ну тут наши метры несколько погорячились, ОДНА глобальная переменная всё равно нужна (пусть это даже будет _Screen), они имели в виду, что к глобальной переменной можно прицепить объект в котором нужно хранить public данные.

Не обязательно даже объект - "глобальным" может быть и курсор или таблица с настроечной информацией, да тот же ini файл - хотя его постоянное чтение не есть хорошее решение в плане производительности.

К переменной невозможно ограничить доступ - и даже просто проследить где меняется её значение (если "тупой код" таки сделает где-то присвоение, найти "концы" будет крайне сложно, особенно в массивном проекте да разарабатываемом не 1 человеком). К свойству объекта - уже можно.