DLL Initialisierung

Antworten
abacom
Site Admin
Beiträge: 3312
Registriert: Dienstag 23. September 2008, 10:54
Kontaktdaten:

DLL Initialisierung

Beitrag von abacom » Dienstag 14. Oktober 2008, 12:41

ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 03.03.2008 18:29 Titel: DLL Initialisierung

--------------------------------------------------------------------------------

Hallo ABACOM Team,

das Vorhalten von lokalen Informationen im PUSER-Bereich ist im Prinzip ja eine feine Sache für eigene DLLs.

Wär es nicht schön, wenn man unmittelbar nach dem Laden einer DLL den Pointer darauf bekommen könnte? Etwa im Rahmen eines "DLL-Initialisierungs-Calls", natürlich nur, wenn die DLL eine solche Routine auch exportiert, um Rückwärtskompatibilität zu gewährleisten?

Für mich würde das eine ganze Reihe von Problemen lösen, die ich derzeit mit "eigenen" Komponenten für PL noch habe.

MfG
Ulrich Bangert

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 04.03.2008 10:24 Titel:

--------------------------------------------------------------------------------

Konkreter Fall? Warum nicht "SimStart"?

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 04.03.2008 11:10 Titel:

--------------------------------------------------------------------------------

Hallo Abacom-Team,

weil es damit z.B. möglich wäre, die Zahl und die Beschriftung der Pins des Bauteils DYNAMISCH aus einer Konfiguration zu lesen, bevor sonst was passiert.

Die Funktionen NumInputs/NumOutputs/InputName/OutputName müssen zum Zeichnen des Blocks ja (leider!) schon vor SimStart aufgerufen werden.

Des weiteren stelle ich mir vor, dass eine DLL in der Lage sein sollte, Initialisierungen lokaler Variablen u.s.w. an einer zentralen Stelle zu erledigen. Der eigentliche begin-end Block der DLL eignet sich dafür nicht, weil man da nicht weiss in welcher Instanz die DLL geladen wurde.

Ich werde gleich zum Thema "Lokale Variablen in DLLs" noch einen neuen Thread starten und da meine Lösung für den Umgang mit lokalen Variablen beschreiben. Eigentlich fehlt dann zum Glücklichsein nur noch die frühzeitige Information über den PUser^[DLLIndex].

MfG
Ulrich Bangert

[/quote]

Nach oben


Mike D



Anmeldungsdatum: 03.07.2006
Beiträge: 236

Verfasst am: 04.03.2008 11:13 Titel:

--------------------------------------------------------------------------------

genau das hatte ich Abacom vor einem Jahr schonmal vorgeschlagen.
Das kann ich nur nochmal unterstützen.

Mike

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 11.03.2008 14:41 Titel:

--------------------------------------------------------------------------------

Tja,

irgendwie ist das unbefriedigend, wenn man nicht weiss, ob sich in dieser Hinsicht was tun wird oder nicht.

Ich denke, KEINER kann sich wirklich bei ABACOM in irgendeiner Form beschweren. Selbst wenn man ProfiLab nicht wirklich für irgendetwas ernsthaftes einsetzen sollte, so ist allein der Spass, mit dem Programm herumzuspielen, sicher mehr als seinen Kaufpreis wert. Insofern werde ich es sicherlich nie bedauern, ProfiLab erworben zu haben. Soviel zu meinem positiven Grundbekenntnis zu ProfiLab.

Auf der anderen Seite ist es so, dass gerade ein Baukastensystem, zumal, wenn es mit Erweiterungsmöglichkeiten des Baukastens durch den Anwender ausgestattet ist, die Frage, ob ein bestimmtes Problem mit dem Baukasten zu lösen ist oder nicht, nicht gerade einfach macht, weil man als Anwender keinen perfekten Überblick über die Eigenschaften aller relevanten Baukasten-Komponenten hat.

Bislang ist es mir mehrfach schon so gegangen, dass ich reale (durchaus auch kommerzielle) Anwendungen für ProfiLab-Applikationen gesehen habe. Leider ist die Umsetzung bislang ein 99%-Erlebnis gewesen, weil sich (nachdem ich selbst schon einige Zeit in die Realisierung gesteckt hatte) am Ende immer herausgestellt hat, das ein winziges Quentschen Software zum 100%-Erfolg fehlt. Dummerweise hat dieses kleine Quentschen zumeist drei unangenehme Eiegenschaften:

