TMenuItem.Click -> any.dll procedure

← →
clickmaker © (2009-05-26 12:43) [80]

> [79] Dennis I. Komarov © (26.05.09 11:16)
> Да, я не пойму почему...

в методе CreateParams FParentWindow чему равно?

← →
Dennis I. Komarov © (2009-05-26 13:15) [81]

Из копания в генофонде нашел:
procedure TCustomFrame.CreateParams(var Params: TCreateParams); begin inherited; if Parent = nil then Params.WndParent := Application.Handle; end;

т.е.
после
Application.Handle:=AHandle;
ошибку победили, но фрэйм так и не появился :(

← →
Сергей М. © (2009-05-26 13:26) [82]

> после
> Application.Handle:=AHandle;

Ну ты и додумался)

Кто же хэндл формы использует в кач-ве хендла глоб.объекта Application ?

← →
Dennis I. Komarov © (2009-05-26 13:36) [83]

> Кто же хэндл формы использует в кач-ве хендла глоб.объекта
> Application ?

Да ни в коем разе...
хендел формы передавался параметром AParent, AHandle передает Application.Handle приложения :)

← →
Сергей М. © (2009-05-26 13:42) [84]

> AHandle передает Application.Handle приложения

Угу.

А что, по твоему, должно передать в кач-ве Application.Handle хост-приложение, разработанное в каком-нить УмбаЮмбаIDE ?)

← →
Dennis I. Komarov © (2009-05-26 13:48) [85]

Так вроде у нас библиотеки могут разрабатываются на таком класном IDE :)

← →
Сергей М. © (2009-05-26 13:51) [86]

Так у тебя библиотека-то твоя не на УмбаЮмба писана, а на Делфи)
А УмбаЮмба знать не знает ни про какие Делфи и уж тем более про объект Application и специфику использования его свойства Handle)

← →
Dennis I. Komarov © (2009-05-26 13:57) [87]

Возможно и не прав, но
App.Handle приложение должно вернуть хендл главного окна приложения (не MainForm)

← →
Сергей М. © (2009-05-26 13:59) [88]

> App.Handle приложение должно вернуть хендл главного окна
> приложения

Так точно.

И тут же вопрос: а что есть "главное окно" УмбаЮмба-приложения ?)

← →
Dennis I. Komarov © (2009-05-26 14:07) [89]

нету у нас УмбаЮмба-приложения . Могут быть только библиотеки, которые соответственно могут распоряжаться двумя параметрами: хендл Win-Application и хендл окна куда она должна поместить свое УмбаЮмба windiws-окно
???

ЗЫ
А "главное окно У-Ю приложения" все равно должно иметь некий идентификатор, если оно конечно как-то связано с Windows :)

← →
Dennis I. Komarov © (2009-05-26 14:13) [90]

И то, по идее, хендла окно (от MDIChild) Должно быть в принципе достаточно, т.к. через него можно найти хендл Win-Application, но это уже другая песня...

← →
Сергей М. © (2009-05-26 14:17) [91]

> нету у нас УмбаЮмба-приложения

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

> "главное окно У-Ю приложения" все равно должно иметь некий
> идентификатор

Ты не понял: УмбаЮмба-приложение может вообще не иметь "главного окна", в том смысле и с той спецификой, как оно трактуется и используется в дельфийском VCL-приложении

← →
clickmaker © (2009-05-26 14:18) [92]

кстати, вместо фрейма можно вполне и TForm юзать

она менее придирчива )

procedure TCustomForm.CreateParams(var Params: TCreateParams);

if (Parent = nil) and (ParentWindow = 0) then
begin
WndParent := Application.Handle;

← →
Сергей М. © (2009-05-26 14:19) [93]

> можно найти хендл Win-Application

Что такое "хендл Win-Application" ?
Дай четкое и внятное определение озвучененому тобой термину ..

← →
Сергей М. © (2009-05-26 14:20) [94]

> clickmaker © (26.05.09 14:18) [92]

Да можно даже и у кастомфрейма перекрыть "неуживчивые" методы, благо они виртуальные ..

