kamalblogs: Creating Edit methods for DS that don’t allow editing in Dynamics ax

[Blog bot]

Источник: http://kamalblogs.wordpress.com/2010...n-dynamics-ax/
==============

Let’s say we have a Datasource and it is being displayed in the grid. The user has to choose one of it to further proceed. The use case is that you must be able to use a checkbox to select the records but you should not be able to modify rest of the information.

Technical implementation:
First Thought: Set allow create, allow delete allow edit property on the ds as false. Consequence: when you set allow edit as false you will no more be able to edit the checkbox also which is undesired.
Second Thought: Set allowedit false control wise either in the ds or in the formcontrol. Consequence: Too much work/customization. If done at formcontrol level the user can even add a field through
the syssteupform and start editing it (Refer here for details: http://wp.me/p298V-2IL)

Best Approach: Set allow edit to true in the ds . Override the write method in the ds and comment the super. Consequence: Peaceful solution

public void write(){ ; I4C_InventTrans_ds.reread(); I4C_InventTrans_ds.refresh(); //super();}



Источник: http://kamalblogs.wordpress.com/2010...n-dynamics-ax/

[greench]

Он бы еще рассказал как написать select, который не выбирает записей.

[TasmanianDevil]

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

Мы решали этот вопрос просто - всем полям DS устанавливалось свойство AllowEdit = false, а на DS AllowEdit = true. Пользователь не мог и не пытался что-либо изменить в таких формах, кроме пометки, и у него не было повода задать дурные вопросы типа "Я вот тут менял, а чего оно не сохранилось ?"

[greench]

Я к тому и смеюсь, что комментирование super(), имхо, далеко не самый лучший вариант. Пользователей это будет сбивать с толку.

[belugin]

Цитата:

Сообщение от TasmanianDevil

Мы решали этот вопрос просто - всем полям DS устанавливалось свойство AllowEdit = false, а на DS AllowEdit = true.

чтобы облегчить такие штуки есть функция allowEditFieldsOnFormDS_W (класс Global).

[casperkamal]

@Tasmainan Devil: Yes that could be a option but that means you also have a risk. See here for more details http://bit.ly/eV79e2

@belugin: I didn't find that method in global and also in the AOT..is it some where else ?

[belugin]

This is a global method on Russian + Eastern Europe GLS.

[TasmanianDevil]

@casperkamal
It seems like some bug - the field added from datasource does not inherits from datasource his specific edit properties for added field, which does not conflict with edit properies for this field from AOT. At any case the prohibition adding fields on specific form will solve this problem.

[S.Kuskov]

Справедливочти ради стоит отметить, что функция allowEditFieldsOnFormDS_W работает на уровне источника данных и оперирует свойствами его полей. При таком подходе неучтённым остаются edit-методы, которые также как и обычные поля могут являтьсь частью дизайна. В таком случае запретить редактирование элементов управления, связанных с edit-методами, можно только напрямую, изменив свойства у самого элемента управления.