Tach zusammen!

Erstmal muß ich sagen, daß ich zwar nicht unbedingt ein Newbee bin, aber ich habe jetzt sehr lange nichts mehr mit Delphi gemacht. Ich kenne den Syntax und die Entwicklungsumgebung ganz gut (bin aber nicht viel weiter mangels Zeit gekommen ), weiß aber meistens nicht wozu die Sachen gut sind. Außerdem glaube ich, daß ich ein paar Verständisprobleme mit grundsätzlichen Computerdingen habe. Ich hoffe, ich hab das hier unter dem richtigen Thema erstellt.

Ich möchte eigentlich mit einem externen Programm eine DLL ansprechen, die dann die erhaltenen Infos weiterverarbeitet und in ner Form darstellen kann. Leider haperts schon beim grundsätzlichen Verständnis der Logiken hinter diesem ganzen Kram mit DLLs und COM und sowas.
Wenn ich das, was ich bis jetzt alles gelesen habe, richtig interpretiere (ja, ich bin noch ein Interpreter und noch kein Compiler ), dann ist eine DLL nichts anderes als eine EXE, die aber von einem anderen Prog aufgerufen werden muß. Man kann sie nicht einzeln aufrufen. Der Vorteil, wenn man die gesamte Applikation in DLLs und EXE splittet, liegt hauptsächlich darin, Änderungen evtl. nur bei einem Teil durchgeführt werden müssen und die DLL von verschiedenen Progs (auch gleichzeitig) genutzt werden kann. Gibt es sonst noch was wichtiges?
Was hat das mit diesen COM/COM+ Objekten auf sich? Und was soll ActiveX sein?

Die DLL muß ich ja dann nur mit dem verschiedenen Möglichkeiten aufrufen (stdcall...) und der public-Funktion die Parameter übergeben, oder?!

Ich hoffe ich nerve keinen, weil das schon drölf mal gefragt wurde, aber ich hab keinen Beitrag dazu gefunden...


bis dann leutz

P.S. Das scheint ein echt cooles Forum mit vielen netten Leuten zu sein . Respect an alle die dazu beitragen.

Im Prinzip kannst du alles in DLLs auslagern. Deshalb sind sie den *.exe Dateien nicht ähnlich. Es sind bloß Bibliotheken, aus denen du dir Sachen "ausleihen" kannst. Du kannst z. B. Funktionen und Prozeduren in DLLs schreiben und dann in deinem Programm nutzen.
Was für Daten willst du denn aus einer DLL holen?

derDoc hat folgendes geschrieben:

Im Prinzip kannst du alles in DLLs auslagern. Deshalb sind sie den *.exe Dateien nicht ähnlich. Es sind bloß Bibliotheken, aus denen du dir Sachen "ausleihen" kannst. Du kannst z. B. Funktionen und Prozeduren in DLLs schreiben und dann in deinem Programm nutzen. Was für Daten willst du denn aus einer DLL holen?

Ah, ok. Das "Ausleihen" bedeutet soviel wie "ich kann die enthaltenen Funktionen und Prozeduren mitbenutzen"!?!
Nur wo ist dann der Unterschied? Wenn man mal von der Art und Weise wie eine DLL im Vergleich zur EXE aufgerufen wird absieht, wird doch genau das gleiche gemacht, oder?
Ich möchte gar keine Daten aus einer DLL holen. Ich möchte Daten an eine DLL über geben, die dann weiterverarbeitet werden und z.B. in einer Form dargestellt werden.

Du kannst dir auch die FAQ's in dem Forum angucken. Da findest du wahscheinlich sehr tolle Beschreibungen wie das funktioniert.

Ein Beispiel:
Du hast eine DLL, in der eine Prozedur ist, die dir einen Text, den du ihr übergibst auf dem Monitor (wie auch immer) ausgibt. Dann währe es am besten, dir diese Prozedur in dein Programm zu importieren und sie dann intern zu benutzen. Dazu kannst du die DLL entweder statisch oder dynamisch laden.

Oder um es plastisch zu machen:
Die DLL ist eine Bibliothek, in der es viele Bücher gibt. Du "leihst" dir ein ein Buch über Schachspielen aus. Jetzt kannst du in diesem Buch lesen, wie du richtig Schach spielst. Du kannst also mit deinem Schachbrett und mit dem Buch als Hilfe Schach spielen. Trotzdem kann die Bibliothek, wenn du ihr dein Schachbrett gibst, noch kein Schach spielen.

Thx for answers.

....

Popov hat folgendes geschrieben:

Du kannst dir auch die FAQ's in dem Forum angucken. Da findest du wahscheinlich sehr tolle Beschreibungen wie das funktioniert.

Hey, mal ehrlich, hast du dir schon mal die FAQs angesehen? Wahrscheinlich nicht, oder? Die meisten sind meiner Meinung nach ganz großer Mist. Da wird meistens irgendwelcher Code gepostet ohne auf die Hintergründe einzugehen und/oder (andere) Fachbegriffe verwendet, die dann für die meisten Anfänger (und das sollten doch die sein, die etwas von den FAQs haben) mehr Fragen als Antworten aufwerfen. Das ist leider fast überall im Inet so.

Außerdem hab ich ja auch nicht danach gesucht, wie ich solche Sachen erstelle oder benutze, sondern was das eigentlich alles genau bedeutet.
Die Erklärung von derDoc ist doch eigentlich ganz gut. Das hört sich vielleicht am Anfang ein wenig verwirrend an, aber wenn man die ersten try-and-error-versuche (ist immer noch das Beste ) macht, dann wird's immer einleuchtender.

