Еще раз про пользовательские настройки форм

[Ace of Database]

Привет всем!

Почему-то нельзя добавить в форму "Закупка" из Расчетов с Поставщиками поля во все группы контролов, которые принадлежат вкладке "Строки".

Когда открываешь пользовательские настройки формы, то в дереве видно, что у вкладки с именем TabLine, нарисован замок. Такой же замок нарисован у всех дочерних для этой вкладки контролов.

Свойство AllowUserSetup у вкладки установлено в Yes.

В чем может быть дело?

[MironovI]

У Tab формы перекрыт метод TabChange - если его убить - будет вам счастье.. много счасться

[Delfins]

Странно,.. у меня тоже...

Может где какой Class `поправляет` значение

[Delfins]

MironovI, mozhet znajesh pochemu takoj plohoj super(...) ??

[MironovI]

Смысл в том, что перекрывая TabChange мы "насильственно" управляем поведением формы, которая изначально IntelliMorf.. ну или как-то так.. - вобщем поскольку гарантировать нормальную работу после этого система не может - пользовательские настройки лочит. Как вариант - смотреть код TabChange и переносить его куда-нить, а метод убивать..

[Ace of Database]

Спасибо, MironovI
Там метод tabChanged для номенклатуры-основного средства показывает группу контролов Asset_RU, а для остальных номенклатур прячет эту группу.

Наверное, придется это перекинуть куда-нибудь в PurchLine_DS.active(), а tabChanged удалить.

[Peter Savintsev]

Я этот код переносил в pageActivated для 2-го TabPage.

[sukhanchik]

Руководство разработчика, раздел Coding for user setup of forms:

Coding for user setup of forms
Restraints on user setup due to coding style
In order for user setup to work, it is important that the code is independent of the actual positioning of the control, meaning that the developer must not use any information on the position of the control or assume that the ordering of controls is retained.

In some cases, the kernel will automatically restrict the user setup level. This is due to overridden methods on the control, which consider the position of the control.

Tab controls
If either of the below methods are overridden, the user setup level of “tab controls” cannot be higher than restricted, regardless of the property value.

tabChange

tabChanged

The reason for this is that these methods receive integer values for the FromTab and ToTab parameters.

public void tabChanged(int _FromTab, int _ToTab)

Because it cannot be certain what the exact values of these tabs are, the methods will lose focus on the index of the tab, and focus is put on the tab as a parameter. If the tab pages are reordered by the user, the parameters passed to these functions will lose their meaning. Therefore, it is possible to either override these methods, or allow for full customization of layout and content.

The following methods on the “tab page control” should be used instead:

pageActivated

allowPageDeactivate

These methods do not pass any information on the current positioning of the tab page, and therefore the code should be independent of the positioning.

MenuButton control
User setup level for this control is limited to “restricted” if the clicked method is overridden. This is because this method is usually used to add menu-items from code, and this does not work well with user setup of forms.

Coding style
When a data bound control is added to the form, a new control of the correct type is created, and the properties Name, Datasource, DataField, Label, and HelpText are set.

Because the control is automatically added by the system, the developer cannot add custom code to the control, but the control can use the code defined on the data source and the data source fields. This is why it is so important that the code from the controls is moved to the datasources. Note that lookup now can be coded on the datasource field.

Names of controls
To determine which control has been moved, it is crucial that a control can be identified by a unique name. Currently the setup information is packed with the control name and the control type, but control’s name should be unique.

Controls bound to fields in the auto fieldgroups are automatically given the name:

<groupName>_<FieldName> for data fields

<groupName>_M_<FieldName> for display methods

Therefore, these names should be avoided elsewhere in the system.

When the user creates new controls, they are automatically given a name which contains the user id and a counter number, so name clashes should be avoided.

Тут достаточно подробно описаны все нюансы доступности пользовательской настройки

[belugin]

и тут подборка ссылок:
http://erpkb.com/Axapta/Pol'zovatel'skajaNastrojjkaInterfejjsa