COM, bilbioteki typu i tworzenie ramki na TabSheecie serwera

Piszę aplikację, która ma obsługiwać pluginy (a zdecydowałem sie na COM). Problem tkwi w tym, że każdy z pluginów ma tworzyć swoją ramkę, która zakotwiczona będzie jako/w TabSheet w PageControlu głównej aplikacji. No i nie wiem jak 'zahaczyć' tę tworzoną przez DLLa ramkę. Ogólnie mówiąc, jedyne co musi zrobić moja aplikacja główna to wywołać w pluginie coś w rodzaju konstruktora ramki o prototypie, dajmy na to:

constructor Create(const AOwner : TComponent, const Parent : TWinControl);

. AOwner jest mi potrzebny do wywołania 'oryginalnego' konstruktora ramki, a Parent, aby przypisać go do NowaRamka.Parent (w tym przypadku parentem będzie wskaźnik do TTabSheet, który powinna przekazać bibliotece moja główna aplikacja).
No i to jest właśnie problem, gdyż używam interfejsów oraz biblioteki typu i nijak nie wiem jak zdefiniować taki konstruktor/funkcję w tejże bibliotece. Oczywiście sam konstruktor mogę dowolnie zmieniać - chodzi mi tylko o to, żeby w jakiś sposób przekazać przez COM odpowiednie wskaźniki. W IDLu oczywiście nie ma czegoś takiego jak TWinControl. Jak w takim razie mam przekazać do pluginu obiekty typu TComponent i TWinControl?
Ew. (i to chyba będzie elegantsze rozwiązanie) <font size="3">jak przesłać do głównej aplikacji uchwyt tej nowoutworzonej ramki, aby ona sama(aplikacja) zatroszczyła się o odpowiednie jej umiejscowienie?</span> (czyli znów... jak przesłać HWND przez COM no i czy potem mógłbym go zrzutować na TFrame)

np. próbowałem wariant z :
wpis w .tlb - interfejs pluginu:

HRESULT _stdcall CreateFrame([in] IArchApp * AppInterface, [in] VARIANT AOwner, [in] VARIANT Parent);/*IArchApp sluzy do celow 'callbackowych'*/

jednak i tak nie wiem jak poprawnie zrzutować Varianta na wymagne typy (poza tym obawiam się, że w ten sposób stracę wszystkie zalety (D)COMa, jak chociażby możliwość wywołania dll-a z innej maszyny /wskaźniki w takim przypadku stracą swoją użyteczność?/)

Oczywiście mógłbym zrezygnować z całego COMa albo tylko z bibliotek typu (i samodzielnie napisać plik z interfejsami - w Delphi, nie przejmując się IDLem i jego ograniczeniami), jednak wierzę że da się to w jakiś łatwy sposób obejść.
Miałem też przez moment masochistyczny pomysł i chciałem udostępnić interfejs pozwalający na ręczne tworzenie komponentów wizualnych w głównej aplikacji. Teoretycznie miałoby to chyba szansę działać, jednak znakomicie skomplikowałoby cały kod (prawie WinApi ;) ). Ew. mógłbym wysyłać jakieś komunikaty, jednak w takim razie tracę całą wygodę związaną z interfejsami.

Z góry dziękuję za wszelką pomoc,

ostatnim czasem wydlubalem cos takiego

Wtyczki (Plugin) w oparciu o interfejsy

nie jest to do konca odpowiedz na twoje pytanie. Aby rzucic to na TFrame moze i mozna przekazac to jako wskaznik. Ale to juz wtedy jest applikacvja specyficzna tylko i wylacznie dla delphi. Mozna obudowac np TFrame albo TForm (i chyba to juz jest zrobione - nie dam glowy) w kolejny interfejs a to dalej w biblioteke typow.

