TMenuItem.Click -> any.dll procedure

← →
Dennis I. Komarov © (2009-05-22 10:38) [0]

Вопрос - не вопрос но:

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

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

← →
Сергей М. © (2009-05-22 10:48) [1]

Не оч понятно ..

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

так ?

← →
Palladin © (2009-05-22 10:51) [2]

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

TMenuItem.Tag
можно хранить там адрес, полученный GetProcAddress

← →
Сергей М. © (2009-05-22 10:52) [3]

И опять напрашивается уже изрядно поднадоевший контрвопрос - почему dll, а не bpl ? Чем в дан.случае оправдан выбор ?

← →
Dennis I. Komarov © (2009-05-22 11:22) [4]

> Сергей М. © (22.05.09 10:48) [1]

Не совсем. Сделать в рантайм пункт, выполнить по нему процедуру из вне это не проблема. Вопрос в самой логике которая прописана в exe, и которая не зависит от конечных пунктров и прицедур. Она одна и не меняется от изменения интерфейса...

> Palladin © (22.05.09 10:51) [2]

да не суть где хранить, в tag, или брать из вне.
GetProcAddress сохранили. Далее как вызвать процедуру, не зная что это за процедура? Не должно о ней ничего знать приложение...

> Сергей М. © (22.05.09 10:52) [3]

Чтобы абстрагироваться от борланд. Ну не будем об этом. Я знаю что есть bpl и с ним все намного проще...

← →
Palladin © (2009-05-22 11:25) [5]

> Далее как вызвать процедуру, не зная что это за процедура?
>

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

← →
Dennis I. Komarov © (2009-05-22 11:34) [6]

Ну, собственно это вот и надо выдумать :)
Ну к примеру некий базовый тип одинаковый для всех вызываемых таким образом процедур. Или передавать только указатель памяти, а там уже извращаться и читать какие-то входящие параметры

← →
Сергей М. © (2009-05-22 11:42) [7]

> Чтобы абстрагироваться от борланд

Чтобы исключить зависимость от особенностей и требований конкретных сред разработки и исполнения и обеспечить универсальность интерпроцессного/интермодульного взаимодействия, мелкомягкими придуман COM/OLE-механизм.
Предлагаю обратить на него свой взор)

> как вызвать процедуру, не зная что это за процедура?

См. выше.

← →
Dennis I. Komarov © (2009-05-22 12:06) [8]

> Чтобы исключить зависимость от особенностей и требований
> конкретных сред разработки и исполнения и обеспечить универсальность
> интерпроцессного/интермодульного взаимодействия, мелкомягкими
> придуман COM/OLE-механизм.
> Предлагаю обратить на него свой взор)

Ну что-то я не сильно тут COM/OLE представляю :) Тупо возьмем пункт "пользователи" и все что в нем цепляем к ???users.dll в которой формочки типа добавить, удалить, права, группы и прочая ерунда касаемая юзверей.

> См. выше.

нету bpl, так сегодня в гороскопе написано :)

З.Ы. Пишем "некое универсальное ядро" с администрировалкой

← →
clickmaker © (2009-05-22 12:16) [9]

> Далее как вызвать процедуру, не зная что это за процедура?
> Не должно о ней ничего знать приложение

а это не противоречит тому, что "в приложении описана только логика"?

← →
Сергей М. © (2009-05-22 12:20) [10]

> > См. выше.
>
> нету bpl,

Выше - это я про COM/OLE

> что-то я не сильно тут COM/OLE представляю

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

← →
Dennis I. Komarov © (2009-05-22 12:24) [11]

> а это не противоречит тому, что "в приложении описана только
> логика"?

Ну а собственно, в каком месте противоречие?

← →
Dennis I. Komarov © (2009-05-22 12:35) [12]

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

Пугает меня такая реализация... Примеры можно?

← →
clickmaker © (2009-05-22 12:55) [13]

> в каком месте противоречие?

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

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

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

