Adresse eine Funktion / Prozedur ermitteln

[Neutral General]

Klar, aber das funktioniert nur wenn die Signatur der Methoden immer gleich ist.

Wenn du ne Methode hast in der ein Integer übergeben wird statt einem String oder mehrere Parameter dann stößt du damit schnell an Grenzen.

[taaktaak]

Moin, Moin,
mal die vermutlich geniale technische Lösung ausser Acht gelassen:

Ich habe (sofern ich die Aufgabenstellung richtig verstanden habe) Zweifel am Grundkonzept. Der Anwender soll im Freitext den Namen einer fest verdrahteten Func/Proc eingeben, die dann aufgerufen wird? Seltsam!

Da der "Befehlsvorrat" fest vorgegeben ist, wäre es doch viel effizienter wenn der Anwender aus dem Befehlsvorrat auswählen könnte. Also Listbox, Combobox - whatever. Das ist schneller, einfacher und schließt Fehler aus.

[BlueWonder]

@NeutralGeneral:
Nach etwas grübeln, versteh ich jetzt glaub was du meinst. Jetzt steig ich auch langsam dahinter, was der ASM-Code genau bewirkt. Muss ich zugeben, is ne clevere Sache. Bei mir hat es bisher diese Unterschiede so nich gegeben, deswegen reichte mir eine feste Signatur, wo eben nur jede Methode ihre spezielle Arbeit verrichtet. Dann möchte ich mich für meinen Post entschuldigen und den mal so als Alternative für simple Sachen stehen lassen.

@taaktaak:
Der Sinn dieser ganzen Sache kann sich über mehrere Bereiche Verteilen. Zum Beispiel kann in ein Programm eine Art Konsole eingebaut werden, in welcher der Benutzer Befehle eintippen kann, die dann ausgeführt werden. (wie zb. "clear" um den Inhalt zu löschen) Der Funktionsumfang könnte durchaus so groß werden, dass er in List-Boxen nicht mehr recht überschaubar wäre. Außerdem verstößt das gegen das Grundlayout einer Konsole.
Oder aber das Programm bekommt ein Objekt übergeben, von dem es die genaue Klassenbeschreibung nicht kennt. Wohl aber weiß oder mitgeteilt bekommt, dass dieses Objekt die Methode "bla" enthält und diese Aufzurufen ist.

[Neutral General]

Hi BlueWonder,

Brauchst dich nicht zu entschuldigen Hast mich ja nicht irgendwie angegriffen oder so

Gruß
Neutral General

[Vjay]

Hi, mal eine Frage dazu ob das prinzipiell möglich ist.

Ich habe schon lange mal vorgehabt (ist halt immer an keiner Zeit oder Faulheit gescheitert) ein Programm zu schreiben, welches auf Plugins und Events basiert und deren SInn es ist diese zusammen zu bringen. Ein Beispiel, es gibt eine DLL, welche Hooking benutzt um den Fenstermanager zu überwachen bzw. Events zu abonieren in der DLL, andererseits stellt sie Funktionen bereit um z.B. Mausklicks oder Tastatureingaben zu simulieren (diese bräuchten z.B. ein Handle als Ausgangsbasis). Nun hat man z.B. dieses Windowplugin, ein http Plugin, ein Comportplugin, ein Timerplugin, ein Systemplugin, ein Dateiplugin, etc pp.

Jetzt habe ich als Benutzer der Anwendung das spontane Problem, dass ich als Beispiel auf einen langen Download warten muss und ins Bett möchte. Also öffne ich schnell das Einstellungsfenster des Programms, ziehe ein Event vom Windowplugin hinein, lege fest, ich möchte Informiert werden wenn ein Fenster geschlossen wird, lege als Filter die Caption fest, ziehe das Herunterfahren Symbol vom Systemplugin hinein, sage herunterfahren + ausschalten und verknüpfe diese beiden Symbole und fertig.

So, ewig lange ausgeholt, tut mir leid. Das Problem an der Geschichte ist bisher, dass einige Funktionen ja Übergabeparameter erwarten/zurückliefern, wie ein Fensterhandle z.B. Diese müsste man ja quasi mitverknüpfen. Als Beispiel WindowEventFensterGeöffnet(HWND)->SimuliereMausklickAufFenster(HWND) oder WindEventFensterGeöffnet(HWND)->FindWindowObjekt(HWND)->SimuliereMausklickAufFenster(HWND) um woanders hin zu klicken.

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.

[uligerhardt]

Zitat von Fussball-Robby:

Naja, dann mach ich mich mal ans if..then..else tippen.. Wenn jemand noch eine Idee hat, immer her damit.

Ich würde statt einer if-then-else-Wüste eine TStringList o.ä. nehmen, bei der du die Prozedurzeiger in .Objects reinstopfst.

HTH,
Uli.

[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)