a) es mit den Mitteln des Systems (also dem Baukasten) an sich nicht erstellbar

b) Es ist (wie in diesem Fall) selbst mit DLLs des Anwenders nicht erstellbar

c) ABACOM kann es nicht realisieren/will es nicht realisieren/interessiert sich nicht dafür

Die Situation ist keineswegs typisch für ProfiLab. Unter dem gleichen Problem leiden alle Baukasten-Systeme, auch richtig vornehme und teure wie LABVIEW.

Ich will für die Situation ein Beispiel geben: Ich habe in den letzten 20 Jahren als Softwareentwickler für Datenerfassung im Bereich Immissions-Schutz/Emissionsschutz so an die 50 seriellen Protokolle unterschiedlicher Hersteller kennengelernt. Die meisten davon sind so beschaffen, dass man bei den notwendigen String- und Bitfriemeleien auf Baukasten-Systeme dankend verzichtet und die notwendigen Aktionen lieber selber in einer textbasierten Programmiersprache in Angriff nimmt. Solche Geschichten wären die IDEALEN Kandidaten für eigene DLLs, wenn, ja wenn einige Voraussetzungen gegeben sind. Diese wären:

a) Konfigurierbarkeit von lokalen Parametern. Diese Forderung wird von ProfiLab unterstützt und wie man es macht, ist in einem fixfertigen Beispiel (Counter-DLL) beschrieben.

b) Überschreibfreie lokale Variablen. Hier ist der ProfiLab-Ansatz mit seinem PUser^ zwar besser als gar nichts, aber nicht der wahre Jakob. In einem anderen Thread habe ich dafür eine brauchbare Lösung beschrieben.

c) Das Vorhalten von Parametern über das Applikationsende hinaus. Wenn das Problem b) zufriedenstellend gelöst ist, so offenbart sich dadurch eine Möglichkeit, auch komplexe Objekte z.B. für die Verwaltung von Windows-Ini-Dateien in DLLs zu benutzen, ohne dass sich dadurch die DLLS in die Quere kommen würden. Diese Objekte wiederum speichern/lesen in den Ini-Dateien die Eigenschaften und Werte ECHTER lokaler Variablen.

Wie ich schon schrieb: 99% der Arbeit sind schon getan. Wenn es eine DLL schon schafft, wesentliche Dinge ihrer Konfiguration wie Zahl der notwendigen Eingangs- und Ausgangspins aus einer Konfigurationsdatei zu lesen und entsprechend umzusetzen, muß denn ein solch wunderbares Konstrukt (als das ich es wirklich einschätze) daran scheitern, dass man ihr keine Gelegenheit gibt, das auch wirklich zu tun, BEVOR ihr Symbol gezeichnet wird?

Ich würde als Anwender ja durchaus entsprechende Arbeit in so eine Möglichkeit reinstecken, wenn ich nur wüsste, wie. Ich würde sicherlich hier nicht als Bittsteller auftreten, wenn ich auch nur im ANsatz sehen könnte, wie dieses Problem von mir OHNE die Hilfe von ABACOM gelöst werden kann.

Grüße aus der Nachbarschaft
Ulrich Bangert

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 11.03.2008 22:28 Titel:

--------------------------------------------------------------------------------

Zitat:
ABACOM kann es nicht realisieren/will es nicht realisieren/interessiert sich nicht dafür


Unangemessen und FALSCH! Aber hier herscht ja Meinungsfreiheit.

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 12.03.2008 07:44 Titel:

--------------------------------------------------------------------------------

Hallo ABACOM-Team,

es liegt mir überhaupt nichts daran, falsche oder unangemessene Formulierungen zu benutzen! Und ich hatte gedacht, meine positive Grundhaltung deutlich genug zum Ausdruck gebracht zu haben.

Ich bitte deswegen höflichst um Aufklärung darüber, WELCHE Formulierung denn angemessen gewesen wäre, den Zustand zu beschreiben, wenn irgendwie gar nichts in dieser Sache passiert?