http://www.experts-exchange.com/Programming/Languages/Pascal/Delphi/Q_23920412.html

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

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

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

← →
clickmaker © (2009-05-22 13:13) [16]

> нет, не плагины. параметры не известны,

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

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

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

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

← →
Dennis I. Komarov © (2009-05-22 13:21) [18]

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

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

← →
Сергей М. © (2009-05-22 13:34) [19]

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

см. TComServer.TypeLib

← →
clickmaker © (2009-05-22 13:35) [20]

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

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

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

← →
Dennis I. Komarov_ (2009-05-22 19:37) [21]

> Сергей М. © (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 20:03) [22]

> Тогда пара вопросов:

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

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

← →
Slym © (2009-05-24 13:24) [23]

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

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

← →
Dennis I. Komarov_ (2009-05-24 18:58) [24]

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. Пока не понял на чем, т.е. чего не создано...

← →
Сергей М. © (2009-05-24 19:16) [25]

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

MainForm = nil

← →
Dennis I. Komarov_ (2009-05-24 19:22) [26]

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

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

← →
Dennis I. Komarov_ (2009-05-24 19:30) [27]

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

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

Parent:=Application.MainForm.ActiveChildForm;

← →
Сергей М. © (2009-05-24 20:40) [28]

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

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

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

← →
Dennis I. Komarov_ (2009-05-24 21:07) [29]

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

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

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

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

← →
Dennis I. Komarov © (2009-05-25 10:43) [30]

Так, ну вот и вернулся привычный инет...

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

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

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

← →
clickmaker © (2009-05-25 11:20) [31]

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

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

← →
Slym © (2009-05-25 11:46) [32]

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

← →
Dennis I. Komarov © (2009-05-25 11:54) [33]

> clickmaker © (25.05.09 11:20) [31]

Ну и я про то, что о VCL придется забыть...

Мануал - пример можно?

Ну создали мы некий TAnyFrame - он как окно должен быть со своим хендлом.
передали хендл приложению, дальше что?

← →
Dennis I. Komarov © (2009-05-25 11:56) [34]

> решается и кросплатформенность: напеши фрейворк, определи
> типы контролов, и типы евентов... аля 1С получица

ну сейчас еще с окнами повожуся и приступлю к написанию "2С" :)

← →
clickmaker © (2009-05-25 11:57) [35]

> передали хендл приложению, дальше что?

а тут всего 2 варианта. Либо в DLL передаем хэндл родителя и там либо CreateWindow либо CreateParented, либо возвращаем хэндл из DLL и делаем SetParent

← →
Dennis I. Komarov © (2009-05-25 12:34) [36]

> в DLL передаем хэндл родителя и там либо CreateWindow либо
> CreateParented

не совсем понял, у нас же в длл есть созданный TFrame, по сути тот же Window

> либо возвращаем хэндл из DLL и делаем SetParent

т.е.
[DLL]
TAnyFrame.Create(nil);
Result:=TAnyFrame.Handle;

[EXE]
if SetParent(HandleFromDll, ActiveChildForm) = nil then ...

← →
clickmaker © (2009-05-25 12:42) [37]

> не совсем понял, у нас же в длл есть созданный TFrame, по
> сути тот же Window

ну, наверно все-таки правильней так
[DLL]
function CreateFrame(AParent: HWND): TFrame;
begin
Frame := TAnyFrame.CreateParented(AParent);
Result := Frame.Handle;
end;

← →
clickmaker © (2009-05-25 12:50) [38]

т.е. function CreateFrame(AParent: HWND): HWND, конечно же

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

← →
Dennis I. Komarov © (2009-05-25 13:39) [39]

