Как проверить факт существования (использования, открытия) формы


Обратите внимание, что здесь используется системная переменная _VFP. Использовать аналогичный синтаксис с системной переменной _SCREEN - не получится. Коллекция _SCREEN.Forms() не принимает в качестве параметра символьные значения. Только числовые.

Кроме того, данный способ не сработает для форм, имеющих значение совйства ShowWindow = 2 - As Top-Level Form. В этом случае придется просто перебирать весь массив _SCREEN.Forms() или _VFP.Forms()

miv321) Необходимо перед сохранением данных проверять поля, необходимые для заполнения.
Этим должна заниматься сама база данных, а не форма. Контроль на уровне интерфейса - это вспомогательный инструмент. Окончательный контроль на уровне данных. Например, RULE-записи (RULE-поля слишком жестко и не удобо для пользователя) или в триггере. Может, Вы заполняете некое поле программно, на основе введенных пользователем значений?

miv32Мудрить код под кнопкой "Сохранить" в каждой форме как-то не спортивно.
Как правило, этот код заключается в одной или нескольких командах TableUpdate() если необходимо, окруженных транзакцией. Если все-таки необходима некая проверка перед сохранением, то, как правило, она уникальна для каждой формы.

miv322) Enabled/Disabled;Visible/Invisible элементов на форме.
(для разных пользователей разный уровень доступа)
Ну, успехов в этом трудном деле. Мало будет один раз открыть, надо будет еще синхронизировать ту таблицу, где будут помечаться эти самые разрешения/запреты и изменения в формах. Если удалили объект в форме, то надо будет не забыть удалить запись в таблице. Особое удовольствие Вы получите, когда некие объекты формы сначала были в контейнере, а потом контейнер удалили, но объекты оставили. Или наоборот, объекты лежали на форме, а потом их положили в контейнер.

Более простой представляется схема, когда форма сама настривает доступ к объектам в зависимости от выполняемых функций. Т.е. права раздаются не на уровне объектов, а на уровне выполняемого функционала. А уж какой объект какому функционалу соответствует форма должна "знать" сама.

miv32Сами формы юзеры трогать не будут. Права на изменения доступности полей только у админа.
Какое отношение к модификации форм имеют юзеры? Вообще никакого! Это Вы себе кучу проблем создаете при таком подходе. Вы же будете "связаны по рукам и ногам" при любой, даже самой незначительной, модификации формы. Любой формы! Вы будете постоянно бороться с проблемой вроде доступ дали, а не доступно. Или наоборот, доступа нет, а доступно. По банальной причине, у Вас будет постоянная рассинхронизация реального "дерева объектов" и прав доступа назначенных на ту или иную "ветку объектов"

miv32Сейчас реализовано следующим образом:
При загрузке формы сканируется табличка. Ищутся объекты и в зависимости от прав юзера объекты на форме Видимы/Невидимы, Доступны/Недоступны. Если объект не найден в таблице, то соответственно ставятся дефаултные значения, т.е. полный доступ.

Да со стороны формы понятно что будет происходить. Проблема именно с настройками.

miv32Дело в том, что в разных конторах функционал могут выполнять либо несколько человек, либо один. Например: "Оператор", "Кассир","Менеджер","Директор"

Оператор может регистрировать клиентов, но не должен видеть кассовые операции, Для Кассира с точностью до наоборот. Менеджер может только видеть, ничего крутить не должен. А директор должен иметь право на все. :)

Ни и зачем Вам в этой идеологии при настройке прав "опускаться" до уровня отдельных объектов формы? Форма должна сама "знать" какие объекты к какому функционалу относятся и что с ними можно делать.

Как это можно реализовать? Ну, например, добавить каждому объекту по парочке свойств. Одно будет хранить название "функционала", например, "Кассир, Менеджер", а второе - тип операции "Show, Edit, Add, Update". Далее смотрите, есть ли права на пару значений "Функционал-Действие" и соответственно разрешаете/запрещаете что-то делать. Сам форма за этим следит. Нет необходимости "вручную" заниматься такой мелочевкой

miv32Но вот таблицу пришлось руками делать. Я хотел, чтобы был некий интерфейс, чтобы "Директор" сам создавал профили. И для любого сотрудника выбирал нужный.
Да не получится по простому это сделать. Я же уже говорил. Проблема будет не в первоначальном создании, а в синхронизации этой самой таблички и изменений в формах. Проблем "огребете" по самое "не балуйся".

Есть такой журнал FoxTalk. Сайт русскоязычного издания http://newsletter.narod.ru/foxtalk/FoxTalk.htm

Так вот, в номерах 5,6,7 за 2005 была статья: "Тук, тук! Кто там?" Авторы Энди Крамек и Марсиа Акинз. Эта статья как раз и посвященная одной из стратегий настройки прав доступа. Если вкратце, то там они давали права на доступ к полям таблиц, и по значению ControlSource объектов идентифицировали эти права.

К сожалению, пока эти статьи не выложены в свободный доступ, но можно свободно скачать коды примеров по этим статьям на том же сайте. В принципе, по коду можно понять, как это все "тикает". Достаточно скачать код к последнему номеру.

Принцип, по которому они обновляли права доступа был описан в 6 номере за 2004 год в статье "Чья же это все-таки работа?". Вот эту статью можно скачать с сайта. В статьях 2005 года использовался тот же принцип, просто к нему "прикрутили" таблицы с настройкой прав.