Профили меню в БД MSSQL

← →
pleasure © (2010-03-31 21:43) [0]

ни как не додумаюсь как и что сохранять в базе, что бы при восстановлении формы меня восстанавливалось из БД

← →
И. Павел © (2010-03-31 23:07) [1]

Часто для восстановления состояния формы используют ini файлы (TINIFile):

http://mirsoft.3dn.ru/publ/3-1-0-54

Для каждой формы сохраните там:
Form1.Top
Form1.Bottom
Form1.Width
Form1.Height
ну и все остальное, что нужно.

А при запуске программы читайте INI файл и восстанавливайте состояние формы.

Еще можно реестр использовать. Скорее всего, найдутся и сторонние компоненты, которые это делают.
База тут ни при чем :)

← →
И. Павел © (2010-03-31 23:11) [2]

> Профили меню в БД MSSQL

Хотя может быть я не понял вопроса...
Что такое "профиль меню"?

← →
Медвежонок Пятачок © (2010-04-01 00:24) [3]

как и что сохранять в базе, что бы при восстановлении формы меня восстанавливалось из БД

как: инсертами
что: как минимум иерархию элементов меню, их капшены и ID

← →
MsGuns © (2010-04-01 02:10) [4]

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

← →
pleasure © (2010-04-01 07:11) [5]

не формы, а меню (профили пользователей - административное меню, меню оператора, и т.д.)

← →
И. Павел © (2010-04-01 08:24) [6]

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

В общем случае я бы делал в ini файле для каждого профиля так:
Файл
Открыть
Открыть файл : OnOpenFile
Открыть проект : OnOpenPrj
Закрыть :OnCloseFile
О программе
Справка : OnHelp
О программе : OnAbout
Выход
Выход :ExitProgram

То есть вложенность показана числом пробелов (или других символов) в начале строки, а после двоеточия (или в новом ключе - кому как нравится) - имя обработчика пункта меню.
Если этот файл общий - наверное, можно просто разместить его в общедоступном месте.

Хотя опять-таки мне не понятно, в чем конкретно у автора возникла сложность.

← →
И. Павел © (2010-04-01 08:25) [7]

Пробелы исчезли :)

Файл Открыть Открыть файл : OnOpenFile Открыть проект : OnOpenPrj Закрыть :OnCloseFile О программе Справка : OnHelp О программе : OnAbout Выход Выход :ExitProgram

← →
pleasure © (2010-04-01 08:50) [8]

какие параметры mainmenu или actionlist сохранять, чтобы затем восстанавливать при открытии. (сохраняется один раз и при необходимости дополняется или урезается)

← →
И. Павел © (2010-04-01 08:56) [9]

А может быть просто делать пункты меню видимыми/невидимыми (активными/неактивными) в зависимости от профиля? Тогда нужно сохранять только по одному числу для каждого пункта: 0-этот пункт невидимый, 1-видимый. Например есть пункты: Создать, Редактировать, Просмотреть, Выход. Для пользователя можно сохранить (0, 0, 1, 1) а для администратора (1, 1, 1, 1).

← →
Anatoly Podgoretsky © (2010-04-01 09:15) [10]

> И. Павел © (01.04.10 08:56) [9]

Такая защита взламывает за секунду.

← →
Медвежонок Пятачок © (2010-04-01 09:26) [11]

какие параметры mainmenu или actionlist сохранять

тебе ж сказали уже.
- наименование пункта меню (видимый юзеру капшен)
- id пункта меню (для обработки нажатия на этот пункт)
- положение этого пункта в иерархии меню (так как меню иерархическое)

← →
pleasure © (2010-04-01 09:40) [12]

у меня не получается сохранить всё меню с под меню, при
for i:=0 to Menu.Items.Count-1 do
begin
Memo4.Lines.Add(IntToStr(Menu.Items.Count));
Memo4.Lines.Add(Menu.Items.Items[i].Name);
end;
выводится только основное меню без подменю, таких как [Файл]->Открыть-> Сохранить.... нет. То что в квадратных скобках есть ;)

← →
Медвежонок Пятачок © (2010-04-01 09:51) [13]

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

← →
pleasure © (2010-04-01 10:03) [14]