Все хорошо, но где-то не хорошо :(

[DLL]
... type TFrameUsers = class(TFrame) ListViewUsers: TListView; Splitter1: TSplitter; PageControl1: TPageControl; StatusBar1: TStatusBar; TabSheet1: TTabSheet; TabSheet2: TTabSheet; ToolBar1: TToolBar; ImageList1: TImageList; ToolButton1: TToolButton; private { Private declarations } public { Public declarations } end; function CreateIUsers(AParent: HWND): HWND; stdcall; implementation {$R *.dfm} function CreateIUsers; begin with TFrameUsers.CreateParented(AParent) do begin Result:=Handle; end; end;

Ловим "control "Frame" has no parent window
Хэндл в функцию передается
...

← →
clickmaker © (2009-05-25 13:44) [40]

> Ловим "control "Frame" has no parent window

в какой момент?

← →
Сергей М. © (2009-05-25 14:11) [41]

> Хэндл в функцию передается

Значит не передается, если тебе черным по белому пишут, что "control .. has no parent window"

Подозреваю, что сейчас начнется свистопляска с соглашением о вызове)

← →
Dennis I. Komarov © (2009-05-25 14:11) [42]

здесь:
with TFrameUsers.CreateParented(AParent) do begin

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

> Подозреваю, что сейчас начнется свистопляска с соглашением
> о вызове)

ctdcall виновытый?

← →
Сергей М. © (2009-05-25 14:14) [44]

Виноватый тот кто его втыкает там где он совершенно не нужен и, напротив, не втыкает там где он действительно необходим)

← →
clickmaker © (2009-05-25 14:17) [45]

> ctdcall виновытый?

если уж он есть, то и описание фунции в exe тоже должно быть с ним

> здесь:
> with TFrameUsers.CreateParented

прямо-таки здесь? а если отладчиком попробовать зайти в CreateParented?

← →
Dennis I. Komarov © (2009-05-25 14:47) [46]

> Виноватый тот кто его втыкает там где он совершенно не нужен
> и, напротив, не втыкает там где он действительно необходим)

Ну если учесть что пишем ядро для "кроссплатформенных интерфейсов", то так уж он и не нужен? Для эксперемента снял его (и там и там) результат не поменялся :(

> если уж он есть, то и описание фунции в exe тоже должно
> быть с ним

Разумеется и там и там есть:

type
TBaseFunction = function(AParent: HWND): HWND; stdcall;

> прямо-таки здесь? а если отладчиком попробовать зайти в
> CreateParented?

пробывал, он сразу (по F7) и отпревляет на ... Внутрь CreateParented не заходит :(

← →
Сергей М. © (2009-05-25 14:52) [47]

> и там и там есть:
>

А вот в [24] что-то не видать соглашения ..

← →
clickmaker © (2009-05-25 15:01) [48]

> Внутрь CreateParented не заходит

[x] Use debug DCUs в настройках проекта + rebuild all

← →
Dennis I. Komarov © (2009-05-25 15:59) [49]

> А вот в [24] что-то не видать соглашения ..

[24] писал с чужого компа, просто не дописал...

← →
Сергей М. © (2009-05-25 16:02) [50]

Тогда приводи код вызова этой ф-ции - что и как передаешь параметром ..

← →
Dennis I. Komarov © (2009-05-25 16:07) [51]

Classes.pas
...
function InitInheritedComponent(Instance: TComponent; RootAncestor: TClass): Boolean;

function InitComponent(ClassType: TClass): Boolean;
...
Result := InternalReadComponentRes(ClassType.ClassName, FindResourceHInstance(
FindClassHInstance(ClassType)), Instance) or Result;

Вот в этой умерает где-то внутри, в асме запутался кто чего откуда

← →
Dennis I. Komarov © (2009-05-25 16:11) [52]

> Сергей М. © (25.05.09 16:02) [50]

procedure TFormMain.MenuItemClick(Sender: TObject);
var
LibHandle: THandle;
ShowUserI: TBaseFunction;
X: TFormMDIBaseCh;
begin
x:=TFormMDIBaseCh.Create(Application); begin
x.Caption := TMenuItem(Sender).Caption;
LibHandle:=LoadLibrary("users.dll");
try
if LibHandle <> 0 then begin
@ShowUserI:=GetProcAddress(LibHandle, "CreateIUsers");
if Addr(ShowUserI) <> nil then begin
x.Caption:= IntToStr(ShowUserI(x.Handle));
// или просто ShowUserI(x.Handle);
end;
end;
finally
FreeLibrary(LibHandle);
end;

end;
end;

← →
Сергей М. © (2009-05-25 16:15) [53]

Это ты что же, хочешь сделать parent"ом окно MDIParent-формы ?)

← →
Dennis I. Komarov © (2009-05-25 16:20) [54]

> окно MDIParent-формы

окно MDIChild-формы, а что - не окно? :(

← →
Сергей М. © (2009-05-25 16:31) [55]

> окно MDIChild-формы, а что - не окно?

Нет, против окна MDIChild-формы я ничего не имею)
Впрочем, и тут возникает тот же вопрос - а зачем владельцем MDIChild-формы выбран объект Application ?

← →
Dennis I. Komarov © (2009-05-25 16:43) [56]

> а зачем владельцем MDIChild-формы выбран объект Application

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

← →
clickmaker © (2009-05-25 16:48) [57]

а ничего, что сразу после ShowUserI(x.Handle); делается FreeLibrary(LibHandle); ?

← →
Сергей М. © (2009-05-25 16:51) [58]

> откуда возникают такие вопросы?

Да все оттуда же)

То у тебя "прокатывает", то "не прокатывает" - метод научного тыка осваиваешь ?)

