2011-12-18 14 views
5

Mam aplikację, która ładuje BPL, że wewnątrz prostego formularza.Dostęp do publicznych metod i właściwości wewnątrz Delphi BPL

Ten formularz jest opcjonalną opcją głównej aplikacji.

BPL ładuje się prawidłowo, formularz jest wyświetlany poprawnie, ale nie wiem, jak uzyskać dostęp do publicznych metod i właściwości formularza wewnątrz pliku bpl.

Czy ktoś może podać prosty przykład?

mój kod:

// Load the BPL on aplication Load 
LoadPackage('About.bpl'); 

// CAll for TForm1 inside the About.BPL 
var 
    AClass: TClass; 
    AForm: TForm; 
begin 

    AClass := GetClass('TForm1'); 
    if AClass <> nil then 
    begin 
     Application.CreateForm(TComponentClass(AClass), AForm); 
     AForm.Show; 
    end; 

// The unit TForm1 inside the BPL package 
unit Unit1; 

interface 

uses 
    Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, 
    Dialogs, StdCtrls; 

type 
    TForm1 = class(TForm) 
     Button1: TButton; 
     Label1: TLabel; 
     procedure Button1Click(Sender: TObject); 
    private 
     { Private declarations } 
    public 
     { Public declarations } 
     PublicMthd; 
    end; 

var 
    Form1: TForm1; 

implementation 

{$R *.dfm} 

Procedure TForm1.PublicMthd; 
Begin 
    ShowMessage('Inside call'); 
End; 

initialization 
    RegisterClass(TForm1); 

finalization 
    UnRegisterClass(TForm1); 

end. 

Jak mogę uzyskać dostęp do "PublicMthd" w TForm1?

+2

Pokaż nam, jak wygląda twój kod. Istnieje wiele sposobów ładowania plików BPL, a odpowiedź będzie zależeć od tego, jak to robisz. –

+0

Zobacz także to pytanie SO: [wykonaj-a-metoda-z-formularza-utworzonego przez-klasy-odniesienia-delphi] (http://stackoverflow.com/questions/2991934/execute-a-method-from -a-form-by-klasa-referencja-delphi) –

+0

Czy napisałeś tę BPL? Dlaczego nie wyeksportować funkcji o nazwie GetMainForm, a następnie wywołać funkcję "GetMainForm: TForm", a następnie można uzyskać do niego dostęp?Czy istnieje powód, dla którego nie można zastosować podejścia opartego na zdrowym rozsądku? Co zamierzacie zrobić, gdy znacie klasy i możecie je wyliczyć, a może nawet stworzyć ich instancje? Czy istnieje powód, dla którego nie określasz interfejsu IPluginInterface, który pasuje do domeny twojego problemu, zamiast przechodzić bezpośrednio do podstawowych typów klas z głównej aplikacji? –

Odpowiedz

9

Jednym z celów posiadania TOptionalForm w dynamicznie ładowanym bpl (przy założeniu, że jest to z "opcjonalnego" bitu)) jest uniknięcie, aby aplikacja zawierała definicję klasy TOptionalForm (znajduje się ona w jednostce zawartej w pakiet i tylko tam).

Oznacza to, że aplikacja nie może nic o tym nie wiem, chyba użyć albo:
- wspólna baza Klasa
- interfejs deklarowania właściwości i metody, które mają dostęp do
- podstawowe RTTI dostęp do publikowanych właściwości i metody
- niektóre rozszerzone RTTI, aby uzyskać dostęp do właściwości i metod publicznych (jeśli masz D2010 lub nowszy)
- niektóre procedury zewnętrzne z bpl akceptujące parametr klasy bazowej (lub TObject/wskaźnik), typując go jako TOptionalForm wewnętrznie.

To jest bardzo niejasne i ogólne i bardziej precyzyjny o kod byłyby potrzebne do udoskonalenia ...

2

Jeśli trzeba załadować BPL dynamicznie, należy użyć - jak już metioned przez Francois:

  • klasą abstrakcyjną (co jest bardziej podobny lub Delphi)
  • interfejs (który uważam czystsze i mają lepsze doświadczenie)

miejsce d do jednostki interfejsu, która jest używana zarówno przez aplikację główną, jak i formularz BPL.

Używam pośredniego "kontraktu/interfejsu" BPL, statycznie używanego zarówno przez aplikację główną, jak i dynamicznie ładowaną.

W przypadku użycia interfejsu, może również przyjrzeć się dyrektywie $WEAKPACKAGEUNIT, aby jeszcze bardziej oddzielić BPL od aplikacji.

Aby skomentować komentarze - za pomocą eksportu bibliotek DLL lub RTTI zasadniczo pominięto cały punkt BPL, który jest typem i dzieleniem przestrzeni nazw.

+1

Ja jestem tego przykładem i dam ci nagrodę – DRokie

Powiązane problemy