Access to public methods and properties inside a Delphi BPL

Question

I have an application that loads a BPL that as inside a simple form.

This form is an optional option of the main application.

The BPL loads correctly, the form is shown correctly, but I don’t know how to access the public methods and properties of the form inside the bpl.

Can anyone provide a simple example?

my code:

// 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.

How can i access "PublicMthd" in Tform1 ?

Casaubon

Show us what your code looks like. There are a variety of ways to load BPL files and the answer is going to depend on how you are doing it. – Plains

See also this SO question : execute-a-method-from-a-form-created-by-class-reference-delphi – Distaff

Did you write this BPL? Why don't you export a function called GetMainForm, and then you call function GetMainForm:TForm and then you can access it? Is there a reason you can't use a common sense approach? What do you intend to do once you know the classes and can enumerate them, and perhaps even create instances of them? Is there a reason you aren't specifying an IPluginInterface that fits your problem domain, instead of going directly to the underlying class types, from your main application? – Reduced

Your executable knows nothing about the 'TForm1' in the bpl, only that it is (or descends from) a TForm. Hence you can only access TForm's methods and properties. Like it or not, François' answer is the correct answer. – Kirstenkirsteni

Answer 1

One of the interest of having TOptionalForm in a dynamically loaded bpl (assuming this from the "optional" bit)) is to avoid for your application to hold the definition of the TOptionalForm class specifically (it's in the unit contained in the package and only there).

That means that your application cannot know anything about it unless you use either:
- a shared base Class
- an Interface declaring the properties and methods you want to access
- some basic RTTI to access published properties and methods
- some extended RTTI to access public properties and methods (if you have D2010 or later)
- some external routines from the bpl accepting a base class parameter (or TObject/pointer) typecasting it as TOptionalForm internally.

This is very vague and general and more precision about your code would be needed to refine...

Canonize

Answer 2

If you need to load the BPL dynamically, you should use - as already metioned by François:

• an abstract class (which is more Delphi-like or)
• an interface (which I consider cleaner and have better experience with)

placed into an interface-only unit used by both the main application and the form BPL.

I use an intermediate "contract/interface" BPL, statically used by both the main application and the dynamically loaded ones.

In the case of interface usage, may also look at the $WEAKPACKAGEUNIT directive to further decouple the BPL fom the application.

To comment on the comments - by using DLL exports or RTTI, you would basically bypass the whole point of BPLs, which is type and namespace sharing.

Ruyle

I simple example of that and I give you the bounty – Casaubon