Bleibt noch die Frage nach COM/COM+ Objekten und ActiveX. Sowie ich das bis jetzt gelesen habe, hat das ja alles mit einander zu tun (auf einer Seite stand, daß COM auf ActiveX basiert, oder war's umgekehrt [ ]), aber was ist dann der Unterschied??

mfg

Hi einsTeIn.NET,

wenn Du nur fragst und Antworten bekommst, kannst Du nicht viel dadurch lernen. Denn das was Du liest, behälst Du nur 10-15% davon. Deshalb ein Tipp von mir, setze die Antworten in Sourcecode um. Dann verstehst Du eher was damit gemeint ist. FAQ heißt ja auch Frenquenzy Asked Question, dass sind also nur Antworten auf häufig gestellte Fragen. Das was Du suchst sind Anleitungen oder Tutorials. Dazu empfehle ich Dir die Seite Delphi-Source. Dort bekommst Du noch zusätzliche Informationen und es werden Dir auch hintergründe erklärt.

Noch ein kleine Beispiel für Dich, wozu DLL gut sein können. Du kannst zum Beispiel ein häufig benutztes Formular in eine DLL auslagern. Damit brauchst Du nichtmehr dieses Formular mit den ganzen Funktionen immer wieder neu zu erstellen. Du rufst dieses Forumlar aus der DLL auf, übergibst Ihm noch Werte und das Formular rechnet damit oder führt einen Suchbefehl aus oder macht eine Abfrage. Das alles was eine DLL macht, hängt ganz davon ab was Du Ihr an Funktionen bebringst. Ich nutze zum Beispiel DLL hauptsächlich dazu um häufig genutzte Funktionen oder Formular auszulagern. Damit brauche ich in einem neuen Programm nichtmehr die Funktion extra zu schreiben sondern binde nur die DLL ein. Es gibt viele Anwendungsmöglichkeiten für eine DLL.

@derDoc

derDoc hat folgendes geschrieben:

Im Prinzip kannst du alles in DLLs auslagern. Deshalb sind sie den *.exe Dateien nicht ähnlich.

Deine Aussage ist falsch, da der Datei Header von dll und exe-Dateien bis auf genau einen Eintrag Identisch ist. Innerhalb von wenigen Minuten kann ich dir aus jeder exe eine DLL machen. Andersherum ist es etwas komplizierter, da dlls nicht unbedingt sebständig lauffähig sein müssen. Dlls stammen aus der C Welt, dort sind statische Bibiloteken(vorkompilierter Code) ein Elementarer Sprachbestandteil (entspechen Delphi's dcu's). Da man in DLLs wie in exe-Dateien Ressourcen auslagen kann, werden DLLs auch immer mehr zu einer Ressourcenablage missbraucht.


@einsTeIn.NET

Com/Com+ ist stark vereinfacht gesagt eine Datenschnittstelle zuwischen Programmen, also so eine Art OLE. ActiveX ist einfach eine komfortablere, neuere COM Version.

SMI

SMI

Vielen Dank nochmal an alle Beitragsleister.
Bin mittlerweile schon ein wenig weiter... Lesen bildet eben doch und es gibt ne Menge im Inet zu lesen Jedenfalls ist das ein riesiges Thema und man kann dazu bestimmt ein eigenes Forum erstellen. Das ist wirklich unbelievable.

SMI hat folgendes geschrieben:

... der Datei Header von dll und exe-Dateien bis auf genau einen Eintrag Identisch ist. Innerhalb von wenigen Minuten kann ich dir aus jeder exe eine DLL machen. Andersherum ist es etwas komplizierter, da dlls nicht unbedingt sebständig lauffähig sein müssen...

Sowas in der Art hab ich mir doch gedacht.

SMI hat folgendes geschrieben:

Com/Com+ ist stark vereinfacht gesagt eine Datenschnittstelle zuwischen Programmen, also so eine Art OLE. ActiveX ist einfach eine komfortablere, neuere COM Version.

Ja, richtig, OLE war damals (1995) die erste dieser Schnittstellen (ich glaub, es ging damals darum Excel-Daten in Word darzustellen) und M$ hat darauf aufbauend viele weitere Schnittstellen definiert und einen Standard vorgegeben, nach dem Schnittstellen aufgebaut werden sollen, damit diese auch von anderer Stelle wiederverwendet werden können. Die Standard-Schnittstellen IUnknown und IDispatch sind hier die Stichworte.
ActiveX war dann der Versuch von M$ einen Standard zu schaffen, der eine Konkurrenz zu Java sein sollte, also z.B. auch plattformunabhängig sein sollte. Dies ist nur teilweise geglückt, um nicht zu sagen es ist gescheitert, den 1. wurden elementare Ziele nicht erreicht und 2. wird ActiveX heute weitestgehend im Webbereich benutzt, also eher ein Konkurrent zu JScript, als zu Java.

Jedenfalls glaub ich immer noch nicht, daß ich das Thema ganz verstanden hab, dazu ist es einfach viel zu groß, aber es gibt ja auch noch viel zu lesen und damit auch viel zu lernen.
Das ist grob gesagt das, was ich bis jetzt so gelesen hab, aber wie ich ja weiter oben schon sagte, steht auch viel Unsinn im Netz, also wenn jemand was geraderücken möchte oder noch weitere Tipps hat, würde ich mich sehr freuen diese zu hören/lesen.

bis dann