← →
Dennis I. Komarov © (2009-05-26 14:44) [95]

> Сергей М. © (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 15:09) [96]

> Есть приложение, наше, родное, дельфовое

Что-то я не понял тогда, за какую "кросплатформенность" ты тогда выступал, если и хост-приложение делфовое и dll, которую ты сейчас мучаешь, тоже делфовое ..

> Это как так, если это приложение Windows?

А вот так : у УЮ-приложения может быть куча окон в куче разных потоках, какое из них "главное" ты заранее не знаешь и знать не можешь, да и объяснить вразумительно потенциальным УЮ-разработчикам, хендл какого окна ты ожидаешь в кач-ве "главного", ты тоже не в состоянии)

> приложение виндоуз обязательно должно иметь окно

Угу. Это если оно одно. Хошь не хошь - оно и есть "главное", ибо других просто нет.

А вот если это самое приложение создает туеву хучу окон, то какое из них, по-твоему, следует считать "главным" ?

← →
Dennis I. Komarov © (2009-05-26 15:19) [97]

> Что-то я не понял тогда, за какую "кросплатформенность"
> ты тогда выступал, если и хост-приложение делфовое и dll,
> которую ты сейчас мучаешь, тоже делфовое ..

блин, ну вроде написал ведь:

> ...одно из которых - предостовление интерфейса. Интерфейс должен
> браться из библиотеки, которая может быть написана (даже
> на УЮ)...

в том числе и на дельфи, что я сейчас и пытаюсь сделать

> А вот так : у УЮ-приложения может быть куча окон в куче
> разных потоках, какое из них "главное" ты заранее не знаешь
> и знать не можешь, да и объяснить вразумительно потенциальным
> УЮ-разработчикам, хендл какого окна ты ожидаешь в кач-ве
> "главного", ты тоже не в состоянии)
...
> Угу. Это если оно одно. Хошь не хошь - оно и есть "главное", ибо других просто нет.
>
> А вот если это самое приложение создает туеву хучу окон, то какое из них, по-твоему, следует считать "главным" ?

Да пусть... У нас нету УЮ-приложений. Зачем уходить специально от темы...

← →
Сергей М. © (2009-05-26 15:33) [98]

> 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:43) [99]

> Сергей М. © (26.05.09 15:33) [98]

Приложение должно работать с библиотеками разработанными не только на делфи. Есть приложение в котором много пунктиков меню. По какому-то мы кликнули - открылось MDI-Child форма. По тому что за итем менюшки был продгружаем определенную библиотеку и импортируем окошко из библиотеке на MDI-Child. То, что я сейчас пишу интерфейс для одного пункта на дельфе не означает, что на другом пункте "будет висеть" тоже дельфовая библиотека. Механизм вызова интерфейсов должен быть универсален для любых библиотек не зависимо от IDE.

← →
clickmaker © (2009-05-26 16:01) [100]

> Механизм вызова интерфейсов должен быть универсален для
> любых библиотек не зависимо от IDE.

тогда нужно передавать и хэндл "главного" окна приложения (который в случае VCL-DLL нужен для Application.Handle) и хэндл контейнера для окна из DLL.
В частном случае (н-р, dialog-based app) это будет одно и то же окно.
В общем - DLL сможет посылать команды главному окну приложения

← →
Сергей М. © (2009-05-26 16:01) [101]

> Dennis I. Komarov © (26.05.09 15:43) [99]

Ну хорошо.

Вернемся к нашим баранам)

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

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

Что теперь-то мешает "связать пункт менюшки" со всем этим хозяйством ?)

← →
Сергей М. © (2009-05-26 16:11) [102]

> clickmaker © (26.05.09 16:01) [100]

Не надо передавать App.Handle.
УЮ-плагинам он нафих не нужен.
А вот отказаться от TFrame в пользу любого другого TWinControl"a - хоть той же TForm - есть прямой резон: геморроя меньше.
Ну а про идеал решения - AX-контрол, про который даже захудалые УЮ-разработчики должны знать, - я уж и не заикаюсь)

