Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

TMenuItem.Click -> any.dll\procedure

Страницы: < 1 2 3 4 5 6 7 8 >
Dennis I. Komarov © (2009-05-22 10:38:00)
Вопрос - не вопрос но:

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

Вопрос такой: Какая (а точнее, кто придумает лучшую) логика должна быть, чтобы связать конечный пункт менюшки с соответствующей процедурой в библиотеке, при том чтобы выполнялось условие: в приложении описана только логика а конкретные данные вынесены из него, т.е. при добавлении нового пункта (в БД) не изменялось само приложение, а только библиотека (или добавлялась новая)

Slym (2009-05-25 11:46:00) [121]
Slym © (24.05.09 13:24) [23]
решается и кросплатформенность: напеши фрейворк, определи типы контролов, и типы евентов... аля 1С получица

clickmaker (2009-05-25 11:20:00) [122]
> Как экспортировать как виндовое окно, в лице TFrame?

Frame.Handle
насчет кроссплатформенности
CreateParented - VCL
CreateWindow - API

Dennis I. Komarov (2009-05-25 10:43:00) [123]
Так, ну вот и вернулся привычный инет...

Я так понимаю, придется виндовые окна экспортировать? :(

Ну у кого какие мысли еще есть?

Как экспортировать как виндовое окно, в лице TFrame?

Dennis I. Komarov_ (2009-05-24 21:07:00) [124]

> Сергей М. © (24.05.09 20:40) [28]
> > Dennis I. Komarov_ (24.05.09 19:30) [27]Ты мне загадки
> решил тут загадывать ?)Возьми дебагер да оттрассируй пошагово,
> чтобы понять источник AV ..

:) Да ну ее к лешему эту AV. Вот правой пяткой чую, что от того что я найду виновника - не ни тепло, ни холодно не будет...

> И зачем, кстати, в кач-ве владельца
> фрейма тебе потребовался именно компонент Application ?

А через него я до Parent-a хотел добраться...А что тут крименального? Вообщто, да. Не совсем правильно. Надо самоу следить за его ничтожением, а не сваливать это на чужой Application

Сергей М. (2009-05-24 20:40:00) [125]

> Dennis I. Komarov_ (24.05.09 19:30) [27]

Ты мне загадки решил тут загадывать ?)
Возьми дебагер да оттрассируй пошагово, чтобы понять источник AV ..

И зачем, кстати, в кач-ве владельца фрейма тебе потребовался именно компонент Application ?

Dennis I. Komarov_ (2009-05-24 19:30:00) [126]

> Сергей М. © (24.05.09 19:16) [25]

А вот и нет, прекрасно ловим AV и без строки

Parent:=Application.MainForm.ActiveChildForm;

Dennis I. Komarov_ (2009-05-24 19:22:00) [127]

> Сергей М. © (24.05.09 19:16) [25]
MainForm = nil

Ну, пусть... Да и не сильно болшая разница чего нехватает. Хотя почему-то Create(Application) не "прокатывает". Вероятно там только хендл и юзается. Ну да бог с ними...
Варианты реализации кто предложит?

Сергей М. (2009-05-24 19:16:00) [128]

> не понял на чем, т.е. чего не создано

MainForm = nil

Dennis I. Komarov_ (2009-05-24 18:58:00) [129]
DLL пишутся на чем угодно, вернее должна быть такая возможность, чтобы любой разработчик (не зависимо от языка) мог добавить свою библиотеку...

Ну да, СУБД скажем неопределенная. На данный момент через ADO к MS SQL, но это не факт, что так и останется. Должна быть универсальная реализация. Возможно, трехзвенка в данном случае - это лучшее решение.

Исходя из вышесказанного несовсем понятно как быть TFrame, т.е. мы привязываемся к "build with runtime packages", что противоречит "кроссплатформенности" DLL. Мои попытки такие:
TFunc = function(AHandle...): Boolean; ... var AnyF: TFun; ... [DLL] funtion AnyF(AHandle): Boolean; begin Application.Handle:=AHandle; with TAnyFrame.Create(Application) do begin Parent:=Application.MainForm.ActiveChildForm; end; end;
Получаю AV. Пока не понял на чем, т.е. чего не создано...

Slym (2009-05-24 13:24:00) [130]
clickmaker © (22.05.09 20:03) [22]
1. Ну в моем случае это был не коннект к БД, а ссылка на интерфейс сервера-приложений (IAppServer). Передавать готовый коннект или коннекшн стринг - зависит от используемой технологии и того, на чем предполагается писать DLL. АДО, например, для каждого потока должна юзать свой коннект. Т.е. если в DLL возможны отдельные потоки, надо это учитывать
+100

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