Взял бы да оформил свой фрейм как ActiveX-контрол - вот тебе и готовый "кроссплатформенный интерфейс"... Я ж тебе не зря про COM/OLE намекал, а ты все про воробьев да про пушки) ..

← →
Сергей М. © (2009-05-25 16:53) [59]

> clickmaker © (25.05.09 16:48) [57]

К 57-му посту маразм только крепчает)

← →
Dennis I. Komarov © (2009-05-25 17:07) [60]

> а ничего, что сразу после ShowUserI(x.Handle); делается
> FreeLibrary(LibHandle); ?

Ну дас, косяк :) но на ошибку сие не влияет, т.к. она происходит до этого.

> Да все оттуда же)
>
> То у тебя "прокатывает", то "не прокатывает" - метод научного
> тыка осваиваешь ?)
>
> Взял бы да оформил свой фрейм как ActiveX-контрол - вот
> тебе и готовый "кроссплатформенный интерфейс"... Я ж тебе
> не зря про COM/OLE намекал, а ты все про воробьев да про
> пушки) ..

Ну опять 25... Ну не создавал я ActiveX ни разу. Ну темный лес... Регистрация всякая, COM/OLE ...

← →
Сергей М. © (2009-05-25 17:24) [61]

> не создавал я ActiveX ни разу. Ну темный лес

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

← →
Dennis I. Komarov © (2009-05-25 17:40) [62]

> Так ведь в самую пору выходить из лесу, коль скоро "кроссплатформенностью"
> озаботился ..

Выйду, выйду... :) Где Parent-окно потерялось?

← →
Slym © (2009-05-26 06:15) [63]

Сергей М. © (25.05.09 17:24) [61]
проще свой простенький фреймворк напесадь

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

> Dennis I. Komarov © (25.05.09 17:40) [62]

> Где Parent-окно потерялось?

А вот где:

procedure TWinControl.CreateWnd; var Params: TCreateParams; TempClass: TWndClass; ClassRegistered: Boolean; begin CreateParams(Params); with Params do begin if (WndParent = 0) and (Style and WS_CHILD <> 0) then if (Owner <> nil) and (csReading in Owner.ComponentState) and (Owner is TWinControl) then WndParent := TWinControl(Owner).Handle else raise EInvalidOperation.CreateFmt(SParentRequired, [Name]); // <--здесь ..

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

