Adresse eine Funktion / Prozedur ermitteln

[Neutral General]

Zitat von Vjay:

Ist es irgendwie möglich Prozeduren währned der Laufzeit in diese Richtung zu analysieren welche Parameter sie erwarten? Es müssten ja (automatisiert) Zuweisungen und evtl sogar impliziert Typecasts erfolgen. Ich hatte damals(5 Jahre etwa) mit Variants mal gestartet, aber abgebrochen, da es in unendliche Komplexität ausgeartet ist.

Hi,

ja das dürfte mit der erweiterten RTTI möglich sein. Musst du mal im Forum nach suchen. Naja wenn du die Parameter herausgefunden hast, musst du die Procedure ja auch irgendwie aufrufen. Das ginge ja eventuell mit meiner Methode aber ich bräuchte glaube ich mehr Infos wie das ganze ablaufen soll...

[Vjay]

Hmh stimmt, das könnte ansich schon funktionieren.
Erschwerend wäre nur vielleicht, dass alles dezentral über DLLs verteilt ist.

Nunja ich hatte mir das so gedacht, wie im obigen Beispiel, dass man in der Window-DLL ein Event registriert und als Empfängerfunktion gleich die Adresse der SystemDLL-Herunterfahren Funktion hinterlegt. Ich bin kein Fan von Parsern oder sonstigen Geraffel. So hätte man maximale Performance, also auch für Events die sehr sehr oft kommen. Nur irgendwo müsste da ein intelligentes Stück Code dazwischen, welches erkennt, dass die eine funktion ein outHWND liefert und die andere in diesem Fall einen inHWND benötigt und dann deinen Code verwendet und die Funktion richtig aufruft.

Gedankengang der Unternehmung war es im Grunde, die kleinen Programme, die wir Programmierer für kleine Aufgaben schreiben überflüssig zu machen und es damit auch der breiten Masse zugänglich zu machen.
Wie wenn man mal eben schnell nen Portforwarding braucht, Einstellungen öffnen, NetzwerkDLL Server, Client IP + Ports rein, Linie ziehen - fertig, evtl. LogDatei noch dazwischenhängen.

[MSSSSM]

Tut mir leid, dass ch diesen Thread wieder ausgrabe, aber müssen die Prozeduren class procedure s sein?
Weil ich wollte nämlich einen XUL-Parseer bauen, und da sollten sich die Funktionen in die Form integrieren lassen.

(Link: XUL-Engine )

[Neutral General]

Nein, sie müssen keine Class-proceduren sein, aber sie müssen halt published sein, oder bei MethodInfo ON zumindest public (Soweit ich weiß, aber ich hab grad kein Delphi und bin mir nicht sicher)

[Cyf]

Also - wenn man mal außer acht lässt, dass das asm-Konstrukt viel ästhetischer ist - was spricht hier eigentlich dagegen, mit den Prozedurnamen einen enum-Typ zu erstellen und beim Programmstart alle möglichen Einsprungspunkte der Prozeduren in ein Array zu packen? Für die Überprüfung bräuchte man dann noch ein zweites Array in dem die vom Benutzer zu benutzenden Befehle (also die Funktionsnamen), als Textstrings an den Indexen die dem enum-Typ entsprechen geparkt sind und schon muss man nur den übereinstimmenden Index suchen und springt dann an den Einsprungspunkt mit dem selben Index. Das hat die Vorteile, dass man bestimmen kann welche Funktionen zugänglich sein sollen (vom Benutzer) und welche nicht, es einfach zu handhaben ist und man die Funktionen ggf. intern anders nennen kann, als sie später von außen heißen sollen. Der einzige Nachteil der mir einfällt, sind 2 Zeilen Typarbeit und vielleicht 20 Byte Speicherverbrauch pro Funktion.
Ansonsten lagert man das ganze eben in Dlls aus, da kann man dann direkt nach dem Namen suchen und hängt die ggf. als Ressource an, wenn man wirklich eine umfangreiche Funktionsmenge bereitstellen will, macht das ohne hin Sinn, da der User wohl kaum immer alle brauchen wird.
Entschuldigt wenn das etwas verwirrend geschrieben ist, ist bisschen spät und ich bin jetzt weg.

[himitsu]

man kann auch in einer EXE eine Funktion/Prozedur als External definieren (halt so wie bei einer DLL)

ich weiß jetzt nicht, wie leicht es dann ist die Adressen umzurechnen (falls man due Funktion direkt in der EXE aufrufen will), aber die EXE läßt sich notfalls wie eine DLL einbinden (mit ein paar kleinen Anpassungen)