|
20.01.2006, 14:44 | #1 |
1C
|
Сохранение строки закупки - потеря фокуса?
Всем доброго дня, помогите пожалуйста, разобраться!
Ситуация следующая: есть закупка, довольно большая (180 строк). При сохранении строки (это должна быть не одна из первых строк) курсорчик в гриде улетает на первую строку. Покопавшись в коде, я выяснил, что это происходит при отработке метода purchLine_ds. Конкретно - строка purchLine_ds.reRead(). Я ее закомментировал - эффект исчез. Вопрос - как еще с этим эффектом бороться? Мне не очень понравился мой метод борьбы... Спасибо |
|
20.01.2006, 15:33 | #2 |
Administrator
|
Если Вы имеете в виду метод write на датасорсе PurchLine - то эффект проявляется на purchTable_ds.reread().
Бороться с этим можно по-разному: 1) Воспользоваться методом findRecord на purchLine_ds. Т.е. сначала запомнить курсор, затем скормить его: purchLine_ds.findRecord(курсор). Этим правда не рекомендуется пользоваться на больших количествах записей (свыше 1000) - к примеру - нехорошо так делать на PurchTable. Т.к. findRecord исполняется на датасорсе, где всего 180 записей - то тут можно применить сей метод 2) Попытаться понять - почему сделано именно так и что пострадает, когда код будет закомментирован. Этот метод ведет к большей переделке, однако он единственен, если записей много
__________________
Возможно сделать все. Вопрос времени |
|
20.01.2006, 16:08 | #3 |
1C
|
Цитата:
Сообщение от sukhanchik
Если Вы имеете в виду метод write на датасорсе PurchLine - то эффект проявляется на purchTable_ds.reread().
Бороться с этим можно по-разному: 1) Воспользоваться методом findRecord на purchLine_ds. Т.е. сначала запомнить курсор, затем скормить его: purchLine_ds.findRecord(курсор). Этим правда не рекомендуется пользоваться на больших количествах записей (свыше 1000) - к примеру - нехорошо так делать на PurchTable. Т.к. findRecord исполняется на датасорсе, где всего 180 записей - то тут можно применить сей метод 2) Попытаться понять - почему сделано именно так и что пострадает, когда код будет закомментирован. Этот метод ведет к большей переделке, однако он единственен, если записей много Вполне понятно, зачем это нужно - например, при изменении количества в строке может измениться статус закупки. Поэтому надо перечитать... Я воспользовался findRecord. Вроде, без тормозов. Спасибо. |
|
20.01.2006, 16:28 | #4 |
Administrator
|
Цитата:
Сообщение от andy239
Вполне понятно, зачем это нужно
Цитата:
Сообщение от MikeR
его нет среди предопределенных
__________________
Возможно сделать все. Вопрос времени |
|
22.01.2006, 12:33 | #5 |
1C
|
Цитата:
Сообщение от sukhanchik
Я имел в виду что помимо осознания зачем это нужно - еще необходима "обходная" реализация - т.е. переделка таким образом, чтобы и у вас все работало и чтобы не пострадал необходимый имеющийся функционал.
|
|
20.01.2006, 15:37 | #6 |
MCT
|
Если правильно понял reRead() - то это ссылка на метод и похоже его нет среди предопределенных.
Можно покапаться в слоях, так чтоб определить в каком слое добавлено. |
|
20.01.2006, 16:08 | #7 |
1C
|
Цитата:
Сообщение от MikeR
Если правильно понял reRead() - то это ссылка на метод и похоже его нет среди предопределенных.
Можно покапаться в слоях, так чтоб определить в каком слое добавлено. |
|