clickmaker (2009-05-22 20:03:00) [131]
> Тогда пара вопросов:

1. Ну в моем случае это был не коннект к БД, а ссылка на интерфейс сервера-приложений (IAppServer). Передавать готовый коннект или коннекшн стринг - зависит от используемой технологии и того, на чем предполагается писать DLL. АДО, например, для каждого потока должна юзать свой коннект. Т.е. если в DLL возможны отдельные потоки, надо это учитывать.
2. Функция из DLL возвращает TFrame. В приложении просто делаем Frame.Parent := SomeForm;

При этом и DLL и exe должны быть собраны с "build with runtime packages", иначе будет косяк с типами.

Dennis I. Komarov_ (2009-05-22 19:37:00) [132]

> Сергей М. © (22.05.09 13:34) [19]

Не кажется ли что из пушки по вообьм?

> clickmaker © (22.05.09 13:35) [20]
> приложение является некоей консолью
> и содержит только базовую функциональность, независимую
> от DLL.А также предоставляет пункты меню для вызова функций
> из DLL.Разумеется, имена функций, параметры и значения должны
> быть известны приложению.

Ну вот придется все загнать в жесткие рамки и передавать только определенные парметры, но на все случии жизни :)

> Я писал что-то подобное. MDI приложение,
> которое обеспечивает коннект к серверу, определение прав
> пользователя и загрузку DLL-оснасток соответственно этим
> правам. Готовый коннект и другая служебная инфа передается
> в DLL. А DLL экспортируют фрэймы, которые располагаются
> на mdi-чайлдах. Вся функциональность и UI - только в DLL.
> Примерно по такому принципу работает и виндозная MMC.

Тогда пара вопросов:
1. Как передать коннект к серверу БД библиотеке, или лучше пус каждая сама инициирует соединение?
2. Как передать родителя фрейму?

З.Ы. Вот так вот, был и-нет и вдруг его нету...

clickmaker (2009-05-22 13:35:00) [133]
> как сие обойти можно

приложение является некоей консолью и содержит только базовую функциональность, независимую от DLL.
А также предоставляет пункты меню для вызова функций из DLL.
Разумеется, имена функций, параметры и значения должны быть известны приложению.

Я писал что-то подобное. MDI приложение, которое обеспечивает коннект к серверу, определение прав пользователя и загрузку DLL-оснасток соответственно этим правам. Готовый коннект и другая служебная инфа передается в DLL. А DLL экспортируют фрэймы, которые располагаются на mdi-чайлдах. Вся функциональность и UI - только в DLL.
Примерно по такому принципу работает и виндозная MMC.

Сергей М. (2009-05-22 13:34:00) [134]

> как сие обойти можно

см. TComServer.TypeLib

Dennis I. Komarov (2009-05-22 13:21:00) [135]

> clickmaker © (22.05.09 13:13) [16]
> вот о чем я и говорю.

Не, это я спрашиваю, как сие обойти можно :)

Dennis I. Komarov (2009-05-22 13:16:00) [136]

> Сергей М. © (22.05.09 13:05) [14]

плохой пример :) предлагает зарегится на 30 дней аля триал

clickmaker (2009-05-22 13:13:00) [137]
> нет, не плагины. параметры не известны,

вот о чем я и говорю. "Как приложение узнает, какие данные туда передавать и откуда их брать?"

Dennis I. Komarov (2009-05-22 13:10:00) [138]

> если логика жестко зашита в приложении, и появилась новая
> DLL с новой функциональностью. Как приложение узнает, какие
> данные туда передавать и откуда их брать?
>
> Если же это плагинная архитектура и dll строго унифицированы,
> то какая проблема? Параметры заранее известны, имена экпортируемых
> функций тоже...

нет, не плагины. параметры не известны, имена передать можно. Как одно из решений, именно, стандартизация процедур, т.е. все процедуры имеют одинаковые входные параметры. Еще com/ole предлагают. Может еще кто чего придумает...

Сергей М. (2009-05-22 13:05:00) [139]
http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_23920412.html

clickmaker (2009-05-22 12:55:00) [140]
> в каком месте противоречие?

если логика жестко зашита в приложении, и появилась новая DLL с новой функциональностью. Как приложение узнает, какие данные туда передавать и откуда их брать?

Если же это плагинная архитектура и dll строго унифицированы, то какая проблема? Параметры заранее известны, имена экпортируемых функций тоже...

Страницы: < 1 2 3 4 5 6 7 8 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »