ورود

View Full Version : استفاده از bpl در دلفي



NOROOZY
سه شنبه 27 اردیبهشت 1384, 14:17 عصر
در مورد نحوه استفاده از فایل bplدر دلفی کسی میتونه کمک کنه
یعنی یک فایل اجرائی داشته باشیم و زیر برنامه ها در فیلهای bpl باشه و از اونجا اجرا بشه تا فایل exe زیاد بزرگ نشه .(نمیخام از فیل exe برای این کار استفاده کنم)

چهارشنبه 28 اردیبهشت 1384, 13:46 عصر
فایل bpl یک پکج دلفی است و این جور که شما میخواهید فکر نمیکنم بشه . برای این کار شما میبایست از DLL استفاده کنید .

:موفق:

NOROOZY
چهارشنبه 28 اردیبهشت 1384, 14:15 عصر
ممنون ولی خیلی کلی گفتی :گیج: :wink:

majid_afra222
چهارشنبه 28 اردیبهشت 1384, 14:36 عصر
سلام جناب NOROOZYی عزیز
راهی که شما می خواهید استفاده کنید٬‌روش درستی برای توسعه برنامه ها می باشد
استفاده از package ها در یک برنامه کاربردی مثل dll ها و ... امکان پذیر می باشد.
در کتاب راهنمای توسعه گر دلفی 6 (کتاب غزال) فصل 14 (استفاده موثر از بسته ها) توضیحات لازم رو داده.
در ضمن من این روش رو تو چند تا شرکت نرم افزاری خوب دیدم که استفاده می کردند.
فقط یه کمی دردسر برای شروع داره.

Delphi-Clinic
چهارشنبه 28 اردیبهشت 1384, 14:56 عصر
Back in January, 1999, Delphi Informant ran an article on developing plugins for your Delphi applications. It covered some of the basics of that plugins are, how to make them, exporting fucntions, and so on. I was tremendously inspired, because a system I was (and still am) working on could (and did!) benefit greatly from such a technology.

However, the layout that was described had some pretty big flaws. First, it wasn't really OOP. Second, it was a little hairy to pass information back and forth. Finally, you had to write a lot of the initialization stuff yourself. There had to be a better way.

A quick overview of what a plugin is: Plugins are DLL files. They contain additional commands or other functionality that can add to your system. Often they add menu items or toolbuttons to your application. Simply the existance of a file can radically enhance your software.

There was. Step 1 was to create an abstract, base class for a plugin. The plugin should know a bit about the application (for example, having a copy of the Application variable could be useful). It should know a bit about itself: how many "commands" it has, what the name of the plugin was, the author, etc. After some fuddling, this is what I came up with:

type
TuilPlugin = class(TObject)
private
FHostApplication : TApplication;
FFilename : string;
FManager : TComponent;
protected
{ Protected declarations }
public
{ Public declarations }
constructor Create;
destructor Destroy; override;
function GetAuthor : String; virtual; stdcall;
function GetDescription : String; virtual; stdcall;
function GetName : String; virtual; stdcall;
function Initialize(Manager : TComponent; HostApplication : TApplication; Filename : string) : Boolean; virtual; stdcall;
function GetNumCommands : Integer; virtual; stdcall;
procedure GetCommand(index : integer; var Caption, Hint, Data : string; var Bitmap : HBitmap; var Event : TNotifyEvent); virtual; stdcall;
procedure Configure; virtual; stdcall;

{ properties }
property HostApplication : TApplication read FHostApplication;
property Filename : string read FFilename;
property Manager : TComponent read FManager;
end; { TuilPlugin }

Most of the methods and properties are self explanatory. Each plugin publishes a number of commands (how many is returned by GetNumCommands). To get information about a specific command, a call to GetCommand will give you the command's caption, bitmap, hint and event. Notice the stdcall after each of the methods. This is required by the dll in order for it to work properly.

The second thing that needed to be done was to develop a loader component, which would take care of all the drudgery of creating, initializing, destroying and generally managing the plugins. Here's what I came up with:

TuilPluginManager = class(TComponent)
private
// Private declarations
FExtension : String;
FPlugins : TList;
FOnBeforeLoading : TNotifyEvent;
FOnAfterLoading : TNotifyEvent;
FOnBeforeLoad : TuilBeforeLoadEvent;
FOnAfterLoad : TuilAfterLoadEvent;
FOnNewCommand : TNewCommandEvent;
protected
[...]
public
// Public declarations
constructor Create(AOwner : TComponent); override;
destructor Destroy; override;
procedure LoadPlugin(Filename : string); virtual;
procedure LoadPlugins; virtual;
procedure UnloadPlugin(index : integer); virtual;
procedure GetLoadedPlugins(PluginList : TStrings); virtual;
property Plugins[index : integer] : TuilPlugin read GetPlugins; default; // Public
property PluginCount : integer read GetPluginCount;
published
// Published properties and events
property Extension : String read GetExtension write SetExtension; // Published
property Version : string read GetVersion write SetVersion;
property OnBeforeLoading : TNotifyEvent read FOnBeforeLoading write FOnBeforeLoading;
property OnAfterLoading : TNotifyEvent read FOnAfterLoading write FOnAfterLoading;
property OnBeforeLoad : TuilBeforeLoadEvent read FOnBeforeLoad write FOnBeforeLoad;
property OnAfterLoad : TuilAfterLoadEvent read FOnAfterLoad write FOnAfterLoad;
property OnNewCommand : TNewCommandEvent read FOnNewCommand write FOnNewCommand;
end; // TuilPluginManager

The main meat procedure here is LoadPlugin. It handles the actual loading and initialization of a plugin. LoadPlugins is useful as well, since it globally loads all the plugins in the application's folder.

All this is well and good, but how the heck do we make our OWN plugins? Actually, it's really simple.

First, you want to create a descendant of the TuilPlugin class. Include (private) event handlers for each of the commands you want to export.

type
TMyPlugin = class(TuilMyPlugin)
procedure Command1(Sender : TObject);
procedure Command2(Sender : TObject);
public
function GetAuthor : String; override; stdcall;
function GetDescription : String; override; stdcall;
function GetName : String; override; stdcall;
function Initialize(Manager : TComponent; HostApplication : TApplication; Filename : string) : Boolean; override; stdcall;
function GetNumCommands : Integer; override; stdcall;
procedure GetCommand(index : integer; var Caption, Hint, Data : string; var Bitmap : HBitmap; var Event : TNotifyEvent); override; stdcall;
procedure Configure; override; stdcall;
end;

The two most important methods you override are GetNumCommands and GetCommand. GetNumCommands is easy. In this case, we've got 2 commands we're exporting:

function TMyPlugin.GetNumCommands : integer;
begin
Result := 2;
end;

GetCommand is a little trickier. You need to determine what command number you're getting, and return the appropriate information and event handler:

procedure TupSamplePlugin.GetCommand(index : integer; var Caption, Hint, Data : string; var Bitmap : HBitmap; var Event : TNotifyEvent);
begin
Caption := '';
Event := nil;
case index of
0 : begin
Caption := 'Command One';
Hint := 'Command One';
Data := '';
Event := CommandOne;
Bitmap := 0;
end;
1 : begin
Caption := 'Command Two';
Hint := 'Command Two';
Data := '';
Event := CommandTwo;
Bitmap := 0;
end;
end;
end;

That's most of it, believe it or not. We have to export a RegisterPlugin procedure with our dll, and include ShareMem as the first unit in both the DLL and our application's .DPR files.

Because there is so much to make sure you do (Sharemem, stdcall, RegisterPlugin, and so on), I put together a Wizard that would make things a lot easier.

kamyar_kimiyabeigi
شنبه 21 خرداد 1384, 17:12 عصر
یه سری به سایت زیر بزن اونها همین طور که شما میخواین کار میکنن
www.rayannazm.com