Es ist ja nicht wirklich schlimm, wenn etwas nicht funktioniert, das hakt man dann ab und macht es eben anders. Insofern wäre selbst die Aussage "Nein, machen wir nicht" etwas äußerst befreiendes, weil es Klarheit schaffen würde.

Mit Grüßen aus der Nachbarschaft
Ulrich Bangert

Nach oben


LED



Anmeldungsdatum: 15.02.2008
Beiträge: 54

Verfasst am: 12.03.2008 12:58 Titel:

--------------------------------------------------------------------------------

Ganz allgemein:

Der Support von Abacom ist hier wirklich hervorragend. Jedoch finde ich eine einzeilige Antwort auf solch ein langes Posting etwas knapp. Selbstverständlich kann man als Abacom sich nicht nur mit dem Forum beschäftigen. Aber wie von Uliban richtig angesprochen, die User brauchen Klarheit. Es bringt nichts auf irgendwelche Features zu hoffen die nie kommen werden. Eine winzige Kleinigkeit kann entscheidend sein, ob ein Projekt mit PL verwirklicht werden kann oder nicht. ( Wenn nicht mit PL mit was denn sonst ?

Welche Möglichkeiten gäbe es denn gegen Bezahlung Features zu bestellen, also bezahlte Erweiterungen?

Nach oben


Wolle



Anmeldungsdatum: 30.09.2007
Beiträge: 1
Wohnort: Lohmar
Verfasst am: 13.03.2008 22:09 Titel:

--------------------------------------------------------------------------------

Hallo,
ich finde es schade das sich hier ABACOM nicht dem Problem
stellt und sich schweigend zurück zieht...mehr oder weniger.
Weiter so ulliban

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 14.03.2008 20:37 Titel:

--------------------------------------------------------------------------------

1.) Anregungen nehmen wir stets gerne auf. Das hat sich in der Vergangenheit wohl bewahrheitet.
2.) Das heisst nicht, dass jedes "Wünsch Dir was" immer zeitnah umgesetzt werden kann.
3.) Das aber heisst widerum nicht, das wir nicht wollen, können oder es uns egal ist.
4.) Die Anregungen und Neuerungen zu ProfiLab sind so zahlreich, dass wir Prioritäten setzen müssen. Klar das jeder seine Idee am liebsten gestern realisiert haben möchte. Geht aber leider nicht. Da hilft auch ein noch so häufiges und nachdrückliches Posten nicht.
5.) Möchten wir hier keine Romane schreiben, sondern nach Kräften Hilfestellungen geben.
6.) Sind unsere Updates ein freiwillger Service.
7.) Ist ein Jahr schneller um als man denkt und es hat eine ganze Reihe neuer Funktionen für lau gegeben, z.B. Modbus, etc.
8.) Wollte ich mich ja kurz fassen und lieber Programme schreiben.
9.) Kann die Antwort nicht einfachen "machen wir" oder "machen wir nicht" lauten, sondern "werden wir versuchen zu machen" ...wenn es technisch geht ...wenn Zeit dafür da ist ... wenn es sich lohnt ... wenn nichts dazwischen kommt ... wenn ... Sorry!

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 15.03.2008 15:00 Titel:

--------------------------------------------------------------------------------

Zitat:
9.) Kann die Antwort nicht einfachen "machen wir" oder "machen wir nicht" lauten, sondern "werden wir versuchen zu machen" ...wenn es technisch geht ...wenn Zeit dafür da ist ... wenn es sich lohnt ... wenn nichts dazwischen kommt ... wenn ... Sorry!


Genau DAS geht eigentlich nicht! Die Anwender von ProfiLab mögen das Programm ja zu sehr unterschiedlichen Zwecken einsetzen, darunter auch solchen, die ich als "verspielt" bezeichnen würde. Trotzdem sind dies doch alles keine Spielkinder, die man damit vertrösten kann, dass Ihnen Mutti (vielleicht) irgendwann mal ein neues Förmchen für den Sandkasten kauft, sondern KUNDEN. Und ich denke, in DIESER Funktion hat jeder, der das Programm erworben hat, eine präzise Antwort und kein Rumeiern verdient.

