Динамическое создание полей на форме.......

[Guest]

Всем добрый день.
Задача: Есть документ, который обрабатывается различными способами (вручную, программно). В документе есть поля, которые при обработке переполняются. Допустим, мы поймали ошибку переполнения поля, но оставшиеся записи нам же надо куда-то помещать.... Вопрос: можно ли программно создавать в документе поля, которые будут существовать не только в документе, но и на дизайне, или как у полей, которые создаются просто в документе менять их тип, например на Authors.
Заранее спасибо.

 

[morpheus]

Николай (Красноярск)
можно...

можно просто пропистьа явно имя нового поля на собаках
FIELD MyFieldIndex3 := "qwerty"; - в свойствах документа вы увидете поле MyFieldIndex3 со значением qwerty

для того чтобы играться с типами полей есть такой класс NotesItem class, у него есть свойства IsAuthors

Example
Read-write. Indicates whether an item is of type Authors. An Authors item contains a list of Notes user names, indicating people who have Author access to a particular document.

 

[Extraterrestrial]

Всем добрый день.
Задача: Есть документ, который обрабатывается различными способами (вручную, программно). В документе есть поля, которые при обработке переполняются. Допустим, мы поймали ошибку переполнения поля, но оставшиеся записи нам же надо куда-то помещать.... Вопрос: можно ли программно создавать в документе поля, которые будут существовать не только в документе, но и на дизайне, или как у полей, которые создаются просто в документе менять их тип, например на Authors.
Заранее спасибо.

Нельзя. Можно создать программно только айтемы, но не поля.

 

[Guest]

Morpheus спасибо))) совсем забыл про это свойство.

 

[Constantin A Chervonenko]

можно ли программно создавать в документе поля, которые будут существовать не только в документе, но и на дизайне, или как у полей, которые создаются просто в документе менять их тип, например на Authors.

Что значит "на дизайне"?
В формулах/скриптах? No problem: всегда есть возможность проверить наличие поля (item-а)/получить их список; обратиться к item-у по имени.
На форме? Но там у поля еще много реквизитов, кроме имен и значения: позиция; формат отображения; редактируемость.. Элементарно: место-то для очередного поля найдется?
Если найдется (предусмотрено), то отобразить/отредактировать на этом месте "лишний" item не сложно, даже чистА на "собаках": в Default value @GetField(имя); в Translation - @SetField(имя; @ThisValue)
А еще есть DXL. Там можно потроха формы на лету перетряхнуть. Но отображаться сразу не будет: дизайн кешируется

 

[morpheus]

А еще есть DXL.

кстати да, созвсем про него забыл... но думаю тут будет уже лишним

 

[Guest]

Можно заранее в дезигнере поля нарисовать, просто скрывать их. Чтобы они пустыми не мешались - можно их удалять по условию какому-нибудь.

 

[LIGHT]

Можно заранее в дезигнере поля нарисовать, просто скрывать их. Чтобы они пустыми не мешались - можно их удалять по условию какому-нибудь.

Разумно, мы и менно так и делаем, самое простое и быстро реализуемое. А скрываем их если они пусты.

 

[Omh]

Cамое простое и быстро реализуемое, но не разумно

 

[Constantin A Chervonenko]

Почему-ж...
Прозрачнее - легче сопровождать потом

 

[Extraterrestrial]

По-моему, если на форме слишком много полей, то она может тормозить. Давно я такой вариант пробовал, но кажется отказался именно поэтому, точно уже не помню. А зачем вообще нужны новые поля Вам?

 

[Guest]

Все, конечно же, зависит от кол-ва полей. Если есть 100 и более полей, которые еще надо продублировать, протроировать и так далее, то может это и не вариант. Но если таких полей десятки - то ничего страшного не произойдет. Опять же, если у вас клиенты сидят на модеме, то лучше поля не множить без дела.

 

[morpheus]

ага и для каждогго десятка полей ещё надо вычислить формулу скрытия - оччень быстро получиться

 

[vladoos]

Среди всех возможностей решения динамичекского тодбражения поля на форме забыли упомянуть, http+javascript и java applets. Аплеты по производительности и глючности непредпочтительны, но не имеют никаких ограничений, а вот яваскрип не всегда применим, но если нужно прото отображение без обработки - самое то: быстр как гепард, лёгок - как одуванчик, надёжен - как ломом об голову, не плодит лишних полей, кода, пр.. но полностью отутствует доступ к DOM. Самое интересное конечно DXL, но кроме интереса ничего интересного в нём нет

 

[Sandr]

философская тема

 

[Akupaka]

Все, конечно же, зависит от кол-ва полей. Если есть 100 и более полей, которые еще надо продублировать, протроировать и так далее, то может это и не вариант. Но если таких полей десятки - то ничего страшного не произойдет. Опять же, если у вас клиенты сидят на модеме, то лучше поля не множить без дела.

ага и для каждогго десятка полей ещё надо вычислить формулу скрытия - оччень быстро получиться

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