• Курсы Академии Кодебай, стартующие в мае - июне, от команды The Codeby

    1. Цифровая криминалистика и реагирование на инциденты
    2. ОС Linux (DFIR) Старт: 16 мая
    3. Анализ фишинговых атак Старт: 16 мая Устройства для тестирования на проникновение Старт: 16 мая

    Скидки до 10%

    Полный список ближайших курсов ...

Field Create

  • Автор темы alexmix
  • Дата начала
A

alexmix

Плз, подскажите как по какому-либо событию на форме создавалось поле (изначально его НЕТ в форме), которое пользователь мог видеть и редактировать.Спасибо.
 
E

Elena Nefedova

Что имеется в виду - тонкий клиент или толстый?
 
A

alexmix

Следующая ситуация: создаю форму для оплаты счетов, изначально неизвестно сколько будет позиций в счете.Так вот, пользователь сам определяет сколько необходимо полей.
 
E

Elena Nefedova

Следующая ситуация: создаю форму для оплаты счетов, изначально неизвестно сколько будет позиций в счете.Так вот, пользователь сам определяет сколько необходимо полей.
Не так все просто. В руководствах вот пишут, что один лотусовый документ отдаленно соответствует одной записи в таблице реляционной базы данных. Соответственно, надо не создавать поля динамически, а добавлять новые документы "позиция" для каждой позиции счета. И счета тогда будет проще переформировывать. А окончательный счет уже генерить на базе этих позиций и записывать в базу, не давая пользователям возможности изменить закрытый счет.

Если же нужно кровь из носу динамические поля создавать, то вот пример обработки в одной форме непостоянного количества полей (1-100):
Посмотреть вложение LiveItems.rarПредполагается, что это диалоговое окно вызывается из агента с уже заполненными предварительно полями CompNameXX и nComputers аналогично тому, как это сделано в документе примера.
Вот от этого можно плясать, разрабатывая свои варианты - добавлять поля, убавлять и прочая...
Но первый вариант гораздо лучше!
 
30.05.2006
1 345
12
BIT
0
Следующая ситуация: создаю форму для оплаты счетов, изначально неизвестно сколько будет позиций в счете.Так вот, пользователь сам определяет сколько необходимо полей.
Да уж.. Странного хотите.
Проблема в чем: если прикладной док-т - весь из себя динамический, то форма, его отображающая объект скорее статический. При дизайне формы вы-ж не только кол-во полей определяете, но и их имена, тип, интерфейс (типа CheckBox, PickList etc; цвет/шрифт/положение), формулы проверки. Это все тоже юзер САМ должен решать? Если да, то просто дайте ему Дизайнера а сами увольняйтесь ;)
Варианты:
  • N однотипных значений можно ввести/вывести через multivalue поле
  • на форме заготовить неколько рабочих полей, которые в translation formula делают @SetField("ЮзерПоле", val), а сами не сохраняются
  • генерить форму динамически - по XML
 
A

alexmix

спасибо всем,есть над чем задуматься .
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!