 |
| |
|
|
 |
Autor |
Nachricht |
 |
| |
| sakura |
#1| Verfasst am: 14.05.2003, 13:25 Titel: PlugIns in eigenen Anwendungen |
 |
|
|
|
Super-Moderator
Alter: 33
Status: offline
Beiträge: 11.294
angemeldet: 10.06.2002
Wohnort: München
RAD-Studio 2007 Architect
|
Sprache: Delphi (Win32)
Nachdem ich gezeigt habe, wie man Erweiterungen (PlugIns) für die Delphi-IDE erstellen kann, möchte ich dieses Mal zeigen, wie man dieses Konzept in eigenen Anwendungen nutzen kann. Dazu werde ich das Tutorial in mehrere Abschnitte aufteilen.
Der erste Abschnitt zeigt die denkbar einfachste Form ein PlugIn zu erstellen. Diese Methode ist nicht unbedingt sehr flexibel, erlaubt es jedoch, schnell einfache Erweiterungen zu erstellen. Vorteil ist, daß das Thema auch für "Neulinge" auf diesem Bereich recht einfach betrachtet werden kann.
Um dieses zu erreichen, werde ich die erste Variante als "Delphi-Only-Lösung" vorstellen, daß heißt, daß auch die PlugIns mit Delphi erstellt werden müssen.
| Code: | markieren | HINWEIS:
Diese Variante benötigt die Unit ShareMem, welche wiederum voraussetzt, daß die Library BORLNDMM.DLL
zusammen mit der Anwendung ausgeliefert wid. Diese DLL befindet sich im Delphi\Bin Verzeichnis und darf
zusammen mit der Anwendung weitergegeben werden. In älteren Delphi-Versionen (3...) ist es möglich, daß die
Borland DLL einen anderen Namen hat.
Die Unit ShareMem muß als erstes in der Uses-Klausel des Projektes und aller PlugIns stehen! |
|
PlugIns, wie kommen die eigentlich in die Anwendung
Es gibt verschiedene Möglichkeiten, woran eine Anwendung erkennt, das diese PlugIns zu laden hat. Alle Möglichkeiten setzen eines jedoch voraus: Die Anwendung muß so konzipiert sein, daß diese PlugIns überhaupt unterstützt.
In diesem Beispiel sucht die Anwendung nach der Datei PlugIns.ini, welche im gleichen Verzeichnis wie die Anwendung liegen muß. Die Ini-Datei sieht wie folgt aus.  Code: | zusammenfalten | markieren | 1
·
·
·
5
·
·
·
·
10
·
·
13
| [info]
info1=This file contains a list of all plugins.
info2=each plugin has its own section
info3=each plugin section has to contain a string "type=plugin"
info4=each plugin section has to contain a string "dllname" pointing to the plugin file
[sample01]
type=Plugin(off)
dllname=plugin01.dll
[sample02]
type=Plugin(off)
dllname=plugin02.dll |
|
Die rot dargestellten Bereiche müssen gelöscht werden, damit die PlugIns geladen werden. In den ZIP-Files sind die Plug-Ins so eingestellt, daß diese (per Default) erst einmal nicht geladen werden, damit die Anwendung ohne Plug-Ins getestet werden kann. Wenn die Strings (off) gelöscht sind, werden die Plug-Ins beim nächsten Start automatisch geladen, dann kann das "neue" Verhalten der Anwendung getestet werden.
Andere Möglichkeiten nach Plug-Ins zu suchen
Oft werden zwei weitere Methoden genutzt, um Plug-Ins zu suchen. - Die Plug-Ins müssen in der Registry unter einem bestimmten Schlüssel eingetragen werden (z.B. Borland Delphi)
- Die Plug-Ins müssen in einem bestimmten Verzeichnis liegen.
Letztere Methode ist nur bedingt empfehlenswert, da diese voraussetzt, das in dem Verzeichnis ausschließlich Plug-Ins liegen, andere Dateien können zu Problemen führen.
Plug-Ins zulassen
In diesem Beispiel werden wir ausschließlich Plug-Ins zulassen, welche als DLLs geladen werden können. Diese Plug-Ins müssen eine Funktion mit dem Namen LoadPlugIn exportieren, welche folgende Paramter hat:
Der erste Parameter Parent erhält den Handle der Anwendung, welche das Plug-In lädt. Der zweite Paramter PlugIn kann vom Plug-In genutzt werden, um ein Object zurückzuliefern. Wird keines zurückgeliefert, so wird da Plug-In nicht im Menü angezeigt.
Die Applikation lädt die Plug-Ins mit Hilfe der Win-API Funtion LoadLibrary. LoadLibrary liefert einen Handle auf die geladene Library zurück. Wenn die Library erfolgreich geladen wurde, versucht Applikation die Methode LoadPlugIn mit Hilfe der Win-API Funtion GetProcAddress zu laden.
| Code: | markieren | HINWEIS:
Bei dem Export von Funktionen aus DLLs muß Groß- und Kleinschreibung beachtet werden (C++-Standard)!!! |
|
Nach erfolgreichem Ladevorgang der Prozedur wird diese aufgerufen und das Plug-In initialisiert.
| Code: | markieren | HINWEIS:
In diesem Beispiel muß sich das PlugIn um die Initialisierung des zurückgelieferten Objektes kümmern.
Die Applikation übernimmt die Zerstörung des Objektes, wenn dieses nicht mehr gebraucht wird. |
|
Das exportierte Plug-In Objekt
Damit die Applikation nach Bedarf auf das Plug-In zurgreifen kann, muß dieses ein Objekt zurückliefern, welches durch die Applikation erkannt wird. Damit sowohl die Applikation, als auch jedes Plug-In vom gleichen Objekttyp "sprechen", wird dieser in einer gemeinsamen Unit definiert. Diese Unit ist dem Download beigefügt (\Shared Units\uPlugInDefinition.pas). | Delphi-Quellcode: | zusammenfalten | markieren | 1
·
·
·
5
·
·
·
·
10
·
·
·
·
15
·
·
·
·
20
| //Auszug aus der Unit
type
TPlugIn = class
public
constructor Create(aParent: THandle);
// information strings
function GetName: string; virtual; stdcall; abstract;
function GetAuthor: string; virtual; stdcall; abstract;
function GetComment: string; virtual; stdcall; abstract;
// menu data
function GetMenuText: string; virtual; stdcall; abstract;
function GetEnabled: Boolean; virtual; stdcall; abstract;
// launch the Expert
procedure Execute; virtual; stdcall; abstract;
// event handler
function EventHandler(EventNotification: TEventNotification): TEventAction;
virtual; stdcall; abstract;
end;
TLoadPlugIn = function(Parent: THandle; var PlugIn: TPlugIn): Boolean; |
|
Einerseits ist hier die abstrakte Definition, welche daß durch jedes Plug-In zu exportierende Objekt zeigt. Dieses Objekt liefert verschiedene Informationen zurück. Unter anderem wird gesteuert, wie sich das Plug-In im Menü darstellt und auf welche Ereigenisse reagiert wird. Desweiteren ist auch das Format der zu exportierenden Funktion TLoadPlugIn definiert.
Das Plug-In I
Jedes Plug-In, welches interaktiv angesteuert werden kann, muss ein Objekt vom Typ TPlugIn exportieren. Dieses Objekt muß alle abstrakten Methoden implementieren, welche durch die abstrakte Klasse TPlugIn definiert sind.
Im ersten Plug-In sieht die Klassendefinition wie folgt aus | Delphi-Quellcode: | zusammenfalten | markieren | 1
·
·
·
5
·
·
·
·
10
·
·
·
·
15
·
·
·
·
20
·
·
·
·
25
·
27
| type
TPlugIn01 = class(TPlugIn)
public
// information strings
function GetName: string; override; stdcall;
function GetAuthor: string; override; stdcall;
function GetComment: string; override; stdcall;
// menu data
function GetMenuText: string; override; stdcall;
function GetEnabled: Boolean; override; stdcall;
// launch the Expert
procedure Execute; override; stdcall;
// event handler
function EventHandler(EventNotification: TEventNotification): TEventAction;
override; stdcall;
end;
{ TPlugIn01 }
function TPlugIn01.EventHandler(EventNotification: TEventNotification):
TEventAction;
begin
// nothing to do
Result := evnContinue;
end;
... |
|
Alle Methoden werden implementiert. Das erste Plug-In führt keine weiteren Aktionen aus. Wird sein Menüpunkt durch den Nutzer aktiviert, so wird lediglich eine Messagebox angezeigt.
Das Plug-In II
Das zweite Plug-In ist ein wenig komplexer. Es reagiert auf mehrere Ereignisse (File->New, File->Open, File->Save). Dazu wird in der Methode EventHandler auf entsprechende Ereignisse reagiert. | Delphi-Quellcode: | zusammenfalten | markieren | 1
·
·
·
5
·
·
·
·
10
·
·
·
·
15
·
·
·
·
20
·
·
·
·
25
26
| function TPlugIn02.EventHandler(
EventNotification: TEventNotification): TEventAction;
begin
case EventNotification of
evnFileNew:
if MessageBox(Parent, 'Änderungen verwerfen?', 'Öhm', MB_ICONWARNING or
MB_YESNO) = IDYES then
Result := evnContinue
else
Result := evnAbort;
evnFileOpen:
if MessageBox(Parent, 'Änderungen verwerfen?', 'Öhm', MB_ICONWARNING or
MB_YESNO) = IDYES then
Result := evnContinue
else
Result := evnAbort;
evnFileSave:
begin
MessageBox(Parent, 'Bitte "Speichern als..." wählen', 'Öhm',
MB_ICONINFORMATION or MB_OK);
Result := evnAbort;
end;
else
Result := evnContinue;
end;
end; |
|
Damit das Plug-In auf diese Ereignisse reagieren kann, muß die Applikation das Plug-In informieren, wenn solche Ereignisse auftreten. Dazu stelle ich Ihnen die Methode RunEvent aus der Applikation vor. | Delphi-Quellcode: | zusammenfalten | markieren | 1
·
·
·
5
·
·
·
·
10
·
·
·
·
15
| function TForm1.RunEvent(EventNotification: TEventNotification): Boolean;
var
I: Integer;
begin
for I := 0 to High(FPlugIns) do
if FPlugIns[I].PlugIn <> nil then
begin
if FPlugIns[I].PlugIn.EventHandler(EventNotification) = evnAbort then
begin
Result := False;
Exit;
end;
end;
Result := True;
end; |
|
Diese Methode sendet ein Ereignis an alle Plug-Ins. Wenn alle Plug-Ins den Status evnContinue zurückliefern, dann liefert die Methode True zurück, ansonsten False. Diese Methode wird zum Beispiel aufgerufen, wenn der User im Menü File auf New klickt. | Delphi-Quellcode: | markieren | procedure TForm1.New1Click(Sender: TObject);
begin
if RunEvent(evnFileNew) then
begin
mmoFileContent.Clear;
FFileName := '';
end;
end; |
|
Wenn kein Plug-In geladen ist, wird der aktuelle Inhalt des Memos einfach gelöscht. Wenn das zweite Plug-In geladen ist, fragt dieses den User, ob er die Inhalte des Memos wirklich verwerfen will. Antwortet der mit "nein", liefert das Plug-In II evnAbort zurück und das Memo wird nicht gelöscht.
Der komplette Code
Der komplette Code für dieses einfache Beispiel kann von Mitgliedern der Delphi-PRAXiS frei runtergeladen werden. Wenn Fragen bestehen, einfach ins Forum posten. Mal schauen...
Der nächste Schritt
Im nächsten Schritt werde ich ein etwas komplexeres Beispiel zeigen. Voraussetzung dafür wird ein Verständnis von Delphi-Interfaces sein. Wann es kommt, steht noch nicht fest 
... ... |
| [ An diesen Beitrag wurden eine oder mehrere Dateien angehängt. Zum Herunterladen bitte anmelden. ] |
Jeder Mensch lebt praktisch in seiner eigenen, privaten Welt. Kommunikation bedeutet zwischen diesen Welten Brücken zu bauen.
CodeGear Associate Evangelist
 Zuletzt bearbeitet von sakura am 14.05.2003, 13:25, insgesamt 1-mal bearbeitet. |
  |
