Diskussion zum Artikel "Leitfaden zum Schreiben einer DLL für MQL5 in Delphi" - Seite 2

Neuer Kommentar
 
marketeer:
Sie sollten zumindest einen Absatz über die Fehlersuche hinzufügen. Der Artikel erwähnt eine Situation, in der AV auftreten kann, aber selbst wenn man die vielen anderen potenziellen Fehlerquellen außer Acht lässt, kann die manuelle (visuelle oder mentale) Suche nach dem Fehlerort sehr lange und erfolglos sein.

Vielen Dank für Ihren Kommentar. Ich denke, dieser Abschnitt kann erweitert werden, um die häufigsten Fehler aufzunehmen. Um jedoch eine "lange und erfolglose" Fehlersuche zu vermeiden, sollten Sie alles so machen, wie es in dem Artikel beschrieben ist. Die Beispiele in diesem Artikel sind praktikabel. Benutzen Sie außerdem den Debugger in MetaEditor, er ist ziemlich anständig, mit schrittweiser Fehlersuche und Haltepunkten!

In diesem Artikel möchte ich niemandem beibringen, wie man programmiert. Wenn jemand elementare Fehler macht und dann laut schreit, , sollte er vielleicht noch nicht seine eigenen DLLs erstellen und erst einmal den matten Teil lernen.

 

Hallo HideYourRichess.

Du bist so schnell! Du hast so viel geschrieben! Du solltest deine eigenen Artikel über Delphischreiben .

Ich werde versuchen, kurz und der Reihe nach zu antworten:

1. Юниты SysUtils и Classes нужно было оставить в проекте.

SysUtils sind im Projekt! Die Klassen haben nichts zu tun! Exception-Handler neben SysUtils ist in System implementiert, die standardmäßig verbunden ist, so sehe ich keinen Grund zur Sorge.

2. Sie sollten nicht alle Arten von Prozeduren innerhalb von DllEntryPoint (auch bekannt als DllMain) verwenden.

Das DllEntryPoint-Beispiel findet man im Internet an jeder Ecke. Dies ist eine Standardmethode zur Erzeugung von DLL-Ereignissen, an die Sie z.B. die Zuweisung und Freigabe von Speicher aus dem Heap binden können. Wenn Sie echte Fehler bei dieser Methode der Arbeit mit Speicher haben, bin ich bereit, sie zu berücksichtigen.

Über alles andere, was nicht in DllEntryPoint gemacht werden kann, diskutiere ich nicht, weil ich es nicht oft benutze.

3. Sie haben eine Menge über den Speichermanager geschrieben. Ich werde nur Ihre Schlussfolgerung hervorheben:

Man kann also die DLL und die Anwendung mit einem einzigen Speichermanager ausstatten, und das wird der MT4-Speichermanager sein.

Das Problem ist, dass keiner von uns weiß, wie der Speichermanager in MT5(MT4) funktioniert. Und selbst wenn wir die Namen der Funktionen wüssten, die diesen Manager implementieren, wie soll man ihn benutzen, denn die API für MT5ist geschlossen! Die Idee eines einzigen MT5-Managers und einer DLL ist also Utopie.

Um die Leser nicht zu verwirren, schlage ich stattdessen vor, die klassische Speicherverwaltungstechnik zu verwenden, die in API-Funktionenimplementiert ist . Sie wird in diesem Artikel im Abschnitt über die Arbeit mit Strings beschrieben.

Ich rechne damit, dass anstelle des Zitierens von Delphi-Büchern und -Artikeln hier, dem Autor des Artikels nur Behauptungen im Zusammenhang mit dem, was wirklich nicht funktioniert, von dem, was im Artikel beschrieben ist, gegeben werden. Vorzugsweise mit Beispielen.


 
avoitenko :

Vielen Dank für Ihren Kommentar. Ich denke, dieser Abschnitt kann erweitert werden, um die häufigsten Fehler aufzunehmen. Um jedoch eine "lange und erfolglose" Fehlersuche zu vermeiden, sollten Sie alles so machen, wie es in dem Artikel steht. Die Beispiele in diesem Artikel sind praktikabel. Benutzen Sie außerdem den Debugger in MetaEditor, er ist ziemlich anständig, mit schrittweiser Fehlersuche und Haltepunkten!

In diesem Artikel möchte ich niemandem beibringen, wie man programmiert. Wenn jemand elementare Fehler macht und dann laut schreit, , sollte er vielleicht noch nicht seine eigenen DLLs erstellen und erst einmal den matten Teil lernen.

Da irren Sie sich aber gewaltig. Nicht nur Programmieranfänger machen Fehler - elementare und nicht so elementare - sondern auch erfahrene Programmierer.

Das hat nichts mit der Mathematik zu tun, sondern mit den Fehlersuchwerkzeugen. Erinnern wir uns an die bekannte "80 mal 20"-Statistik: 80 % der Zeit wird für die Fehlersuche verwendet und nur 20 % für das Schreiben von Code. Soweit ich das verstanden habe, ist das Ziel des Artikels, Ihnen beizubringen, wie man eine funktionierende DLL schreibt, d.h. nicht nur das angegebene spezifische Beispiel, sondern auch einen hypothetischen anderen Code. Natürlich ist es unmöglich, alle möglichen Fehler zu berücksichtigen, aber wir brauchen Informationen darüber, wie man sie prinzipiell abfangen kann. Andernfalls werden die Leser nichts anderes tun können, als das Beispiel zu reproduzieren.

Auch der MetaEditor hat damit nichts zu tun, denn es geht um das Debuggen der DLL, d.h. um ihre Interna.