Ich lebe seit nun mehr als 25 Jahren von PC-Programmierung und Hardware-Entwicklung im Mikrocontroller-Bereich und bilde mir deswegen ein, den Standpunkt von ABACOM durchaus auch von der Herstellerseite aus beurteilen zu können. Dass man da auch gewissen Restriktionen unterliegt und nicht jeder Idee nachgehen kann, dass weiss ich selber auch sehr genau!

Ich möchte aber noch einmal darauf hinweisen, dass ich ja nicht stundenlange kostenlose Entwicklungsarbeit einfordere, und möchte den Umfang von dem, was ich mir erhoffe, noch einmal darlegen:

Durch einige einfache Experimente mit zusätzlich exportierten Prozeduren/Funktionen bzw. Weglassen vorhandener wie "Configure" kann man einfach verifizieren, dass

a) ProfiLab zusätzliche exportierte Prozeduren NICHT automatisch erkennt

b) ProfiLab erkennt, wenn eine der Standard-Prozeduren wie Configure NICHT exportiert wird.

Zusammen mit der Tatsache, dass DLLs in Profilab dynamisch geladen werden, muss das dahinterstehende Programmierkonstrukt am Beispiel der Configure-Prozedur mehr oder weniger so ähnlich aussehen wie (Dass Profilab in Delphi geschrieben ist, habe ich ja mal von Euch gehört):

Code:
type
TConfigure = Procedure(PUser: PDLLParams);

var
Configure : TConfigure;
LibraryHandle = THandle;

begin;
LibraryHandle:=LoadLibrary(DLLName)
If LibraryHandle<>0 then
begin;
@Configure:=GetProcAddress(DLLName, 'Configure');
if @Configure<>Nil then
begin;
// Tu was, z.B. addiere den String 'Configure' zu der Listbox der exportierten Prozeduren
end;
end;
..
..
end;


Worum ich nun bitte ist, das ganze um einige wenige Zeilen zu erweitern:

Code:
type
TConfigure = Procedure(PUser: PDLLParams);
TDllInit = Procedure(PUser: PDLLParams); // 1. zusätzliche Zeile

var
Configure : TConfigure;
DllInit : TDllInit; // 2. zusätzliche Zeile
LibraryHandle = THandle;

begin;
LibraryHandle:=LoadLibrary(DLLName)
If LibraryHandle<>0 then
begin;
@Configure:=GetProcAddress(DLLName, 'Configure');
if @Configure<>Nil then
begin;
// Tu was, z.B. addiere den String 'Configure' zu der Listbox der exportierten Prozeduren
end;
@DllInit:=GetProcAddress(DLLName, 'DllInit'); // Zusätzliche Zeilen 3-8
if @DllInit<>Nil then
begin;
// Tu was, z.B. addiere den String 'DllInit' zu der Listbox der exportierten Prozeduren
DLLInit(PUser);
end;
end;
..
..
end;


Aus meinem Empfinden heraus ist diese (rückwärtskompatible) Veränderung doch etwas, was im durchaus im überschaubaren Rahmen bleibt!

Wenns wirklich zu viel Arbeit ist: Ich komme gerne aus Groß Ippener in Ganderkesee vorbei (Google rechnet eine Strecke von 12,5 km und eine Fahrzeit von 18 Minuten) und tippe das in Eurer Anwesenheit nackt (=Kein Know-How-Klau möglich) ein!

Mit Grüßen aus der Nachbarschaft
Ulrich Bangert

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 08.04.2008 12:34 Titel:

--------------------------------------------------------------------------------

Hallo Herr Bangert,

ich habe im heutigen Update einmal probeweise und undokumentiert die Prozedur

Code:
Procedure InitValues(POutput,PUser: PDLLParams);

bzw.

Code:
void _stdcall CInitValues(double *POutput, double *PUser)


eingeführt. (Wird in der Liste der importierten Funktionen z.Zt. noch nicht angezeigt, sollte aber gehen.) Wenn´s funktioniert liefern Sie ja sicher noch die dreisprachige Dokumentation, oder

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 10.04.2008 09:39 Titel:

--------------------------------------------------------------------------------

Hallo Abacom-Team,

Zitat:
Wenn´s funktioniert liefern Sie ja sicher noch die dreisprachige Dokumentation, oder