|
|
|
| |
| MichaelK |
#2|Verfasst am: 14.05.2003, 15:47 Titel: |
|
|
|
|
Mitglied
Status: offline
Beiträge: 10
angemeldet: 08.05.2003
|
Hi!
Ich finde dein Tutorial sehr gut: es ist verständlich, gut strukturiert und vorallem praktisch. Mir hat es sehr geholfen meine Andwendungen flexibel zu gestalten (hab ja mehr oder weniger um ein Tutorial "gebeten", auch wenn ich's nicht direkt gesagt hab )
Ich freue mich schon auf den zweiten Teil! |
|
| |
|
|
|
| |
| sakura |
#3|Verfasst am: 15.05.2003, 16:16 Titel: |
|
|
|
|
Super-Moderator
Alter: 33
Status: offline
Beiträge: 11.294
angemeldet: 10.06.2002
Wohnort: München
RAD-Studio 2007 Architect
|
Obwohl einigen schon für heute versprochen  kommt der zweite Teil erst morgen. Dafür aber ohne Interfaces aber um so cooler.
...... |
Jeder Mensch lebt praktisch in seiner eigenen, privaten Welt. Kommunikation bedeutet zwischen diesen Welten Brücken zu bauen.
CodeGear Associate Evangelist |
| |
|
|
|
| |
| sakura |
#4|Verfasst am: 16.05.2003, 15:09 Titel: |
|
|
|
|
Super-Moderator
Alter: 33
Status: offline
Beiträge: 11.294
angemeldet: 10.06.2002
Wohnort: München
RAD-Studio 2007 Architect
|
Dieser zweite Teil stellt ein etwas komplexeres Beispiel vor. Bevor Sie sich diesen Teil durchlesen, empfehle ich dringend den ersten Teil, falls Sie sich vorher nicht mit Erweiterungen, DLLs oder ähnlichem ausführlich beschäftigt haben. Gute Kenntnisse in der objekt-orientierten Programmierung sind zwingend erfordlich, da dieses Tutorial dafür keinen Platz bietet.
In diesem Teil stelle ich Ihnen eine Methode vor, welche sehr stark an die Art angelehnt ist, wie auch Delphi diese bereits seit mehreren Versionen unterstützt. Nachteil dieser Methode ist, daß auch die Plug-Ins in Borland Delphi bzw. Borland C++ erstellt werden müssen. Der Vorteil ist die relative "Einfachheit" der Strategie.
| Code: | markieren | HINWEIS:
Auch diese Version nutzt die Unit ShareMem.
Die Unit ShareMem muß als erstes in der Uses-Klausel des Projektes und aller PlugIns stehen! |
|
Registrieren der Plug-Ins
Um auch einen anderen Weg der Registrierung von Plug-Ins zu zeigen, habe ich dieses Mal einen Eintrag in die Registry gewählt. Ähnlich dem Verfahren, welches auch Borland Delphi nutzt. Alle zu ladenen Plug-Ins müssen sich unter folgendem Registry-Key eintragen.
HKCU\Software\Delphi-PRAXiS\Extendable Application\PlugIns
Für jedes Plug-In muß ein String-Wert eingetragen werden, dessen Value den Pfad und den Namen der Plug-In-DLL enthalten. Der Name des Wertes kann frei gewählt werden.
Das Design der Software
Unter Design ist nicht das Aussehen der Anwendung zu verstehen, als viel mehr der interne Aufbau des Codes! In einer öffentlichen Unit (Shared Units\uAppIntf.pas) werden die abstrakten Basisklassen (TIApplication, TIMainMenu, TIMenuItems, TIMenuItem, TIDocuments, TIDocument, TIDocument) vorgestellt, welche durch die Anwendung den Plug-Ins zur Verfügung gestellt werden. Zusätzlich wird auch die Basisklasse (TPlugInObject) vorgestellt, welche durch jedes Plug-In exportiert werden muß.
Diese Unit muß sowohl von der Applikation als auch von jedem Plug-In importiert werden. Mit einer Ausnahme sind alle Klassenmethoden als abstrakt definiert. Die Ausnahme bildet der constructor der Klasse TPlugInObject, welcher eine Referenz auf das von der Applikation exportierte Hauptobjekt speichert.
Die Aufgaben der Applikation
Damit die Applikation dem Plug-In wirkliche Möglichkeiten zur Erweiterung bietet, muß diese Schnittstellen nach aussen geben. Die Startschnittstelle ist TIApplication und diese ist in diesem Beispiel wie folgend definiert. | Delphi-Quellcode: | markieren | TIApplication = class
public
function GetHandle: Integer; virtual; stdcall; abstract;
function GetMainMenu: TIMainMenu; virtual; stdcall; abstract;
function GetDocuments: TIDocuments; virtual; stdcall; abstract;
function GetActiveDocument: TIDocument; virtual; stdcall; abstract;
procedure ShowMessage(const Msg: String); virtual; stdcall; abstract;
end; |
|
Während der Initialisierung des Plug-Ins erhält das Plug-In von der Anwendung eine Referenz auf ein Objekt vom Typ TIApplication. Diese Objekt bietet in diesem Beispiel fünf Methoden.- GetHandle liefert das Handle der Anwendung zurück
- GetMainMenu erstellt ein Objekt vom Typ TIMainMenu und liefert dieses an die Anwendung zurück, welche dieses anschließend nutzen kann, um das Hauptmenü zu erweitern
- GetDocuments erstellt ein Objekt vom Typ TIDocuments und gibt dem Plug-In die Möglichkeit mit den einzelnen, geöffneten Dokumenten zu arbeiten.
- GetActiveDocument[I] erstellt ein Objekt vom Typ [I]TIDocument. Die Plug-Ins haben so jederzeit Zugriff auf das aktuelle Dokument.
- ShowMessage fordert die Anwendung auf, dem Nutzer eine MessageBox zu zeigen
| Code: | markieren | HINWEIS:
Die Anwendung erstellt sämtliche Objekte (außer TIApplication) ausschließlich für die Plug-Ins.
Wenn die Plug-Ins das Objekt nicht mehr benötigen, dann müssen diese das Objekt auch wieder freigeben,
um Resourcen zu sparen. |
|
Das Menü dem Client anbieten
Der Trick. Wie schon mit der Applikation, möchten wir dem Plug-In keinen direkten Zugriff auf das Menü gewähren, um den dadurch entstehenden Risiken vorzubeugen. Das bringt natürlich auch etwas Arbeit mit sich, da ein Wrapper für das Menü und sämtliche Menüpunkte erstellt werden muss.
Dazu werden die folgenden abstrakten Klassen definiert, welche auch den Plug-Ins bekannt sind: | Delphi-Quellcode: | zusammenfalten | markieren | 1
·
·
·
5
·
·
·
·
10
·
·
·
·
15
·
·
·
·
20
·
·
·
·
25
·
·
·
·
30
·
·
·
·
35
·
·
38
| TIMainMenu = class
public
function GetMenuItems: TIMenuItems; virtual; stdcall; abstract;
function InsertMenuItem(aIndex: Integer; aCaption, aHint, aName: String;
aShortCut: Word; aTag: Integer; OnClick: TOnMenuClick): TIMenuItem;
virtual; stdcall; abstract;
end;
TIMenuItems = class
public
function GetCount: Integer; virtual; stdcall; abstract;
function GetItem(Index: Integer): TIMenuItem; virtual; stdcall; abstract;
function FindItem(aName: String): TIMenuItem; virtual; stdcall; abstract;
function RemoveItem(aMenuItem: TIMenuItem): Boolean; virtual; stdcall;
abstract;
end;
TIMenuItem = class
public
function GetMenuItems: TIMenuItems; virtual; stdcall; abstract;
function InsertMenuItem(aIndex: Integer; aCaption, aHint, aName: String;
aShortCut: Word; aTag: Integer; OnClick: TOnMenuClick): TIMenuItem;
virtual; stdcall; abstract;
function FindItem(aName: String): TIMenuItem; virtual; stdcall; abstract;
function GetIndex: Integer; virtual; stdcall; abstract;
function GetCaption: String; virtual; stdcall; abstract;
procedure SetCaption(aValue: String); virtual; stdcall; abstract;
function GetHint: String; virtual; stdcall; abstract;
procedure SetHint(aValue: String); virtual; stdcall; abstract;
function GetName: String; virtual; stdcall; abstract;
function GetShortCut: Word; virtual; stdcall; abstract;
procedure SetShortCut(aValue: Word); virtual; stdcall; abstract;
function GetTag: Integer; virtual; stdcall; abstract;
procedure SetTag(aValue: Integer); virtual; stdcall; abstract;
function GetOnClick: TOnMenuClick; virtual; stdcall; abstract;
procedure SetOnClick(aValue: TOnMenuClick); virtual; stdcall; abstract;
end; |
|
TIMainMenu wird vom Applikations-Objekt zurückgeliefert. Von dort kann dann das Plug-In auf alle Menüpunkte zugreifen, eigene Menüpunkte und ganze Menüs einbauen, etc.
In der Applikation
Die Applikation bietet Klassen, welche die einzelnen Menüpunkte verwalten und die gewünschten Schnittstellen nach außen bieten. | Delphi-Quellcode: | zusammenfalten | markieren | 1
·
·
·
5
·
·
·
·
10
·
·
·
·
15
·
·
·
·
20
·
·
·
·
25
·
·
·
·
30
·
·
·
·
35
·
·
·
·
40
·
·
·
·
45
·
·
·
·
50
| TMainMenuImpl = class(TIMainMenu)
private
FMenuItem: TMenuItem;
FAppIntf: TApplicationImpl;
public
constructor Create(aAppIntf: TApplicationImpl; aMenuItem: TMenuItem);
// overrides
function GetMenuItems: TIMenuItems; override; stdcall;
function InsertMenuItem(aIndex: Integer; aCaption, aHint, aName: String;
aShortCut: Word; aTag: Integer; OnClick: TOnMenuClick): TIMenuItem;
override; stdcall;
end;
...
constructor TMainMenuImpl.Create(aAppIntf: TApplicationImpl; aMenuItem:
TMenuItem);
begin
inherited Create;
FAppIntf := aAppIntf;
FMenuItem := aMenuItem;
end;
function TMainMenuImpl.GetMenuItems: TIMenuItems;
begin
Result := TMenuItemsImpl.Create(FAppIntf, FMenuItem);
end;
function TMainMenuImpl.InsertMenuItem(aIndex: Integer; aCaption, aHint,
aName: String; aShortCut: Word; aTag: Integer;
OnClick: TOnMenuClick): TIMenuItem;
var
MI: TMenuItem;
PMI: TPluginMenuItem;
begin
MI := TMenuItem.Create(frmMain);
MI.Caption := aCaption;
MI.Hint := aHint;
MI.Name := aName;
MI.ShortCut := aShortCut;
MI.Tag := aTag;
MI.OnClick := nil;
FMenuItem.Insert(aIndex, MI);
PMI := TPluginMenuItem.Create(FAppIntf, MI);
PMI.OnMenuClick := OnClick;
FAppIntf.FPlugInMenus.Add(PMI);
Result := TMenuItemImpl.Create(FAppIntf, MI);
end; |
|
Dazu speichert sich der Menü-Wrapper eine Referenz auf das Applikationsobjekt (um diese an die einzelnen Wrapper der Menüpunkt durchzureichen) und eine Referenz auf das Menüitem, welches die Referenz auf den zu bearbeitenden Menüpunkt hält. Desweiteren fallen die folgenden Zeilen auf | Delphi-Quellcode: | markieren | PMI := TPluginMenuItem.Create(FAppIntf, MI);
PMI.OnMenuClick := OnClick;
FAppIntf.FPlugInMenus.Add(PMI); |
|
Da der Klick auf ein dynamisches Menüitem nicht automatisch durchgereicht werden soll (Sicherheitsaspekte) wird der Klick auf ein separat erstelltes Objekt gelenkt. Dieses Objekt stellt die interne Klick-Methode zur Verfügung | Delphi-Quellcode: | zusammenfalten | markieren | 1
·
·
·
5
·
·
·
·
10
·
12
| procedure TPluginMenuItem.OnClick(Sender: TObject);
var
TMII: TMenuItemImpl;
begin
TMII := TMenuItemImpl.Create(FAppIntf, FLinkedMenuItem);
try
if Assigned(FOnMenuClick) then
FOnMenuClick(TMII);
finally
TMII.Free;
end;
end; |
|
Wenn der Menüpunkt angeklickt wird, erstellt diese Methode einen Wrapper auf den Menüpunkt, ruft die OnClick Methode des Plug-Ins auf und zerstört anschließend das Wrapper-Objekt wieder. Damit wird dem Plug-In die Möglichkeit geboten auf Klick im Menü zu reagieren.
Die Plug-Ins (I)
Das erste Plug-In ist wieder ein Non-Sense Plug-In, dafür aber sehr einfach. Es erstellt im Hauptmenü einen neuen Menüpunkt und erstellt darunter drei Einträge. Wenn einer dieser Einträge ausgewählt wird, wird eine MessageBox angezeigt, welche den Namen des angeklickten Menüpunkt nennt. | Delphi-Quellcode: | markieren | procedure TPlugInObject01.OnMenuClick(Sender: TIMenuItem);
begin
Parent.ShowMessage(Format('"%s" was clicked', [Sender.GetCaption]));
end; |
|
Die Plug-Ins (II)
Das zweite Plug-In ist etwas sinnvoller. Es stellt zwei neue Menüpunkt im File Menü zur Verfügung. "Alle Dokumente speichern" und "Alle Dokumente schließen". Nach Ausführung teilt es dem User mit, ob die Anfrage erfolgreich durchgeführt wurde.
Die Plug-Ins (III)
Das dritte Plug-In ist ein wenig komplexer. Es ermöglicht dem User die ShortCuts sämtlicher Menüpunkte neu zu definieren! Eigentlich eine echt geile Funktion. Nur das Programm brauch die eigentlich nicht
Die Einstellungen werden in einer INI Datei im Verzeichnis, in welchem auch die DLL liegt, gespeichert. Dadurch kann das Plug-In die Einstellungen beim nächsten Programmstart auch wiederherstellen Dieses Beispiel zeigt auch, wie man ein VCL-Form in eine DLL einbinden kann - und gleich ist die 350 KB größer als die anderen 
Viel Spaß
Und nicht vergessen  Schaut in die About-Box, dort wird noch der Umgang mit der THeaderControl gezeigt 
...... |
| [ An diesen Beitrag wurden eine oder mehrere Dateien angehängt. Zum Herunterladen bitte anmelden. ] |
Jeder Mensch lebt praktisch in seiner eigenen, privaten Welt. Kommunikation bedeutet zwischen diesen Welten Brücken zu bauen.
CodeGear Associate Evangelist
Zuletzt bearbeitet von sakura am 16.05.2003, 15:09, insgesamt 1-mal bearbeitet. |
| |
|
|
|
| |
| Matheridon |
#5|Verfasst am: 14.11.2003, 11:21 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
Mitglied
Status: offline
Beiträge: 1
angemeldet: 14.11.2003
|
Hi,
kann es sein dass du in den kompilierten Programmen irgendetwas falsch gemacht hast? Bei mir werden nämlich keine DLLs geladen, es kommt auch keine Fehlermeldung... beide Programme sagen mir einfach nur dass keine DLLs geladen wurden (und ja, die DLLs sind im richtigen Verzeichnis *g*)
Gruß,
Matheridon |
|
| |
|
|
|
| |
| sakura |
#6|Verfasst am: 14.11.2003, 16:13 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
Super-Moderator
Alter: 33
Status: offline
Beiträge: 11.294
angemeldet: 10.06.2002
Wohnort: München
RAD-Studio 2007 Architect
|
Genau habe ich es jetzt nicht im Kopf, aber sofern ich mich erinnere, müssen die DLLs in der Registry angegeben werden - genaueres steht auf jeden Fall im obigen Text.
...... |
Jeder Mensch lebt praktisch in seiner eigenen, privaten Welt. Kommunikation bedeutet zwischen diesen Welten Brücken zu bauen.
CodeGear Associate Evangelist |
| |
|
|
|
| |
|
|
| |
| FriFra |
#8|Verfasst am: 19.01.2004, 02:03 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
Mitglied
Alter: 36
Status: offline
Beiträge: 1.327
angemeldet: 19.04.2003
Delphi 2005 Professional
|
Ich hab grosse Probleme bei der Umsetzung... Beide Beispiele laufen zwar bei mir, aber wenn ich den "Plugin-Code" in mein fertiges Projekt (ich hätte auch gern eine Plugin Schnittstelle) integriere, werde ich von "ungültigen Zeigeroperationen" bomardiert...
wenn ich Application.onexception abfange sehe ich zwar die Fehlermeldungen nicht mehr und es funktioniert auch alles, aber wo zum Teufel kommen diese Fehler her? |
Elektronische Bauelemente funktionieren mit Rauch. Kommt der Rauch raus, geht das Bauteil nicht mehr. |
| |
|
|
|
| |
| sakura |
#9|Verfasst am: 19.01.2004, 09:39 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
Super-Moderator
Alter: 33
Status: offline
Beiträge: 11.294
angemeldet: 10.06.2002
Wohnort: München
RAD-Studio 2007 Architect
|
Ohne Code schwer zu raten Aber bitte einen eigenen Thread für dieses Problem. Unter Umständen hast Du in einem der beiden Teile (Anwendung - PlugIn) vergessen ShareMem als erstes in die Projekt-Uses-Klausel aufzunehmen.
...... |
Jeder Mensch lebt praktisch in seiner eigenen, privaten Welt. Kommunikation bedeutet zwischen diesen Welten Brücken zu bauen.
CodeGear Associate Evangelist |
| |
|
|
|
| |
| nitschchedu |
#10|Verfasst am: 24.04.2006, 08:41 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
Mitglied
Status: offline
Beiträge: 301
angemeldet: 24.03.2006
Delphi 7 Professional
|
Ich habe auch noch ein problem! Ich habe das Gerüst wie oben benutzt und noch zusätzlich eine funktion reingemacht wo ich auf einen TForm zukreifen will, der Befehl Show geht, aber wenn ich nun TControlls verschieben will in meine Anwendung, bekomme ich den Fehler TFont kann nicht TFont zugewissen werden!
Wie kann ich das beheben? 
Ich kan euch auch mal den Code Posten. |
Zuletzt bearbeitet von nitschchedu am 24.04.2006, 08:57, insgesamt 1-mal bearbeitet. |
| |
|
|
|
| |
| FriFra |
#11|Verfasst am: 24.04.2006, 09:06 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
Mitglied
Alter: 36
Status: offline
Beiträge: 1.327
angemeldet: 19.04.2003
Delphi 2005 Professional
|
schau mal nach, ob die TFont's aus der selben unit kommen... Das Problem mit dem TFont hatten wir hier auch schonmal irgendwo |
Elektronische Bauelemente funktionieren mit Rauch. Kommt der Rauch raus, geht das Bauteil nicht mehr. |
| |
|
|
|
| |
| nitschchedu |
#12|Verfasst am: 24.04.2006, 09:34 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
Mitglied
Status: offline
Beiträge: 301
angemeldet: 24.03.2006
Delphi 7 Professional
|
Na das Problem ist das es nicht aus der Selben Unit kommt.
Ich habe eine Unit vom Hauptprogramm und eine Unit in der Dll.
Nun Create ich in der dLL das Form und versuche die Controlls ins Hauptprogramm zu laden, genau da passiert der Fehler.  |
|
| |
|
|
|
| |
| himitsu |
#13|Verfasst am: 24.04.2006, 09:45 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
sehr aktives Mitglied
Alter: 30
Status: offline
Beiträge: 13.875
angemeldet: 11.10.2003
Wohnort: Elbflorenz
Delphi 2010 Professional
|
Tja, dann kannst du es vergessen, solange du nur Delphi's MM benutzt.
Ließ dich mal  da etwas durch ^^ |
an alle schlaflosen Programmierer ... macht ein Upgrade, denn mit neuer Technik passiert sowas nicht > http://xkcd.com/571 
www.fnse.de/img.htm |
| |
|
|
|
| |
| xaromz |
#14|Verfasst am: 24.04.2006, 09:49 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
aktives Mitglied
Beiträge: 1.580
angemeldet: 18.03.2005
Delphi 2006 Enterprise
|
Hallo,
| nitschchedu hat folgendes geschrieben: | Na das Problem ist das es nicht aus der Selben Unit kommt.
Ich habe eine Unit vom Hauptprogramm und eine Unit in der Dll.
Nun Create ich in der dLL das Form und versuche die Controlls ins Hauptprogramm zu laden, genau da passiert der Fehler. |
Das sieht mir nach dem klassischen Problem aus, dass Du in beiden Projekten (HauptProgramm und DLL) die VCL einkompiliert hast. Leider hat jedes Programm seine eigene RTTI. Deshalb kann Hauptprogramm.TFont niemals DLL.TFont sein, auch wenn beide eigentlich die gleiche Klasse sind. Daher kommt auch der Fehler, TFont.Assign prüft, ob wirklich ein TFont übergeben wurde.
Die Lösung ist einfach: Packages verwenden.
Gruß
xaromz |
|
| |
|
|
|
| |
| nitschchedu |
#15|Verfasst am: 24.04.2006, 09:54 Titel: Re: PlugIns in eigenen Anwendungen |
|
|
|
|
Mitglied
Status: offline
Beiträge: 301
angemeldet: 24.03.2006
Delphi 7 Professional
|
Und wie sieht es mit Frames aus? Das ich das Frame aus der DLL im Hauptprogramm anzeigen lasse. Da wiedrum hatte ich auch das Problem!
Also wie ich es mache es kommt der Fehler  . Ansonsten versuche ich es mal mit PAckets. |
Zuletzt bearbeitet von nitschchedu am 24.04.2006, 09:57, insgesamt 1-mal bearbeitet. |
| |
|
|
|
|
|
|
| |
|
|
| |
 
  
|
|
| |
|
Du darfst keine Beiträge in dieses Forum schreiben.
Du darfst auf Beiträge in diesem Forum nicht antworten.
Du darfst Deine Beiträge in diesem Forum nicht bearbeiten.
Du darfst Deine Beiträge in diesem Forum nicht löschen.
Du darfst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten.
Du kannst Dateien in diesem Forum nicht herunterladen.
|
|
|
Site-Map
Suchen
Code-Library
Registrieren
Login