if (WndParent = 0) and (Style and WS_CHILD <> 0) then

WndParent у тебя равен нулю.

А говоришь "передается")

← →
Dennis I. Komarov © (2009-05-26 09:55) [66]

Так, ну кто-нить объяснит почему нету Parent-окна?

> Это ты что же, хочешь сделать parent"ом окно MDIParent-формы ?)

> Нет, против окна MDIChild-формы я ничего не имею)

И где в коде намек на MDIParent?

← →
Сергей М. © (2009-05-26 09:58) [67]

> где в коде намек на MDIParent?

А мне почем знать, что в идентификаторе TFormMDIBaseCh постфикс у тебя означает сокращение именно от "Child", а не что-то иное ?)

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

> кто-нить объяснит почему нету Parent-окна?

Потому что ты не передаешь его (факт.параметром в конструктор передается нуль), что еще не понятно ?)

← →
Dennis I. Komarov © (2009-05-26 10:04) [69]

> if (WndParent = 0) and (Style and WS_CHILD <> 0) then
>
> WndParent у тебя равен нулю.
>
> А говоришь "передается")

но x.Handle <> 0 :(

← →
Сергей М. © (2009-05-26 10:09) [70]

Это ты где смотришь ?
Значение фактически переданного хэндла нужно смотреть уже в теле конструктора, а не в коде, вызывающем конструктор ..

← →
Dennis I. Komarov © (2009-05-26 10:09) [71]

function CreateIUsers; begin ShowMessage(InttoStr(AParent)); if AParent <> 0 then with TFrameUsers.CreateParented(AParent) do begin Result:=Handle; end; end;

AParent <> 0

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

> AParent <> 0

А вот фрагмент "генофонда" говорит об ином..
Ты вникни в него, я же не зря привел его ..

← →
KSergey © (2009-05-26 10:29) [73]

мне вот интересно
Идет обсуждение тех. реализации...
а может посмотреть на готовое? ну вот в винамп очень даже гибко встраивается
или есть еще микрософтовский API для mmc.

Может поизучать как и что люди делают?

← →
Dennis I. Komarov © (2009-05-26 10:31) [74]

procedure TWinControl.CreateWnd; var Params: TCreateParams; TempClass: TWndClass; ClassRegistered: Boolean; begin CreateParams(Params); with Params do begin if (WndParent = 0) and (Style and WS_CHILD <> 0) then if (Owner <> nil) and (csReading in Owner.ComponentState) and (Owner is TWinControl) then WndParent := TWinControl(Owner).Handle else raise EInvalidOperation.CreateFmt(SParentRequired, [Name]); FDefWndProc := WindowClass.lpfnWndProc;

Отладчик молчит по поводу значения WndParent, но после 1-го if идем на выделенную строку, значит WndParent <> 0 (ну или Style and WS_CHILD = 0) :) Так что не тут ошибочка ...

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

> Dennis I. Komarov © (26.05.09 10:31) [74]

нет, обманул, не то окно пробежал, действительно попадаем внутрь :(

← →
Сергей М. © (2009-05-26 10:45) [76]

> Отладчик молчит по поводу значения WndParent

Так ты спроси у него конкретно - чему, мол, равно Params.WndParent)

Он же "бестолковый" - не понимает что ид-р WndParent имеет отношение к структуре Params)

← →
Dennis I. Komarov © (2009-05-26 10:58) [77]

да спросил конечно, чего его спрашивать то если и так видно :)
Тока вот почему... *SCRATCH*

TForm.Handle не есть хендл окна?

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

> TForm.Handle не есть хендл окна?

Есть.
Ну так ты убедился что Params.WndParent = 0 ?

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

Да, я не пойму почему...

← →
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. Впрочем, результат тот же :(

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

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

)

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 .. и передать информацию .. клиенту

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

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

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

Да нет конечно :) И как такое в голову лезет :) Наверное утро :)...