Ganz egal ob sich hinter Ihrem Spruch nun triefende Ironie oder unerfüllte Hoffnung verbirgt: Wenn das funktioniert, dann WERDE ich mich entsprechend engagieren.

Mit DREiSPRACHIG bin ich überfordert, weil ich vor vielen Jahrzehnten Französisch zugunsten von Physik abgewählt habe, aber ZWEISPRACHIG bekomme ich sicher hin! Es sei denn, Sie würden Latein als dritte Sprache akzeptieren?

Nun noch mal ernsthaft: Ich begrüße es (wie sicher einige andere Anwender auch), dass Sie diese Möglichkeit geschaffen haben. Das ganz ernste Angebot, sich an Ihrem Entwicklungsaufwand zu beteiligen, haben Sie nicht nur von mir sondern auch von einigen anderen Forum-Mitgliedern vorliegen. Eigentlich gilt es nur, dafür ein vernünftiges Modell zu finden! Wenns in diesem Fall die Doku sein sollte, so ist das eben so!

Grüße aus der Nachbarschaft
Ulrich Bangert

P.S.
Werde erst am Wochenende zum Funktionstest kommen

Nach oben


abacom
Site Admin


Anmeldungsdatum: 30.06.2006
Beiträge: 898

Verfasst am: 10.04.2008 14:37 Titel:

--------------------------------------------------------------------------------

Ich wollte nur verdeutlichen, dass es mit drei Zeilen Programm-Code nicht getan ist. Der Aufwand eine Funktion zu erklären ist meist erheblich höher als die Funktion selbst.

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 11.04.2008 05:54 Titel:

--------------------------------------------------------------------------------

Umso besser! Das übernehme ich dann in diesem Fall!

Grüße aus der Nachbarschaft
Ulrich Bangert

---------------------------------------------------------------------------------

ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 06.05.2008 08:29 Titel:

--------------------------------------------------------------------------------

Hallo Abacom-Team,

ich bin in den letzten Wochen inklusive der Wochenenden so mit Arbeit zu gewesen, dass ich nicht zu einem Test gekommen bin. Entschuldigung dafür.

Ich habe nun heute ein paar Tests gemacht und dabei gefunden, dass die InitValues-Prozedur durchaus aufgerufen wird (auch wenn sie nicht in der Liste der importierten Prozeduren auftaucht), allerdings zu einem Zeitpunkt, der nicht das erlaubt, was ich eigentlich meine:

Die DLL soll (außer anderen Initialisierungen) in der Lage sein, die Zahl ihrer Eingänge und der Ausgänge aus einer Konfigurationsatei zu lesen und ihr graphisches Symbol soll dann auch richtig dargestellt werden. So, wie es gegenwärtig implementiert ist, wird InitValues NACH dem Zeichnen aufgerufen.

Da die Funktionen NumInputs, NumOutputs, InputName und OutputName OHNE Verweis auf PUSER aufgerufen werden (und sich das aus Gründen der Rückwärtskompatibilität vermutlich auch nicht ändern wird), wird es ohnehin schwierig genug sein, die Informationen, die sich die DLL im Rahmen von InitValues beschaffen konnte, zu dem Zeitpunkt herüber zu retten, zu dem DIESE Funktionen aufgerufen werden. Ohne Verweis auf PUSER wird man wohl globale Variablen benutzen müssen mit den bekannten Einschränkungen.

Meine Ideen werden daher wohl überhaupt nur dann funktionieren können, wenn für jede Instanz der DLL die Aufrufreihenfolge

1) InitValues
2) NumInputs/NumOutputs
3) Input/OutputName
4) Zeichnen

eingehalten wird. Nur dann ist gewährleistet, dass in den globalen Variablen die Werte "überleben" bevor sie von einer neuen Instanz überschrieben werden.

Um nochmals zu sagen, wo ich den Sinn sehe: Ich habe hier einen hübschen Formelinterpreter, dessen Möglichkeiten über das, was in PL mit "Formel universell" angeboten wird, deutlich hinausgeht. Der schreit förmlich danach, in eine DLL umgesetzt zu werden. Das ganze scheitert aber daran, dass die DLL eben KEINE vergleichbare Speicherung der Konfiguration zur Verfügung steht, wie das bei der Zahl der Eingänge in "Formel universell" der Fall ist.

