Это достаточно сложно, ведь тебе придется проверить факт наличия данных во ВСЕХ TextBox. Т.е. контроль в каком-то одном TextBox - недостаточно. Нужно какое-то синтетическое свойство, которое учитывало бы факт модификации данных во всех TextBox.

Если бы ты использовала буферизацию и прямое редактирование буфера, то все было бы просто.

Т.е. просто во всех TextBox.Valid()

ThisForm.CmdOk.Enabled = NOT EMPTY(ChrTran(GetFldState(-1),"1",""))

А с переменными памяти придется симулировать работу функции GetFldState(). Это целая история:

1) Заводим пропертю формы

ThisForm.strModify = SPACE(10)

здесь число 10 - условно. Надо указать число равное количеству TextBox в твоей форме.

2) На эту пропертю вешается метод ASSIGN в котором примерно такой код


3) Теперь в форме завдим еще один метод, который будет модифицировать эту самую пропертю. Например, ThisForm.MakeModify


4) Ну, и наконец во всех TextBox.Valid() пишем что-то вроде

ThisForm.MakeModify(1,NOT EMPTY(This.Value))

Здесь первый параметр - это порядковый номер, который следует присвоить данному TextBox. Важно не перепутать. Т.е. чтобы разные TextBox не входили с одинм и тем же параметром. К сожалению, невозможно воспользоваться никаким свойством собственно TextBox. Нет никаких уникальных числовых идентификаторов. Они все уникальны в пределах одного контейнера.

PS:

Может, все-таки откажешся от редактирования через перменные памяти и перейдешь на работу с буферами? Честное слово - это значительно проще во всех смыслах. Работаешь как будто напрямую с полями таблицы, но запись идет не напрямую в таблицу, а в некий буфер. И ты только управляешь фактом сброса данных из этого буфера в исходную таблицу.

ЛисонькаВсе бы хорошо, но он выдает на thisform.cmdOK.Enabled=this.Value#this.Coment, что member cmdOK ему не известен. У меня все эти txtbox'ы и кнопки загнаны в свой класс-контейнер, может поэтому и ссылка на объект не проходит (вместо cmdOK, конечно, стоит мое название, несколько раз перепроверяла, синтаксис объекта верен).
Ну, так если CmdOk находится в контейнер, то и надо писать всю иерархию

ThisForm.MyConteiner.cmdOk.enabled = ...

Причем это сработает, если MyContainer - это объект на базовом классе "Container".

Если же это объект на базовом классе "Control", то обращение к его вложенным объектам из вне Control в принципе невозможно. Нужно организовывать специальные методы у этого класса Control для модификации реквизитов вложенных объектов и вызывать эти самые методы.

ЛисонькаВот сейчас сидела разбиралась. Название cont_РедБокс прописано в проперти этого моего класса. А вот окно Locals в Debugger'е дает название cont_РедБокс1. В этом и заключалась у меня ошибка в ссылке на объект.
А почему проперти и дебаггер трактуют это название по разному?
Когда ты создаешь класс, то, естесственно, указываешь свойство Name.

НО! На форму ты кладешь не сам класс, а экземпляр этого класса. По сути - другой объект. Естесственно, что его имя (свойство Name), в общем случае, будет отлично от имени самого класса.

А если положишь на форму несколько экземпляров класса? Как отличить один экземпляр от другого? Только по разным именам (свойствам Name).

Вот FoxPro по умолчанию сам и формирует эти имена исходя из того соображения, что в одном контейнере (в данном случае в форме) не может быть 2 объектов с одинаковым свойством Name. Для этого он просто добавляет порядковый номер к значению Name того класса, на основании которого формируется объект.