СУБД - Сервер приложений (это не которое загружает библиотеки) - GUI (интерфейс загруженный из библиотеки)

> СУБД - Сервер приложений (это не которое загружает библиотеки)
> - GUI (интерфейс загруженный из библиотеки)
>

Что-то я не вижу никакой связи между "кислым", "теплым" и "зеленым")

Если твое хост-приложение знать ничего не знает и знать не желает о происходящем внутри библиотеки, то какая ему разница, как эта самая библиотека получит данные с какого-то там сервера, дабы, например, изобразить эти данные в своем же собственном GUI ?

> СУБД - Сервер приложений (это не которое загружает библиотеки)
> - GUI (интерфейс загруженный из библиотеки)

Сервер приложений - н-р, MIDAS или другая DCOM-подобная технология, которая предоставляет методы для вызова.
Клиент - импортирует библиотеку типов сервера и получает данные в виде TClientDataset в случае MIDAS или просто путем вызова методов сервера. Данные передавать и получать можно с помощью любых OLE-совместимых типов: variant, widestring etc

:) Ну неуж-то правда не понятно, или специально? :)))

Но библиотека то должна знать что за индивид загрузил ее...
Тут два варианта:
1. передаем данные аунтификации (а так же всю информацию о СУБД) библиотеке и получаем двузвенную архитектуру.
2. Строим промежуточное звено "Сервер приложений" (МА)

> clickmaker © (28.05.09 10:05) [123]

Как раз ее сейчас штудирую. Интересны реальные подводные камни, надежность и пр. кто уже использовал технологию, поэтому вопрос был:
"каким образом Вы......" Ну еще добавить почему? Чем хорошо\плохо и т.д.

C моей точки зрения MIDAS плоха тем, что клиента привязываем к TClientDataSet

> библиотека то должна знать что за индивид загрузил ее

Зачем ?

Что полезного УЮ-библиотека поимеет, если будет знать, что она загружена в АП процесса какого-то там заморского VCL-приложения MySuperPuperProga.exe ?)

ТЗ на ходу меняешь-изобретаешь ?)

> MIDAS плоха тем, что клиента привязываем к TClientDataSet

Задействование MIDAS не требует обязательного использования CDS.

> Зачем ?
>
> Что полезного УЮ-библиотека поимеет, если будет знать, что
> она загружена в АП процесса какого-то там заморского VCL-
> приложения MySuperPuperProga.exe ?)
>
> ТЗ на ходу меняешь-изобретаешь ?)

И ни капельки я не меняю ТЗ. Индивид - не бла-бла-бла.exe а физическое лицо которое запустило этот ...exe :) со своими правами, а УЮ библиотека что бы подключиться к СУБД должна на ней пройти авторизацию, а авторизироваться из каджого интефейса - это по меньшей мере не удобно для юзверя :) Да и еще не известно умеет ли УЮ вообще работать с этим СУБД

> Задействование MIDAS не требует обязательного использования
> CDS.

Про MIDAS я сейчас читаю, посмотрим...

> не известно умеет ли УЮ вообще работать с этим СУБД
>

А тогда нашиша грузить такую УЮ-библиотеку, которая не понимает чего от нее хотят ?)

А вот есть интерфейс который успешно работал с MSSQL, ORACLE .... а тут надо внедрить его в систему, которая на битрив работает, а вот УЮ ну не знает что это и как его есть...

Уходим от темы опять???

Обсуждаем трехзвенку, в частности как передать инфу с TDataSet удаленному интерфейсу (не в "формате TDataSet")
MIDAS - первое что пришло - ковыряю его. Какие еще варианты, и отзывы о них...

> со своими правами, а УЮ библиотека что бы подключиться к
> СУБД должна на ней пройти авторизацию

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

> УЮ ну не знает что это и как его есть

Так он еще много чего может не знать, не только это)

О MIDAS речь тем более идти не может - это технология и среда, специфичная для сред разработки от Борланд, а УЮ-среда про Борланд ничего не знает.

