Interfaces über Modulgrenzen implementieren

[DGL-luke]

Hallo,

ich schreibe gerade eine größere Anwendung mit umfangreichem Plugin-System. Ich wüsse jetzt gern, ob ich über die Modulgrenzen, d.h. innerhalb einer DLL, ein Plugin implementieren und das ans Hauptmodul liefern kann.

Also z.B. so:

Delphi-Quellcode:

type
  IMyInterface = interface
    function MyFUnction: string;
  end;

Delphi-Quellcode:

//DLL-Code
type
  TMyPlugin = class(TInterfacedObject, IMyInterface)
    function MyFunction: string;
  end;

function GetPlugin: IMyInterface; stdcall; export;
begin
  Result := MyPlugin;
end;

Delphi-Quellcode:

//EXE-Code
modh := loadlibrary('myplugin.dll');
GetPlugInProc := GetProcAddress(modh, 'GetPlugIn');
PluginIntf := GetPluginProc;

Showmessage(PluginIntf.MyFunction);

Gibts da irgendwelche Hindernisse?

[phXql]

Musst halt mit den Strings aufpassen, entweder nur PCHar benutzen oder diese eine komische Unit einbinden (Name entfallen :/)

[DGL-luke]

Ja, SharedMem ^^
Aber da schlägt ja wieder der Borland-MM zu. Das will ich eigentlich verhindern (Hab dazu schon n Thread aufgemacht ;-) )

[arbu man]

Dann nim doch den Type WideString imho kann man dem Benutzen :)

[Elvis]

Zitat:

Zitat von DGL-luke

Ja, SharedMem ^^
Aber da schlägt ja wieder der Borland-MM zu. Das will ich eigentlich verhindern (Hab dazu schon n Thread aufgemacht ;-) )

ShareMem oder FastMM wären eine Möglichkeit. Aber wesentlich besser sind WideStrings.
Nicht nur weil sie nicht Delphi-spezifisch sind, sondern wohl auch weil im Jahre 2007 AnsiStrings einfach nur noch jämmerlich yestercentury sind.
Solange du irgendwelche dinge darin packst, die keinerlei regionalen Kontext haben, mag das noch Sinn machen AnsiStrings zu nehmen, aber warum sollte man einem Russen, Koreaner, Japaner, Franzosen, [irgendeine Sprache != deiner eigenen] aufzwingen, in für ihn komisch aussehenden Zeichen zu tippen?
Unicode ist also im Zweifelsfall sowieso vorzuziehen, auch wenn es nur das uralte UCS2 vom WideString ist.

[DGL-luke]

Widestrings beinhalten also weniger Compiler-Magic und laufen deswegen über Modulgrenzen?

Bitte sag mir doch mehr, und nicht immer nur so kleine Häppchen :cry:
(Du willst mir nicht zufällig n Buch andrehen? :mrgreen: )

EDIT: Widestrings wären mir natürlich auch recht. Ich würd halt dann, bis das Programm komplett auf Unicode umgestellt wird (was im Moment NICHT geplant ist, vielleicht mit der Delphi-Version, die ne Unicode-VCL mitbringt) das aktuelle Codepage-ASCII reinpacken...

[Elvis]

Zitat:

Zitat von DGL-luke

Widestrings beinhalten also weniger Compiler-Magic und laufen deswegen über Modulgrenzen?

WideString ist ein BSTR, also ein Typ, den Windows selbst kennt.
Es ist auch der String, den man in COM benutzt (weshalb er in delphi gerne OleString genannt wird).

Zitat:

Bitte sag mir doch mehr, und nicht immer nur so kleine Häppchen :cry:

Kleine Häppchen und diffus eingestreute Zusatzinfos machen aber mehr Spass. :-P

Zitat:

(Du willst mir nicht zufällig n Buch andrehen? :mrgreen: )

Ich halte nichts von Büchern. Fachbücher sind was für Faulenzer und Bergaufbremser.

Zitat:

EDIT: Widestrings wären mir natürlich auch recht. Ich würd halt dann, bis das Programm komplett auf Unicode umgestellt wird (was im Moment NICHT geplant ist, vielleicht mit der Delphi-Version, die ne Unicode-VCL mitbringt) das aktuelle Codepage-ASCII reinpacken.

Damit wäre wenigstens deine öffentliche API für die PlugIns stabil, auch wenn du in der App erst dann Unicode haben wirst, bis du entweder auf Delphi2063 wartest, oder TNT benutzt.

[DGL-luke]

Okay, cool, dann bitte nur noch den anderen Thread beantworten :)