24.10.2003, 10:37 | #1 |
Участник
|
как запретить редактирование всей строки DataSource?
Добрый день!
Кто-нибудь может сказать как программно осуществить $subj ? Нужно запретить для редактирования строки DataSource с определенным значением одного из полей. Смотрел там http://www.axforum.info/forums/showt...&threadid=2659, но мне нужен запрет на уровне именно DataSource, а не Grid, т.к. часть полей отображается не на Grid. Заранее благодарен. |
|
24.10.2003, 11:03 | #2 |
NavAx
|
PHP код:
|
|
24.10.2003, 11:27 | #3 |
NavAx
|
Это для столбца:
Цитата:
Изначально опубликовано raz
PHP код:
перекрываем cursorNotify у датасорса: PHP код:
__________________
С уважением, Игорь Ласийчук. |
|
|
За это сообщение автора поблагодарили: konopello (1), Corel (1). |
24.10.2003, 11:31 | #4 |
Участник
|
спасибо!
Чертовски изящно, однако... |
|
27.10.2003, 14:55 | #5 |
Участник
|
Оставьте в покое cursorNotify() !!!!!!!!!!!!!
для этих целей предназначен active() на датасорсе.
cursorNotify() нужен совсем для другого!!! |
|
|
За это сообщение автора поблагодарили: Hans (1). |
27.10.2003, 19:38 | #6 |
Сенбернар
|
громко А пояснить, для тупых (меня)?
__________________
Best Regards, Roman |
|
28.10.2003, 06:41 | #7 |
Участник
|
попробовал active(). разницы пока не заметил.
А в самом деле, в чем она заключается? И почему "совсем для другого"? |
|
|
За это сообщение автора поблагодарили: Hans (1). |
28.10.2003, 09:27 | #8 |
Участник
|
Re: Оставьте в покое cursorNotify() !!!!!!!!!!!!!
Цитата:
Изначально опубликовано ta_and
для этих целей предназначен active() на датасорсе. cursorNotify() нужен совсем для другого!!! |
|
28.10.2003, 11:15 | #9 |
NavAx
|
Да, для этих целей надо использовать active. cursorNotify я использую по привычке.
Посмотрел внимательней на работу cursorNotify Судя по всему он работает так: cursorNotify(int event): event = 0 - подчитываются данные из существующего курсора event = 1 - (не совсем понятно) был создан курсор с фильтрацией event = 2 - курсор закрылся и открылся новый event = 3 - аналогичен методу active
__________________
С уважением, Игорь Ласийчук. |
|
21.05.2010, 13:47 | #10 |
Участник
|
А ести ли возможность запретить редактирование почти все строки (без припустим одного поля)???
Проблема слудующая: - Добавили 1 кастом-поле в таблицу (таблица большая и со сложной AllowEdit логикой на уровне полей) - После постинга вся строка датасорса имеет AllowEdit = false - Но добавленое поле должно всегда быть активно Как можно с минимальными усилиями это обойти? |
|
21.05.2010, 13:52 | #11 |
Moderator
|
Цитата:
Сообщение от andriy_s
А ести ли возможность запретить редактирование почти все строки (без припустим одного поля)???
Проблема слудующая: - Добавили 1 кастом-поле в таблицу (таблица большая и со сложной AllowEdit логикой на уровне полей) - После постинга вся строка датасорса имеет AllowEdit = false - Но добавленое поле должно всегда быть активно Как можно с минимальными усилиями это обойти? |
|
21.05.2010, 14:33 | #13 |
Мрачный тип
|
Цитата:
1) Закомментировать изменение AllowEdit на источнике, оставив всегда в true 2) В том же месте добавить вызов функции, в которой будет происходить перебор полей (через DictTable и DictField) источника данных и установка их AllowEdit, кроме избранных, в false Но лучше так не рисковать 2S.Kuskov Я так понимаю, что это с версий выше 3-ки в Global появилось ?
__________________
Мы летаем, кружимся, нагоняем ужасы ... Последний раз редактировалось TasmanianDevil; 21.05.2010 в 14:36. |
|
21.05.2010, 16:18 | #14 |
Участник
|
Все прекрасно работает с помощью Global::allowEditFieldsOnFormDS_W.
КРОМЕ 1 поля, editContactPersonName - которое формируется edit методом. X++: client server edit ContactPersonName editContactPersonName(boolean _set, ContactPersonName _name) |
|
|
За это сообщение автора поблагодарили: S.Kuskov (1). |
21.05.2010, 16:48 | #15 |
Участник
|
А ведь точно. Про edit-методы то я и не подумал. И видимо не только я но и локализаторы.
Дело в том что доступность полей, основанных на edit-методах определяется свойствами самого DataSource. Получается, для того чтобы гарантированно отключить все edit-методы, необходимо обойти все контролы на форме, проверить их на причастность к edit-методам, и выставить AllowEdit непосредственно на контролах Обойти контролы можно при помощи итератора с поддержкой методов обратного вызова для обработки контролов на форме Последний раз редактировалось S.Kuskov; 21.05.2010 в 16:52. |
|
21.05.2010, 17:46 | #16 |
Участник
|
Спасибо! Очень помогли
|
|
22.06.2011, 12:00 | #17 |
Модератор
|
Понимаю, что вопрос уже закрыли:
Цитата:
Сообщение от andriy_s
А ести ли возможность запретить редактирование почти все строки (без припустим одного поля)???
Проблема слудующая: - Добавили 1 кастом-поле в таблицу (таблица большая и со сложной AllowEdit логикой на уровне полей) - После постинга вся строка датасорса имеет AllowEdit = false - Но добавленое поле должно всегда быть активно Как можно с минимальными усилиями это обойти? Методы Dynamics Ax 2009 Sp1 Ru7: \Classes\Global\allowEditFieldsOnFormDS_W \Classes\Global\dsSetFieldAllowEdit_RU //тоже самое что и код ниже \Classes\Global\dsSetFieldGroupAllowEdit_RU \Classes\Global\dsSetFieldsAllowEdit_RU или пример в \Forms\BankAccountTrans\Methods\initDesign_LV X++: void initDesign_LV() { DictTable dictTable = new DictTable(bankAccountTrans_ds.table()); ; bankAccountTrans_DS.allowEdit(true); //Disable editability of all fields for datasource allowEditFieldsOnFormDS_W(bankAccountTrans_DS, false); //Enable editability of Notification fields. bankAccountTrans_ds.object(fieldnum(BankAccountTrans, CorrespondentCountry_LV)).allowEdit(true); bankAccountTrans_ds.object(fieldnum(BankAccountTrans, CentralBankPurposeText_LV)).allowEdit(true); bankAccountTrans_ds.object(fieldnum(BankAccountTrans, CentralBankPurposeCode_LV)).allowEdit(true); bankAccountTrans_ds.object(fieldnum(BankAccountTrans, BankPaymentRegistrationNum_LV)).allowEdit(true); }
__________________
This posting is provided "AS IS" with no warranties, and confers no rights. |
|
|
За это сообщение автора поблагодарили: NataLee (1), S.Kuskov (1), SuperStar88 (1). |
22.06.2011, 12:54 | #18 |
Участник
|
Интересно, а метод \Classes\Global\dsSetFieldGroupAllowEdit_RU что-нибуть делает с edit-методами, содержаoщимися в блокируемой группе?
P.S.: К сожалению сам пока RU7 пощупать не могу. |
|
04.07.2012, 13:12 | #19 |
Участник
|
Наступил только что на, акуратно разложенные самим же собой, грабли в виде свойства таблицы MaxAccessMode установленного в значение "View". Понадобилось мне к датасурсу с этой таблицей приджойнитье ещё одну таблицу и открыть в связанной таблице одно поле на редактироавние (в связанной таблице MaxAccessMode = Delete). Ситуация получилась аналогичная той где изменения блокировались на уровне источника данных. Т.е. также автоматически заблокировалось и поле из связанной таблицы .
Для исправления ситуации пришлось выставить в свойствах таблице значение MaxAccessMode = Edit, а уже у самих поле AllowEdit = No. Конечно, после такой "подмены" в случае добавления новых полей в таблицу придётся закрывать от редактирования и их. Вообще, имхо, это неправильное поведение системы. Зачем принимать решение о блокировке подчинённых полей основываясь на свойствах главного датасурса/таблицы? Последний раз редактировалось S.Kuskov; 04.07.2012 в 13:17. |
|
04.07.2012, 15:33 | #20 |
Administrator
|
Цитата:
Например, пусть у MainTable MaxAccessMode = View, а у DetailTable MaxAccessMode = Delete. Теперь добавим в форму два DataSource - MainTable и DetailTable - и свяжем их. Если создать Grid, привязанный к DataSource MainTable, то ничего в нём редактировать будет нельзя, так как система смотрит на уровень доступа к датасорсу контейнера (в данном случае, контейнер - это Grid). Но если поля из DetailTable привязать к контролам, не входящим в Grid (например, выводящимся под Grid), то их можно будет спокойно редактировать, даже несмотря на то, что у основной таблицы MaxAccessMode = View.
__________________
Not registered yet? Register here! Have comments, questions, suggestions or anything else regarding our web site? Don't hesitate, send them to me |
|