Зато наверняка знает про OLE, COM, ActiveX, CORBA)

> clickmaker © (28.05.09 11:46) [132]
>
> авторизацию может проводить хост-экзе, а в библиотеку передавать
> уже готовый интерфейс сервера приложений.

Так оно и задумано. Задача обмена инфы [131]

> Сергей М. © (28.05.09 11:56) [133]
> О MIDAS речь тем более идти не может - это технология и
> среда, специфичная для сред разработки от Борланд, а УЮ-
> среда про Борланд ничего не знает.
>
> Зато наверняка знает про OLE, COM, ActiveX, CORBA)

MIDAS не COM?
Тогда вычеркнул из списка :)

> Зато наверняка знает про OLE, COM, ActiveX, CORBA)

Можно подробнее, примеры, хорошо\плохо, чем опасно... и т.д.

У меня пока такая мысль:
TDataSet -> некий текстовой формат (к примеру cds, xml) -> упаковали -> передали по TCP/IP -> получили -> распакавали -> преобразовываем в TDataSet (или чего другое, в зависимости от IDE)

> MIDAS не COM?

MIDAS основана на COM, но это специфичная надстройка.

> TDataSet -> некий текстовой формат (к примеру cds, xml)
> -> упаковали -> передали по TCP/IP -> получили -> распакавали
> -> преобразовываем в TDataSet

MIDAS именно так и работает.
Данные передаются в своем формате, упакованном в OleVariant. Причем, передаваться могут не все данные, а только изменившаяся на клиенте часть.

> Данные передаются в своем формате, упакованном в OleVariant.
> Причем, передаваться могут не все данные, а только изменившаяся
> на клиенте часть.

формат открытый? Сможет ли приложение написанное скажем на MSVC++ работать с ним? midas.dll для этого будет достаточно?

> формат открытый?

Где же он открытый, если за использование midas-модуля денюжку требуют ?)

> Где же он открытый, если за использование midas-модуля денюжку
> требуют ?)

у-у-у....
так это совсем плохо. :)

> это совсем плохо

Жаба душит ?)

> Жаба душит ?)

Я даже не знаю какую денюжку они требуют, так что жаба приползет поздже :)

Я тут, понимаешь, велосипед изобрел, а они уже денюжку хочуть :)

> Я тут, понимаешь, велосипед изобрел

Не, это ты на чужом хочешь на халявку прокатиться)

> Не, это ты на чужом хочешь на халявку прокатиться)

Ну сперва я его изобрел, потом узнал что он есть, и за него денюжку хотять. А кататься я на нем не буду - жадные они :) Я лучше свой сделаю...

Если второй раз выполнить LoadLibrary одной библиотеки, то в памяти будет два экземпляра библиотеки и два различных хендла или второй раз будет "холостым" и вернется тот же хендл?

> или второй раз будет "холостым" и вернется тот же хендл?
>
>

Не совсем "холостым", но хендл получишь тот же самый.

Понял, т.е. если из одной dll загрузил два окна, то закрывая одно убивать ее не моги :)

> Где же он открытый, если за использование midas-модуля денюжку
> требуют ?)

Вроде уже давно не требуют, нет ?

Убивать - да, "не моги")

Но FreeLibrary приводит к "убийству" лишь тогда, когда она вызвана ровно столько раз, сколько раз перед этим была вызвана соответствующая ей LoadLibrary.

Иными словами, каждый вызов LoadLibrary приводит к увеличению сч-ка ссылок на модуль на единицу (т.е. впервые загруженная этим вызовом библ-ка имеет значение сч-ка = 1), каждый вызов FreeLibrary - соотв-но к уменьшению оного на единицу. Как только в рез-те очередного вызова FreeLibrary сч-к ссылок обнуляется, система выгружает модуль из АП тек.процесса.

> а то я уже собрался сам считать

Не, новых кулибиных нам не надо)

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