Grüße aus der Nachbarschaft

Ulrich Bangert

Nach oben


Mike D



Anmeldungsdatum: 03.07.2006
Beiträge: 236

Verfasst am: 06.05.2008 13:08 Titel:

--------------------------------------------------------------------------------

mir erschließt sich der Sinn von InitValues nach wie vor nicht.

Ich plädiere für die Einführung von:
Function NumInputsEx(PUser: PDLLParams): Byte;
Function NumOutputsEx(PUser: PDLLParams): Byte;
Function InputNameEx(Channel: Byte, PUser: PDLLParams): ShortString;
Function OutputNameEx(Channel: Byte, PUser: PDLLParams): ShortString;

Mike

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 07.05.2008 05:34 Titel:

--------------------------------------------------------------------------------

Ja natürlich,

DAS wäre wirklich das "volle Programm"! Aber da wiederum kann ich Abacom verstehen, wenn sie das nicht machen möchten in Hinblick auf diejenigen, die ihre DLLS schon geschrieben haben.

Ulrich Bangert

Nach oben


Mike D



Anmeldungsdatum: 03.07.2006
Beiträge: 236

Verfasst am: 07.05.2008 10:29 Titel:

--------------------------------------------------------------------------------

wieso, das das geht hat ABACOM mit calculateEX doch schon bewiesen.

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 08.05.2008 05:42 Titel:

--------------------------------------------------------------------------------

@MikeD:

CalculateEx ist doch genau wie InitValues eine Prozedur gewesen, die ZUSÄTZLICH zum vorhandenen Leistungsumfang kam und insofern niemand berührt hat, der sie eben (vorher) nicht benutzt hat.

In diesem Sinne würde ich die Einführung von CalculateEx und InitValues als "Rückwärtskompatibel" bezeichnen. Die von Dir vorgeschlagene Änderung hätte hingegen zur Folge, dass alle vorhandnenen DLLS umgeschrieben werden müssten, um Aufrufkompatibel zu werden. Oder sehe ich da was falsch?

Grüße
Ulrich

P.S.
Unabhängig von diesem Einwand halte ich Deinen Vorschlag immer noch für den vernünftigsten!

Nach oben


Mike D



Anmeldungsdatum: 03.07.2006
Beiträge: 236

Verfasst am: 08.05.2008 06:23 Titel:

--------------------------------------------------------------------------------

Ja, das siehst du falsch, denn alle Prozeduren mit Ex am Ende sind zusätzlich zu den bestehenden.
Je nach dem welche du benutzt und in der DLL als öffentlich deklarierst weiss PL welche es mit welchen Parametern aufrufen muss.

Mike

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 09.05.2008 05:37 Titel:

--------------------------------------------------------------------------------

@MikeD:

Ich lerne ja gerne noch was dazu: Mir war bewußt, dass PL aus einem endlichen Pool von Prozedur- und Funkionsnamen prüft, welche von der DLL exportiert werden. Das mache ich mit meinen eigenen Delphi-Wrappern für mit anderen Entwicklungsumgebungen geschriebene DLLs genauso, wenn ich sie dynamisch lade.

Aus meiner Kenntnis heraus lassen sich aber die benötigten Parameter zum Aufruf so NICHT ermitteln sondern müssen a priori bekannt sein. Aber wenn es anders sein sollte: Bitte um Aufklärung!

Grüße
Ulrich Bangert

Nach oben


ulliban



Anmeldungsdatum: 09.08.2007
Beiträge: 22
Wohnort: Gross Ippener
Verfasst am: 09.05.2008 05:41 Titel:

--------------------------------------------------------------------------------

@MikeD:

Sorry, bitte meine beiden letzten Mails vergessen! Ich hatte schlichtweg übersehen, dass Du in Deinem Vorschlag auch alles als "Ex" gekennzeichnet hattest. Na klar, das wäre natürlich rückwärtskpompatibel! Aber dürfen wir auf sowas hoffen?

Grüße
Ulrich Bnagert
ABACOM support

Antworten

Zurück zu „DLL-Programmierung“