тогда код сохранения и восстановления(построения) меню будет выглядеть, как?
Шаблон можно?

← →
Медвежонок Пятачок © (2010-04-01 10:06) [15]

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

← →
Медвежонок Пятачок © (2010-04-01 10:08) [16]

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

← →
pleasure © (2010-04-01 10:12) [17]

так....
Memo4.Lines.Add(IntToStr(Menu.Items.Count));
for i:=0 to Menu.Items.Count-1 do
begin
Memo4.Lines.Add(Menu.Items.Items[i].Name);
for j:=0 to Menu.Items.Items[i].Count-1 do
begin
Memo4.Lines.Add(" "+Menu.Items.Items[i].Items[j].Name);
end;
end;

результат

7
File1
Open1
OpenWith1
N3
PrintSetup1
Run1
N2
Exit1
Edit1
Cut1
Copy1
Paste1
Delete1
SelectAll1
Undo1
Search1
Find1
FindFirst1
FindNext1
Replace1
AutoCheck1
GroupedAction11
GroupedAction21
GroupedAction31
N1
AutoCheckAction1
GroupedAction12
BrowseURL2
DownloadURL2
SendMail2
Dialog1
SelectColor1
SelectFont1
OpenPicture2
GroupedActions11
Previous1
Next1

используется пример из Demo Delphi - Actions.
это допустим сохранение, а восстановление как организовать?

← →
pleasure © (2010-04-01 10:14) [18]

а куда форматирование текста делось? странно ....

← →
Медвежонок Пятачок © (2010-04-01 10:51) [19]

а восстановление как организовать?

восстановление уже никак не организовать, так как при сохранении ты потерял иерархию меню (информацию о том, кто чей чайлд)

← →
И. Павел © (2010-04-01 10:56) [20]

> pleasure © (01.04.10 10:14)

Читайте memo строчку за строчкой и создавайте пункты меню. Как только встретите пункт без пробела в начале, запомните его и используйте в качестве родителя для всех остальных пунктов.

> [19] Медвежонок Пятачок © (01.04.10 10:51)

Там во внутреннем цикле пробел в начале ставится. ИМХО, для менб без вложений пойдет.

← →
pleasure © (2010-04-01 12:47) [21]

тогда зреет вопрос чтобы без геммороя и лишних движений сохранить и восстановить всю иерархию можно каким путем?

Там во внутреннем цикле пробел в начале ставится. ИМХО, для менб без вложений пойдет.

Ты же вроде собирался в базе данных хранить структуру меню.
итого получается:
много строк в бд без пробелов и часть строк с пробелами.
и как ты определишь какие строки с пробелами какому паренту принадлежат?

> тогда зреет вопрос чтобы без геммороя и лишних движений
> сохранить и восстановить всю иерархию можно каким путем?

Нет никаких лишних движений, вот код восстановления меню из memo:

procedure TForm1.btn1Click(Sender: TObject); var MI, PMI:TMenuItem; n:string; i:integer; begin for i:=0 to Memo1.Lines.Count-1 do Begin n:=Memo1.Lines.Strings[i]; if n[1]<>" " then PMI:=nil; MI:=TMenuItem.Create(Application); MI.Caption:=n; if PMI<>nil then PMI.Add(MI) else MainMenu1.Items.Add(MI); if n[1]<>" " then PMI:=MI; end; end;

