| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TMenuItem.Click -> any.dll\procedure
Dennis I. Komarov © (2009-05-22 10:38:00)Вопрос - не вопрос но:
Есть: некое приложение, интерфейс которого грузим из некой БД согласно правам пользователя, который запустил это приложение. В частности, возьмем ситуацию с TMainMenu. Согласно правам загрузилось дерево меню и подменюшек. Есть некая "ссылка" (int) на то, что должно выполнится при вызове соответствующего пункта. Процедура сего действия, а так же все интерфейсы и т.п. вынесены в библиотеку (dll).
Вопрос такой: Какая (а точнее, кто придумает лучшую) логика должна быть, чтобы связать конечный пункт менюшки с соответствующей процедурой в библиотеке, при том чтобы выполнялось условие: в приложении описана только логика а конкретные данные вынесены из него, т.е. при добавлении нового пункта (в БД) не изменялось само приложение, а только библиотека (или добавлялась новая)
Dennis I. Komarov (2009-05-27 09:08:00) [41]Уговорили :) Поменял TFrame на TForm и ... о чудо, я вижу... :)
Всетаки странный он TFrame...
Спасибо!!!
clickmaker (2009-05-26 16:44:00) [42]procedure TFrameUsers.CreateParams(var Params: TCreateParams); //override
begin
inherited;
if ParentWindow <> 0 then
Params.WndParent := ParentWindow;
end;
Сергей М. (2009-05-26 16:40:00) [43]
> Dennis I. Komarov © (26.05.09 16:39) [108]
Сказка про белого бычка ?)
Сергей М. (2009-05-26 16:39:00) [44]
> вот тут поподробнее, в чем геморой?
В том что , по замыслу разработчиков, у фреймов в качестве Parent'а ожидается конкретный оконный VCL-контрол. И если Parent=nil, то , как ты в "генофонде", родительским окно назначается окно Application.Handle, которого в случае с VCL-библиотекой попросту нет. И взять неоткуда, если хост-приложение писали в УЮ)
Dennis I. Komarov (2009-05-26 16:39:00) [45]
with TFrameUsers.CreateParented(AParent) do begin
???
Сергей М. (2009-05-26 16:33:00) [46]
> Фрэйм создался, но вот только я его не вижу на MDI-Child
> окне
Да как же ты его увидишь, если его родителем в соответствии с [81] и [83] стало главное окно VCL-приложения, у которого Witth = Height = 0?
)
Dennis I. Komarov (2009-05-26 16:26:00) [47]
> clickmaker © (26.05.09 16:21) [104]
> а Frame.Visible := true не надо сделать?
Возможно. Если создавать в отдельном приложении то достаточно просто создать и указать Parent. Впрочем, результат тот же :(
Dennis I. Komarov (2009-05-26 16:22:00) [48]
> Не надо передавать App.Handle.
> УЮ-плагинам он нафих не нужен.
А мы их и не заставляем их юзать :)
> А вот отказаться от TFrame в пользу любого другого TWinControl'a
> - хоть той же TForm - есть прямой резон: геморроя меньше.
А вот тут поподробнее, в чем геморой?
> Ну а про идеал решения - AX-контрол, про который даже захудалые
> УЮ-разработчики должны знать, - я уж и не заикаюсь)
Сейчас вот это домучаю, а потом можно и про AX почитать будет :)
clickmaker (2009-05-26 16:21:00) [49]а Frame.Visible := true не надо сделать?
Dennis I. Komarov (2009-05-26 16:16:00) [50]
> Dennis I. Komarov © (26.05.09 15:43) [99]
Так вроде оно сейчас так и есть :)
> Сергей М. © (26.05.09 16:01) [101]
>
> > Dennis I. Komarov © (26.05.09 15:43) [99]
> Ну хорошо.
> Вернемся к нашим баранам)
:) Ура....
> Так что там насчет "логика должна быть, чтобы связать конечный
> пункт менюшки с соответствующей процедурой в библиотеке"
> ?
>
> У тебя есть имя библиотеки, есть утвержденный тобой же прототип
> точки входа, известны типы и назначения параметров и результата.
>
>
> Что теперь-то мешает "связать пункт менюшки" со всем этим
> хозяйством ?)
Ну так вроде связал, Фрэйм создался, но вот только я его не вижу на MDI-Child окне
На всякий случай что есть:
[exe]
type
TBaseFunction = function(AHandle, AParent: HWND): HWND; stdcall;
...
procedure TFormMain.MenuItemClick(Sender: TObject);
var
LibHandle: THandle;
ShowUserI: TBaseFunction;
X: TFormMDIBaseCh; {Это MDI-Child форма}
begin
x:=TFormMDIBaseCh.Create(FormMain); begin
x.Caption := TMenuItem(Sender).Caption;
LibHandle:=LoadLibrary('users.dll');
try
if LibHandle <> 0 then begin
X.Tag:=LibHandle;
@ShowUserI:=GetProcAddress(LibHandle, 'CreateIUsers');
if Addr(ShowUserI) <> nil then begin
x.Caption:= IntToStr(ShowUserI(Application.Handle, x.Handle));
end;
end;
finally
//FreeLibrary(LibHandle);
end;
end;
end;
[dll]
function CreateIUsers(AHandle, AParent: HWND): HWND; stdcall;
implementation
{$R *.dfm}
function CreateIUsers;
begin
Result:=0;
Application.Handle:=AHandle;
if AParent <> 0 then
with TFrameUsers.CreateParented(AParent) do begin
Result:=Handle;
end;
end;
Сергей М. (2009-05-26 16:11:00) [51]
> clickmaker © (26.05.09 16:01) [100]
Не надо передавать App.Handle.
УЮ-плагинам он нафих не нужен.
А вот отказаться от TFrame в пользу любого другого TWinControl'a - хоть той же TForm - есть прямой резон: геморроя меньше.
Ну а про идеал решения - AX-контрол, про который даже захудалые УЮ-разработчики должны знать, - я уж и не заикаюсь)
Сергей М. (2009-05-26 16:01:00) [52]
> Dennis I. Komarov © (26.05.09 15:43) [99]
Ну хорошо.
Вернемся к нашим баранам)
Так что там насчет "логика должна быть, чтобы связать конечный пункт менюшки с соответствующей процедурой в библиотеке" ?
У тебя есть имя библиотеки, есть утвержденный тобой же прототип точки входа, известны типы и назначения параметров и результата.
Что теперь-то мешает "связать пункт менюшки" со всем этим хозяйством ?)
clickmaker (2009-05-26 16:01:00) [53]> Механизм вызова интерфейсов должен быть универсален для
> любых библиотек не зависимо от IDE.
тогда нужно передавать и хэндл "главного" окна приложения (который в случае VCL-DLL нужен для Application.Handle) и хэндл контейнера для окна из DLL.
В частном случае (н-р, dialog-based app) это будет одно и то же окно.
В общем - DLL сможет посылать команды главному окну приложения
Dennis I. Komarov (2009-05-26 15:43:00) [54]
> Сергей М. © (26.05.09 15:33) [98]
Приложение должно работать с библиотеками разработанными не только на делфи. Есть приложение в котором много пунктиков меню. По какому-то мы кликнули - открылось MDI-Child форма. По тому что за итем менюшки был продгружаем определенную библиотеку и импортируем окошко из библиотеке на MDI-Child. То, что я сейчас пишу интерфейс для одного пункта на дельфе не означает, что на другом пункте "будет висеть" тоже дельфовая библиотека. Механизм вызова интерфейсов должен быть универсален для любых библиотек не зависимо от IDE.
Сергей М. (2009-05-26 15:33:00) [55]
> Dennis I. Komarov © (26.05.09 15:19) [97]
Вот ты сказал:
> мы привязываемся к "build with runtime packages", что противоречит
> "кроссплатформенности" DLL
Ну а о какой такой "кроссплатформенности", с которой ты якобы не хочешь иметь "противоречий", может тогда вообще идти речь, если нет ни намека на УЮ, т.е. если всевзаимодействующие модули "у вас" разрабатываются в среде Днелфи и заведомо используют VCL ? И если так, то к чему все эти пляски с бубном, если всего-то достаточно разместить фрейм в модуле пакета времени выполнения (bpl) и обеспечить BwRTP=True во всех взаимодействующих модулях ?
)
Dennis I. Komarov (2009-05-26 15:19:00) [56]
> Что-то я не понял тогда, за какую "кросплатформенность"
> ты тогда выступал, если и хост-приложение делфовое и dll,
> которую ты сейчас мучаешь, тоже делфовое ..
блин, ну вроде написал ведь:
> ...одно из которых - предостовление интерфейса. Интерфейс должен
> браться из библиотеки, которая может быть написана (даже
> на УЮ)...
в том числе и на дельфи, что я сейчас и пытаюсь сделать
> А вот так : у УЮ-приложения может быть куча окон в куче
> разных потоках, какое из них "главное" ты заранее не знаешь
> и знать не можешь, да и объяснить вразумительно потенциальным
> УЮ-разработчикам, хендл какого окна ты ожидаешь в кач-ве
> "главного", ты тоже не в состоянии)
...
> Угу. Это если оно одно. Хошь не хошь - оно и есть "главное", ибо других просто нет.
>
> А вот если это самое приложение создает туеву хучу окон, то какое из них, по-твоему, следует считать "главным" ?
Да пусть... У нас нету УЮ-приложений. Зачем уходить специально от темы...
Сергей М. (2009-05-26 15:09:00) [57]
> Есть приложение, наше, родное, дельфовое
Что-то я не понял тогда, за какую "кросплатформенность" ты тогда выступал, если и хост-приложение делфовое и dll, которую ты сейчас мучаешь, тоже делфовое ..
> Это как так, если это приложение Windows?
А вот так : у УЮ-приложения может быть куча окон в куче разных потоках, какое из них "главное" ты заранее не знаешь и знать не можешь, да и объяснить вразумительно потенциальным УЮ-разработчикам, хендл какого окна ты ожидаешь в кач-ве "главного", ты тоже не в состоянии)
> приложение виндоуз обязательно должно иметь окно
Угу. Это если оно одно. Хошь не хошь - оно и есть "главное", ибо других просто нет.
А вот если это самое приложение создает туеву хучу окон, то какое из них, по-твоему, следует считать "главным" ?
Dennis I. Komarov (2009-05-26 14:44:00) [58]
> Сергей М. © (26.05.09 14:17) [91]
Брррр... Все не так
Есть приложение, наше, родное, дельфовое... Оно есть и пишем его только мы... Оно грузит некое TMainMenu согласно правам того кто в него зашел. Каждый итем меню должен быть ассоциирован с неким дейсвием, одно из которых - предостовление интерфейса. Интерфейс должен браться из библиотеки, которая может быть написана (даже на УЮ)...
> Ты не понял: УмбаЮмба-приложение может вообще не иметь "главного
> окна", в том смысле и с той спецификой, как оно трактуется
> и используется в дельфийском VCL-приложении
Это как так, если это приложение Windows?
Да и нету у нас приложений а если и будут, то без нас :)
> clickmaker © (26.05.09 14:18) [92]
Конечно можно, ибо с точки зрения Windows окно, как окно :) Но удобно ли его будет вписать в MDIChild?
> Сергей М. © (26.05.09 14:19) [93]
>
> > можно найти хендл Win-Application
>
>
> Что такое "хендл Win-Application" ?
> Дай четкое и внятное определение озвучененому тобой термину
> ..
Ну вот тут сложнее, но ИМХО приложение виндоуз обязательно должно иметь окно (которое не форма) Через это окно происходит общение системы с приложением. Возможно сумбурно, но как-то так :)
Сергей М. (2009-05-26 14:20:00) [59]
> clickmaker © (26.05.09 14:18) [92]
Да можно даже и у кастомфрейма перекрыть "неуживчивые" методы, благо они виртуальные ..
Сергей М. (2009-05-26 14:19:00) [60]
> можно найти хендл Win-Application
Что такое "хендл Win-Application" ?
Дай четкое и внятное определение озвучененому тобой термину ..
| |
Страницы: 