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

  • Автор темы Guest
  • Дата начала
G

Guest

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

morpheus

скриптописец
07.08.2006
3 915
1
#2
Николай (Красноярск)
можно...

можно просто пропистьа явно имя нового поля на собаках
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

Well-known member
28.02.2008
266
0
#3
Всем добрый день.
Задача: Есть документ, который обрабатывается различными способами (вручную, программно). В документе есть поля, которые при обработке переполняются. Допустим, мы поймали ошибку переполнения поля, но оставшиеся записи нам же надо куда-то помещать.... Вопрос: можно ли программно создавать в документе поля, которые будут существовать не только в документе, но и на дизайне, или как у полей, которые создаются просто в документе менять их тип, например на Authors.
Заранее спасибо.
Нельзя. Можно создать программно только айтемы, но не поля.
 
G

Guest

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

Guest

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

LIGHT

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

Omh

Lotus team
04.07.2007
2 210
1
#9
Cамое простое и быстро реализуемое, но не разумно :)
 

Extraterrestrial

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

Guest

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

morpheus

скриптописец
07.08.2006
3 915
1
#13
ага и для каждогго десятка полей ещё надо вычислить формулу скрытия - оччень быстро получиться
 
V

vladoos

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

Akupaka

А че я?.. О.о
04.10.2007
3 360
1
#16
Все, конечно же, зависит от кол-ва полей. Если есть 100 и более полей, которые еще надо продублировать, протроировать и так далее, то может это и не вариант. Но если таких полей десятки - то ничего страшного не произойдет. Опять же, если у вас клиенты сидят на модеме, то лучше поля не множить без дела.
ага и для каждогго десятка полей ещё надо вычислить формулу скрытия - оччень быстро получиться
да фигня это все, получится достаточно быстро! тем более, что расчет скрытия идет на основании данных в том же документе! дело ж не в обращении к другим документам или базам!..
думаю, что если надо быстро, то дубляж полей вполне устроит, но проблема в том, что они не универсальны... кроме того, если к примеру, эти данные нужно лишь отобразить, то вполне можно использовать RT-поля, а авторс-данные хранить в итемах документа и не отображать их, а использовать для построения данных в отображаемом RT-поле...
если надо еще и исправлять, то можно доделать свой механизм, сложости не много...