У нас сделано так
Есть БД "Софт", где хранятся объекты "Приложение", "Пользователь", "Отчеты"
Объект "Приложение" включает в себя (БЛОБ) упакованный архив с рабочей папкой проги (исполняемые файлы, ресурсы, вспом.файлы и т.д. - т.е. все, что обычно инсталлируется.
Объект "Пользователь" - это параметры логина, права и список доступных приложений и отчетов, ну и там всякие прочие специфические вещи
Объект "Отчет" - это список хранимок с набором параметров, БЛОБы с эксельными шаблонами, картника с скриншотом..

Есть спецпрога "Проводник", которая устанавливается на ПК клиента
Этоа прога работает так:
После процедуры регистрации она тащит из БД все доступные проги и отчеты и строит интерфейсные панельки с кнопками - одна для программ, другая для отчетов. Причем и те и другие определяются из списка для этого пользователя
Когда юзер жмет на прогу, то из БД вытаскивается "инстал"-архив и разворачивается в локальной папке, откуда и запускается стартовый экзешник. Опции пользователя, также поднятые из БД, используются при открытии гл.формы
При нажатии отчетов также разворачивается весь экслельный набор шаблонов, макросов и хранимок - все это последовательно запускается

Плюс этой технологии в том, что при изменении версии программы (отчета), добавлении в систему новой или изменении прав пользователя никуда не надо ходить - все очудобно меняется в БД с компа "админа" - юзеру надо лишь перерегистрироваться - т.е. деплой как таковой просто отсутствует. Что весьма приятно, когда юзеров десятки и они разбросаны по предприятию

Это то, что нужно ?

Да, забыл добавить - при закрытии "тематического" приложения его локальные установки записываются в БД юзеру на место старых, а сама папка с прогой уничтожается. То же самое с отчетами за исключением собственно результатных эксель-файлов.
Т.е. на ПК клиентов сидят только работающие в данный момент приложения.
Это также избавило от проблем когда юзер нечаянно вытирает "лишние" файлы или теряет ярлыки на раб.столе
Кстати о ярлыках
Есть юзера, у которых имеется доступ к нескольким десяткам "базовых" прог - раньше у него все это валялось на столе. Сейчас "Проводник" из трея позволяет открыть меню, откуда можно запустить или поднять уже запущенное приложение. Пользователь теперь для запуска или активации нужной проги не опускает все запущенные окна чтобы добраться к рабочему столу, а просто клацает по иконке в трее.
В общем-то ничего особенного, но вполне в "духе" современности :)

да
> MsGuns ©
, следущий этап реализации проекта схож с вашим, т.б. хранение шаблонных форм отчетов в БД. Именно из-за удобства обновления выбран такой подход.
А сейчас обыгрывается вариант реализации прав доступа пользователей к БД на уровне содержимого меню. Вариант не лучший, но всё же. Если есть другие - готов выслушать. Поднимать тему на разграничение на уровне СУБД конечно хорошо (роли, права.....), но только интерфейс меню ими не решишь.

таблица.
деревянная.

id,
pfent_id,
caption,
item_id

все id c parent_id = null - это шаблоны меню конкретной роли.

заходит юзер "вася" у которого в шаблоне меню записано id=3

идем в деревянную таблицу, получаем все чайлды рутового васиного профиля (id = 3)

меню "васи" у нас в кармане.

Права пользователя и "гибкий" интерфейс для них - штука не такая простая как может показаться и очсильно зависит от собственно модели реализации этих самых прав.
Лучше всего, когда еще ДО создания всех проблемных вещей уже была продумана система прав
У нас, к примеру, все не так хорошо.
Поэтому мы пошли другим путем - каждое приложение уже подразумевает некоторый набор прав и мы лишь "подстраиваемся" под них. Другими словами, если у пользователя есть права на некоторый функционал, то прога включается в его список. Нет - до свидания.
Сложнее иное - вот есть в реальной БД сложные объекты с тучей характеристик. При этом некоторые из этих характеристик "ведутся" одним подроазделением или даже клерком, а некоторые - другими, третьими и т.д. А прога, писанная когда еще все вводилось в одном месте, открывает форму, где можно редактировать ессно ВСЕ поля объекта.
Вот и как прикажете поступать - "открывать" для редактирования одни поля пользователю, "закрывая" другие ? Т.е. надо не просто переписать прогу нафих, а еще придумать как раздавать права на ПОЛЯ таблицы.
Конечно, средствами сиквеля на сервере можно разрулить большинство этих "правовых" вопросов, но клиента все равно надо переписывать полностью. Если проект был реализован в трехзвенке, то в принципе это не проблема, но что делать с множеством "толстых" клиентских проектов ?

Блин, забыл написть главное
"средствами сиквеля на сервере можно БЫЛО БЫ разрулить"

Сама проблемная база, включая всю ее бизнес-логику, опять-таки была создана тогда еще
:)

Профили меню в БД MSSQL Найти похожие ветки