Sie sind der Autor - Sie wissen es besser. Ich habe lediglich meine Meinung über eine gewisse Unvollständigkeit in der Präsentation zum Ausdruck gebracht.

 
"Du bist so schnell! Du hast so viel geschrieben! Du solltest deine eigenen Artikel über Delphi schreiben."

Dies sind Auszüge aus einem alten Artikel über dlls für mt4, unvollendet. Ich habe die Auszüge einfach hierher kopiert. Es ist nicht schwer und nicht lang.

"SysUtils sind im Projekt! Die Klassen haben damit nichts zu tun! Der Exception-Handler neben SysUtils ist in System implementiert, das standardmäßig verbunden ist, also sehe ich keinen Grund zur Sorge. "

Es bleibt dem Eigentümer überlassen, welche Units er einbindet. Aber ich denke, es ist notwendig, anzugeben, warum. In diesem Fall werden SysUtils und Classes von Borland empfohlen. Und dafür gibt es Gründe.

"Das Beispiel mit DllEntryPoint wird im Internet an jeder Ecke gegeben. Das ist eine Standardmethode, um DLL-Ereignisse zu erzeugen, zu denen zum Beispiel"

Borland hat DllMain nicht zufällig vor unbedarften Händen versteckt. Der Standardweg, eine DLL in Delphi zu erstellen, ist mit einer versteckten DllMain. Denken Sie darüber nach, warum das so ist. Und lesen Sie, was Microsoft selbst empfiehlt.

"Sie können die Speicherzuweisung und -freigabe aus dem Heap binden. Wenn Sie echte Fehler mit dieser Methode der Arbeit mit Speicher haben, bin ich bereit, sie zu berücksichtigen."

Das bleibt Ihnen überlassen. Aber meine Empfehlung ist, dass in DllMain überhaupt nichts gemacht werden sollte.

"Das Problem ist, dass keiner von uns weiß, wie der Speichermanager in MT5(MT4) funktioniert. Und selbst wenn wir die Namen der Funktionen wüssten, die diesen Manager implementieren, wie soll man ihn benutzen, denn die API für MT5ist geschlossen! Die Idee eines einzigen MT5-Managers und einer DLL ist also Utopie."

;-) für den einen ist es "geschlossen" und "Utopie" - und für den anderen "alles funktioniert". wir sprechen über 4. ich habe mir 5 nicht angesehen.

 

Es sollte erwähnt werden, dass es eine Alternative zur Verwendung von Delphi gibt.

Wenn Sie noch kein Delphi-Benutzer sind, sollten Sie Lazarus/FPC in Erwägung ziehen. Es ist Open Source, hat fast die gleichen Funktionen wie Delphi (und sogar einige mehr), ist weitgehend kompatibel mit dem Delphi-Quellcode und ich würde sogar darauf wetten, dass sich alle oben genannten Beispiele ohne Änderungen in Lazarus kompilieren lassen.

Wenn Sie Open Source gegenüber proprietärer Software bevorzugen (was Sie sowieso tun sollten), dann ist Lazarus das, was Sie suchen und nicht eine kommerzielle Testversion von Delphi.

 

In dem Artikel gibt es ein solches Verfahren:

//----------------------------------------------------------+
procedure DLLEntryPoint(dwReason: DWord); // Ereignisbehandler
//----------------------------------------------------------+
begin
    case dwReason of

      DLL_PROCESS_ATTACH: // DLL ist an den Prozess angehängt;
          // Speicherzuweisung
          Buffer:=AllocMem(BUFFER_SIZE);

      DLL_PROCESS_DETACH: // Die DLL wird vom Prozess getrennt;
          // Freigeben von Speicher
          FreeMem(Buffer);

    end;
end;

Der Compiler fragt mich, was die nicht deklarierte Variable BUFFER_SIZE ist.

Könnten Sie mir bitte sagen, was sie wirklich sein sollte und wo sie deklariert werden sollte und um welchen Puffer es sich handelt?

 
lucka88:

Der Compiler fragt mich, was die nicht deklarierte Variable BUFFER_SIZE ist.

Könnten Sie mir bitte sagen, was dort stehen sollte und wo sie deklariert werden sollte und von welchem Puffer wir sprechen?

In der Projektdatei dll_mql5.dpr gibt es die folgende Deklaration

const BUFFER_SIZE = 255;

Durch eine Code-Zeile

Buffer:=AllocMem(BUFFER_SIZE);

wird Speicher für die Speicherung der Zeichenkette im Heap zugewiesen.

Und der Buffer-Zeiger selbst wird in der Funktion GetStringBuffer verwendet, die die Arbeit mit Strings demonstriert.

 

DLL-Hilfe

Kann jemand helfen, mich zu führen ... Können wir MT4 DLL-Datei auf MT5 verwenden und wenn ja ... wo Sie es in MT5 und jede Sache, die ich wissen müssen instill.

Auch in welchem Ordner speichern wir die DLL-Datei?

Ich habe den Code für die DLL nicht mehr, so dass ich ihn nicht mehr neu schreiben kann.

Ich bin für jeden Vorschlag und jede Hilfe dankbar.

 

Beim Verbinden des Expert Advisors in MT5 erhalte ich die Fehlermeldung "dll is not 64-bit version".

Gibt es eine Möglichkeit, eine 32bit dll zu verwenden?

Wenn nicht, kann mir jemand sagen, wie man eine 64bit dll in Delphi XE kompiliert?

 
meneo:

Wie kompiliert man 64it dll in Delphi XE?

Unterstützung für 64 Bit erschien in Delphi XE2 und Lazarus.
123
Neuer Kommentar