Показать сообщение отдельно
Старый 20.11.2008, 08:04   #7  
TasmanianDevil is offline
TasmanianDevil
Мрачный тип
Аватар для TasmanianDevil
Злыдни
 
887 / 389 (14) ++++++
Регистрация: 24.01.2005
Адрес: Томск
kashperuk, Dron AKA andy, Вы, видимо , невнимательно прочитали мое сообщение. В первоначальном варианте - изменяемого поля в гриде(и ассоциированного с ним контрола,соотвественно) не было - и тут Вы оба на 100 % правы. Но затем-то это поле было добавлено в грид (см. вложение)! При его программном изменении в процессе исполнения edit-метода на табличной переменной, в гриде значение контрола , ассоциированного с изменяемым полем, тоже изменялось - но к этому-то контролу никто не обращался из кода, к тому же с поля , ассоциированного с edit-методом, перехода не было, фокус выделения никуда не уходил. Вопрос же стоял почему в случае пользовательского изменения содержимого контрола вызывается, а в случае изменения значения у контрола, ассоциированного с изменяемым в коде полем, выполняемого системой, не вызывается modified() у этого контрола ?

В любом случае, именно это вопрос(должен вызываться или не должен вызываться modified() при изменении ядром системы значения контрола) не столь принципиален - по большому счету пофиг как ядро разруливает внутри себя обработку WM_SETTEXT по окну данного контрола, вполне возможно, что сделано сие для предотвращения каких-то подводных камней(типа рекурсий вызовов этих методов при кривом программинге).

Принципиально то, что проверка валидности Relation'ов активируется в исключительно по результатам манипуляций в ассоциированных с полями таблиц контролах формы, а не по результатам изменения табличной переменной датасорса.
Еще раз, повторяясь - IMHO, это архитектурный баг ...
Вложения
Тип файла: xpo PrivateProject_EditMethodTest.xpo (7.9 Кб, 253 просмотров)
__________________
Мы летаем, кружимся, нагоняем ужасы ...