Pouczająca lektura... ale zdaje się że Twoja wersja jest także nieco specyficzna (implementracja wtyk jest możliwa tylko w języku w którym pisany był plik z interfejsami - tzn. dla każdego języka wymagany byłby osobny plik z interfejsami). Tego m.in. chciałem uniknąć korzystając z biblioteki typu.

Przeczytałem ten art dość pobieżnie, i myślę że mógłbym robić podobnie: przekazywać tylko uchwyt HWND mojego TabSheeta i korzystać z CreateParams (nie wiem jak to zadziała w przypadku TFrame /ostatecznie mógłbym przerobić ramkę na formę ;)/, ale podejrzewam że ok - sugestie i wskazówki implementacyjne będą mile widziane). Z tym że... nadal pozostaje problem przekazywania tego nieszczęsnego uchwytu via biblioteka typu+COM. Niestety IDL nie uwzględnia czegoś takiego jak typ HWND, ale zastanawiam się, czy nie mógłbym przekazywać go jako zwykłej wartości word(int?) /o ile da się to jakoś elegancko rzutować - tu też przydałyby się wskazówki :)/ (z przenośnością (czyt. obsługą innych języków programowania) kodu też nie powinno być wielkich problemów, gdyż uchwyty z tego co mi się kojarzy są elementem samego WinAPI). Gorzej chyba z przenośnością w sensie uruchamiania ze zdalnej maszyny, ale i tak nie zamierzałem korzystać z DCOMa.

Jeżeli nie da się inaczej, faktycznie stworzę wersję 'Delphi-only', ale póki co jeszcze eksperymentuję, no i czekam na jakieś pomysły.

reichel napisał(a)

Mozna obudowac np TFrame albo TForm (i chyba to juz jest zrobione - nie dam glowy) w kolejny interfejs a to dalej w biblioteke typow.

Jeżeli jest coś takiego, chętnie zapoznałbym się z tym bliżej. Choć i tak znakomicie utrudni to pisanie wtyczek (wersja tekstowa zamiast GUI), no i potrzebna byłaby także obsługa zdarzeń tych wszystkich tworzonych zdalnie komponentów.

Jestes juz prawie w domu :)

1. typ HWND -> popatrz jak jest zdefiniowany w windows.pas (nie jestem pewien czy nie rozni sie odrobine ta definicja od wersji delphi np INTEGER? )
   to cos w rodzaju (w przykladzie dla masm stosuje to zamiennie)

type
  HWND = WORD ;

wiec tu nie ma problemu

2. Jesli chciales rzucac na TFrame to nie za bardzo widze stosowanie wtyku w jezykach gdzie nie jest zdefiniowane TFrame, okno (czytaj uchwyt) jest wszedzie w windows.

3. Ja nie zastosowalem biblioteki typow z kilku powodow:

   • nie zawsze jest opcja w delphi (np Personal Edition)
   • Mniej smieci w kodzie (a i tak trzeba dac SDK do wtyczki)
     ale z przykladu VC++ z ATL widac ze jest ona dolaczana automatycznie, to po prostu kwestia klikniecia w opcjach " dolacz biblioteke typow".

Tylko w jezyku w ktorym byl pisany wtyk z interfejsami ??? No a co to za problem go przelozyc ??? Jak zaczelem zabawe w delphi to wiekszosc ciekawych
interfejsow byla w c++ tylko. To tak jakbys napisal ze nie zatosujesz w delphi biblioteki dll bo masz opis eksportow tylko w c++. Generalnie mozna podac calkowicie abstrakcyjny opis (bardziej bliski asm) np funkcja 1 robi to i to i ma takie to a takie parametry (wielkosc)

4. Pamietam ze widzialem cos w kodach VCL, ale to mogla byc dawno i nieprawda (nie mam takowych pod reka), ale zdawalo mi sie wtedy, ze niektore komponenty byly juz obudowane w interfejsy. W najgorszym razie bedziesz musial obudowac w postaci IForm = class(TInterfacedObject,TForm). I udostepnic to co Ci bedzie potrzebne.

pozdrawiam