kashperuk, Dron AKA andy, Вы, видимо , невнимательно прочитали мое сообщение. В первоначальном варианте - изменяемого поля в гриде(и ассоциированного с ним контрола,соотвественно) не было - и тут Вы оба на 100 % правы. Но затем-то это поле было добавлено в грид (см. вложение)! При его программном изменении в процессе исполнения edit-метода на табличной переменной, в гриде значение контрола , ассоциированного с изменяемым полем, тоже изменялось - но к этому-то контролу никто не обращался из кода, к тому же с поля , ассоциированного с edit-методом, перехода не было, фокус выделения никуда не уходил. Вопрос же стоял почему в случае пользовательского изменения содержимого контрола вызывается, а в случае изменения значения у контрола, ассоциированного с изменяемым в коде полем, выполняемого системой, не вызывается modified() у этого контрола ?
В любом случае, именно это вопрос(должен вызываться или не должен вызываться modified() при изменении ядром системы значения контрола) не столь принципиален - по большому счету пофиг как ядро разруливает внутри себя обработку WM_SETTEXT по окну данного контрола, вполне возможно, что сделано сие для предотвращения каких-то подводных камней(типа рекурсий вызовов этих методов при кривом программинге).
Принципиально то, что проверка валидности Relation'ов активируется в исключительно по результатам манипуляций в ассоциированных с полями таблиц контролах формы, а не по результатам изменения табличной переменной датасорса.
Еще раз, повторяясь - IMHO, это архитектурный баг ...
__________________
Мы летаем, кружимся, нагоняем ужасы ...
|