← →
Dennis I. Komarov © (2009-05-26 16:16) [103]

> 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;

← →
clickmaker © (2009-05-26 16:21) [104]

а Frame.Visible := true не надо сделать?

← →
Dennis I. Komarov © (2009-05-26 16:22) [105]

> Не надо передавать App.Handle.
> УЮ-плагинам он нафих не нужен.

А мы их и не заставляем их юзать :)

> А вот отказаться от TFrame в пользу любого другого TWinControl"a
> - хоть той же TForm - есть прямой резон: геморроя меньше.

А вот тут поподробнее, в чем геморой?

> Ну а про идеал решения - AX-контрол, про который даже захудалые
> УЮ-разработчики должны знать, - я уж и не заикаюсь)

Сейчас вот это домучаю, а потом можно и про AX почитать будет :)

← →
Dennis I. Komarov © (2009-05-26 16:26) [106]

> clickmaker © (26.05.09 16:21) [104]
> а Frame.Visible := true не надо сделать?

Возможно. Если создавать в отдельном приложении то достаточно просто создать и указать Parent. Впрочем, результат тот же :(

← →
Сергей М. © (2009-05-26 16:33) [107]

> Фрэйм создался, но вот только я его не вижу на MDI-Child
> окне

Да как же ты его увидишь, если его родителем в соответствии с [81] и [83] стало главное окно VCL-приложения, у которого Witth = Height = 0 ?

)

← →
Dennis I. Komarov © (2009-05-26 16:39) [108]

with TFrameUsers.CreateParented(AParent) do begin
???

> вот тут поподробнее, в чем геморой?

В том что , по замыслу разработчиков, у фреймов в качестве Parent"а ожидается конкретный оконный VCL-контрол. И если Parent=nil, то , как ты в "генофонде", родительским окно назначается окно Application.Handle, которого в случае с VCL-библиотекой попросту нет. И взять неоткуда, если хост-приложение писали в УЮ)

procedure TFrameUsers.CreateParams(var Params: TCreateParams); //override
begin
inherited;
if ParentWindow <> 0 then
Params.WndParent := ParentWindow;
end;

Уговорили :) Поменял TFrame на TForm и ... о чудо, я вижу... :)
Всетаки странный он TFrame...

Спасибо!!!

Чтобы не терялась мысль задам тут еще вопрос:

При вышеперечисленных условиях каким образом Вы реализовали "тонкий клиент" к СУБД. из библиотеки?

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

> ... передача данных TDataSet с сервера...

...от сервера приложений библиотеке, которая...

> передача данных TDataSet с сервера, которая в свою очередь,
> понятия не имеет о существовании некой TDataSet

И что же библиотека будет делать с тем, о чем она понятия не имеет ?

← →
Dennis I. Komarov_ (2009-05-27 20:22) [116]

> И что же библиотека будет делать с тем, о чем она понятия
> не имеет ?

А я не говорил, что она получит TDataSet :)

Нужно придумать протокол обмена (скорее всего над TCP/IP) и передать информацию (из DataSet) клиенту. А как там с ней будут поступать, нас уже не интериует, как впрочем и функционал этой библиотеки. Вот интересуют мысли по этому поводу...

> Нужно придумать протокол обмена (скорее всего над TCP/IP)
> и передать информацию (из DataSet) клиенту

Все уже придумано до и за нас - http называется)
А браузер - тот самый "тонкий клиент")

← →
Dennis I. Komarov_ (2009-05-27 21:18) [118]

> Сергей М. © (27.05.09 20:57) [117]

не-е... клиент библиотека, а обрабатывать инфу через http... ну в принципе реально конечно, но думаю не самое то :)))))

> не-е... клиент библиотека

А какая разница, где будет размещен код клиента ?
Абсолютно никакой)

> над TCP/IP .. и передать информацию .. клиенту

Т.е. твое хост-приложение должно передавать данные рядом находящейся библиотеке с использованием интернет-протокола ?

Это ж надо до такого додуматься) ..

TMenuItem.Click -> any.dll procedure Найти похожие ветки