Нельзя.
Можно автоматом "расширять" любую колонку до доступной ширины.
И организовать "многострочный" показ (до 9 строк, фиксированно или по содержанию)
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Можно автоматом "расширять" любую колонку до доступной ширины.
И организовать "многострочный" показ (до 9 строк, фиксированно или по содержанию)
а какое свойство в настройках представления отвечает за этот автомат - "расширение"?
Последняя вкладка пропертей колонки - Extend to use ava1lable window width
Хочу запретить пользователям открывать документы во вложенном представлении. Т.е. представление использую только для отображения информации. При попытке открытия документа через двойной клик ничего не должно происходить. Это как-то настраивается?
Sub Queryopendocument(Source As Notesuiview, Continue As Variant)
Continue = False
End Sub
По поводу проблемы "после вызова и закрытия диалога сохраняется документ (пустой и без формы)". Перепробовал различные вариации: тип значений ставил Number и Text. Значения выставлял 0, 00, "0", "00", а также не забыл про commputed и computed for display. В любом случае сохраняется этот пустой документ. Пробовал программно через replaceitemvalue прописывать 0,00,"0", "00". Как-то все тщетно
[DOUBLEPOST=1429014903,1429014610][/DOUBLEPOST]Думал сделать агент удаления, только вот поля Form нет у него, т.е. в формуле не написать Form = "" и без этого ошибку выдает. Искать по полям в пустом доке, как вариант, но не очень-то и красиво, хотя может сработать.
[DOUBLEPOST=1429014903,1429014610][/DOUBLEPOST]Думал сделать агент удаления, только вот поля Form нет у него, т.е. в формуле не написать Form = "" и без этого ошибку выдает. Искать по полям в пустом доке, как вариант, но не очень-то и красиво, хотя может сработать.
Я тут задумался, но еще не опробовал. Тип формы Response/Document играет роль?
ХЗ. Никогда не приходило в голову брать для диалога Response Form
Код - позже. Я сейчас нервничаю с документацией по диплому. Кто-нибудь может подсказать как описать схему данных и структуру базы данных? Для реляционной БД - пустяки, а вот с лотусом что-то как-то не вяжется 
. Какая модель данных применяется в лотусе? ))
[DOUBLEPOST=1429208571,1429208310][/DOUBLEPOST]Это жесть. Иерархическая модель данных: похоже, только вот я в детях детей родителя храню инфу о родителе, т.е. это уже смахивает на сетевую модель. А что насчет объектной модели данных?
. Какая модель данных применяется в лотусе? ))[DOUBLEPOST=1429208571,1429208310][/DOUBLEPOST]Это жесть. Иерархическая модель данных: похоже, только вот я в детях детей родителя храню инфу о родителе, т.е. это уже смахивает на сетевую модель. А что насчет объектной модели данных?
+ у меня СЭД состоит из 6 баз данных. Не представляю как раздел с постановкой задачи описывать теперь.
И как связи между компонентами из разных БД указывать? :nailbiting:
И как связи между компонентами из разных БД указывать? :nailbiting:
спасибо за наводку. Почитал пару статей. Познакомился с NoSQL. Прихожу к выводу, что надо каждую форму документа представлять в виде таблицы (как в реляционной базе данных) и "связывать", тогда получится иерархическая модель данных. Тогда непонятно остается лишь наличие более одной базы данных. Надо ли в инфологической модели указывать БД или силой мысли убедить себя, что все 6-7 БД это одна БД и спокойно составлять инфологическую модель?
Баг с сохранением диалога решил. Диалог выбора пользователей сохранял документ, откуда вызывался диалог. Изначально создавал для главного документа, не подозревая тогда, что буду его же вызывать уже из другого диалога :inpain:
Начни с того, что ты делаешь не базу, а систему. Система может включать как 1, так и n баз, причем эти базы могут быть как объектные, так и реляционные,в которых ты хранишь свои данные....это может быть даже текстовые файлы. Поэтому описывать ты в первую очередь должен систему, которая обращаясь к нужным базам за той или иной информацией. В лотусе, к сожалению или к счастью если все держать в 1 базе, то со временем столкнешься с проблемами производительности и тогда ты начинаешь разделять свою систему из 1 базы на несколько, при этом логику и связи ты уже сам придумываешь. В результате у тебя получится горизонтальное масштабирование
???
Форма - только способ визуализации данных (абстрактных, в общем случае, которые хранятся где-то в айтемах).
Она не "привязана" к конкретному доку (наличие Form в доке, указывает только на возможность открытия этого дока по этой умолчальной форме).
erdi правильно говорит, что описывать надо систему (в смысле логику работы). Модель и структуру БД описывать выщще нет смысла. Если совсем общо - БД Лотус ВСЕГДА одна плоская таблица нот (note, как говорит вендор) с доступом к записи по ключу (UNID) или последовательным перебором записей. Views, Forms и прочая - по сути, доп приблуды для удобства "общения" с notes. БД может не содержать ни одного вида, ни к одному документу может быть не привязано ни одной формы и база будет вполне шустро работоспособной.
В LotusNotes нет никакой иерархии\древовидности (пусть не вводят в заблуждение всякие parents\childrens\responses).
Все связи определяются только на программном уровне (и не обязательно в видах и формах), а не структурой БД.
Разбивка приложения на несколько баз, делает более наглядной логику работы, может увеличить быстродействие, даёт доп гибкость в секурити, может упростить администрирование.
и сделали неправильный вывод
NoSQL - это прежде-всего key-value
т.е. - быстрое получение значения по ключу/чам
при этом, в силу особенностей (домины и кочДБ, например) - запись не самая быстрая операция
присутствие индексов видов "усугубляет" ситуацию
НО тот же твитер и мордокнига - кейвэлью БД
РСУБД - неудачная модель для плохоструктурированных данных, там есть решения, но они не лучше кейвэлью (а даже хуже
)Обучение наступательной кибербезопасности в игровой форме. Начать игру!