Fehler, Irrtümer, Fragen - Seite 2541

Neuer Kommentar
 
Ilyas:
Sie haben also die Kontrolle nicht an das Terminal zurückgegeben, sondern sind in einer "Endlosschleife" innerhalb der Fn in der DLL "hängengeblieben".
Von welcher Art von normaler Beendigung reden wir hier?

Wenn Sie ein solches Verhalten benötigen, sollten Sie einen separaten Thread mit einer Schleife innerhalb von Fn in DLL laufen lassen, der durch ein Flag gestoppt werden sollte, das in einer separaten Funktion FnStop und mit DLL_PROCESS_DETACH gesetzt wird

Die Tatsache, dass ich nicht die Kontrolle zurück, es ist zum Beispiel getan, ist es klar, dass während sollte in einem separaten Thread ausgeführt werden, um nicht zu blockieren, die mql-Thread.
Aber ich bekomme das gleiche Verhalten, wenn ich, während in einem anderen Thread laufen, das Problem ist in DLL_PROCESS_DETACH, dieser Bezeichner funktioniert nicht, für die vorhandene Flagge Detach.
Ja, wir haben bereits geschrieben, dass wir eine separate exportierte Funktion erstellen und diese zur Steuerung dieser Flagge verwenden müssen.
Aber wie in diesem Beispiel gezeigt, funktioniert das Flag in DLL_PROCESS_DETACH nicht.
Vielleicht liegt ein Fehler im Terminal vor, dann ist es logisch, dass DLL_PROCESS_DETACH das Flag in einen anderen Zustand versetzt.
Die while-Schleife erhält diesen Zustand, verlässt die Schleife, führt alles aus, was auf dem Weg begegnet, und beendet die Funktion Fn() selbst.
Erst danach sollte die dll entladen werden!
Dies geschieht jedoch nicht, sondern es kommt zu einer Art vorzeitiger Entladung durch versteckte Terminalmechanismen, was zu einem Absturz führt.

 
TheXpert:

Ich möchte nicht, dass inkompetente Leute wie Sie, Fedoseyev usw. an der Diskussion über Fehler und Konstruktionen beteiligt werden.

so dass Konstruktionen und Mechanismen, die in MQL vollständig aus C++ übernommen wurden und genauso aussehen wie in C++, auch genauso funktionieren wie in C++.

Es ist Blödsinn und Sie wissen es, aber Sie müssen es sagen.

Sie sind derjenige, der sich darüber beklagt, wie lästig es ist, eine eigene Sprache und ein eigenes Thema zu haben.

Eröffnen Sie einen eigenen Thread für sich und Ihre Sympathisanten und jammern Sie dort.

Ich hatte eine bessere Meinung von Ihnen. Mein Fehler. Das kommt vor. Du bist ungehobelt und ... nicht klug.

 
Roman:

Es ist zum Beispiel gemacht, während sollte in einem separaten Thread ausgeführt werden, um nicht zu mql Thread blockieren.
Ich erhalte das gleiche Verhalten, wenn ich starte, während in einem anderen Thread, das Problem ist in DLL_PROCESS_DETACH, diese Kennung funktioniert nicht, für bestehende Flagge Detach.
Ja, wir haben bereits geschrieben, dass wir eine separate exportierte Funktion erstellen und diese zur Steuerung dieser Flagge verwenden müssen.
Aber wie in diesem Beispiel gezeigt, funktioniert das Flag in DLL_PROCESS_DETACH nicht.
Vielleicht liegt ein Fehler im Terminal vor, dann ist es logisch, dass DLL_PROCESS_DETACH das Flag in einen anderen Zustand versetzt.
Die while-Schleife erhält diesen Zustand, verlässt die Schleife, führt alles aus, was auf dem Weg begegnet, und beendet die Funktion Fn() selbst.
Erst danach sollte die dll entladen werden!
Dies geschieht jedoch nicht, sondern es kommt zu einer Art vorzeitiger Entladung durch versteckte Terminalmechanismen, was zu einem Absturz führt.

Lassen Sie mich raten. Wenn Sie eine Schleife in einem Terminal-Thread von dll starten, bleibt sie hängen, und wenn Sie sie in einem separaten Thread ausführen, der detach(), dann stürzt das Terminal mit einem Fehler ab?
 
Roman:

Die Nichtübernahme der Kontrolle ist nur ein Beispiel, es ist klar, dass while in einem separaten Thread ausgeführt werden sollte, um den Thread nicht zu blockieren.

Geben Sie uns also ein gutes Beispiel und lassen Sie die Anhänge in Ruhe. Verwalten Sie die Erstellung/Löschung von Themen ausdrücklich selbst.
 

Forum zum Thema Handel, automatisierte Handelssysteme und Testen von Handelsstrategien

Wanzen, Wanzen, Fragen

Sergey Dzyublik, 2019.05.26 15:12

Leider sind die Funktionszeigertypen in MT4/MT5 derzeit sehr begrenzt und aufgrund einiger Mängel nicht praktikabel:
#(nicht behoben in MT5(build 2118))"Kompilierungsfehler bei wiederholter Verwendung der gleichen Funktionssignatur innerhalb von typedef".
#(nicht behoben in MT5(build2118))"Bei der Arbeit mit typedef wird bei der Verwendung einer Template-Funktion mit expliziter Spezialisierung kein Code für diese Template-Funktion erzeugt".


In Anbetracht der anstehenden Namespace-Implementierung sollten Sie in Erwägung ziehen, die Unterstützung für dieses Verhalten als Teil der Fehlerkorrekturen in der nächsten C++ zu implementieren:
//#include <iostream>

template<typename T>
class A{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
    T data;
};

template<typename T>
class B{
public:
    typedef void (*callback)(T&);   //class namespace for function pointer type
    callback f_ptr;
};

template<typename T>
void func(T& value){
    ++value;
}


void OnStart(){
//int main(){
    A<int> a;
    B<int> b;
    
    a.f_ptr = func<int>;      // automatic code generation of templates functions
    b.f_ptr = a.f_ptr;        // assignment operation for function pointers with the same function signatures and different function pointer types.
    
    int x = 1;
    b.f_ptr(x);
    printf("%d\r\n", x);                  //2
    printf("%d\r\n", b.f_ptr == a.f_ptr); //1     // equal operation for function pointers with the same function signatures and different function pointer types.
}

MT5 (Build 2118), Wie lange können wir noch auf Fehlerbehebungen in derTypedef-Funktionalität warten?
Irgendein Unsinn - ein Schritt nach links zu einem primitiven Beispiel für die Verwendung vontypedef und das war's -ein Haufen von Fehlern, die die weitere Entwicklung blockieren.

 
Vladimir Simakov:
Lassen Sie mich raten. Wenn Sie eine Schleife von dll in einem Terminal-Thread ausführen, bleibt sie hängen, aber wenn Sie sie in einem separaten Thread ausführen, an den Sie detach() anhängen, stürzt das Terminal mit einem Fehler ab?

Nicht ganz.
Das Starten einer Schleife funktioniert problemlos.
Das Problem tritt auf, wenn Sie das Programm zwangsweise anhalten und ein Flag an die Schleife übergeben, um die Schleife zu verlassen und eine laufende Funktion zu beenden.
Aber das Terminal erlaubt es nicht, die Schleife zu verlassen und die laufende Funktion korrekt zu beenden, da das frühe Entladen der DLL bereits ausgelöst wurde. Wir werden aufgehalten.
Die DLL wird entladen, bevor der Flaggenstatus übergeben wird, und die Fn-Funktion wird nicht beendet; frühes Entladen macht alles kaputt.

Ich habe es zum Beispiel in einem Terminal-Thread gemacht, um nicht den ganzen Code zu schreiben, denn im blockierenden Modus ist das Problem besser zu sehen.
Ich habe eine separate Funktion für das Schleifenflag erstellt und die laufende Schleife wird in einem anderen Thread ausgeführt, aber das Verhalten ist dasselbe.
Und wenn ich versuche, die Flagge in einen anderen Zustand von nicht gesperrten mql-Code zu wechseln, durch eine Funktion zum Verlassen der Schleife,
wartet das Terminal nicht darauf, dass die laufende Schleife beendet wird, und lässt die Fn-Funktion nicht beenden, wenn die Schleife läuft.
Das Terminal führt sofort eine vorzeitige Entladung durch, ohne auf den Abschluss der Funktion Fn zu warten. Das ist das Problem.

TheXpert:
also geben sie gleich ein richtiges beispiel. und lassen sie das attachi detachi in ruhe. kontrollieren sie die erstellung/löschung von threads ausdrücklich selbst.

Sie können das Problem im gesperrten Modus besser erkennen. Es spielt keine Rolle, was den Zustand der Flagge verändert. Mit einem Einstiegspunkt oder einer separaten Funktion.
Der Einstiegspunkt ist besser für den gesperrten Modus geeignet, da die Kontrolle nicht zurückgegeben wird und die Flaggenänderungsfunktion nicht aufgerufen werden kann. Aus diesem Grund wird atachi detechi als Beispiel herangezogen.
Atachi abnehmbar allein gelassen, machte eine separate Funktion, wie Sie beraten, kein Glück, auf einem funktionierenden Projekt in nicht-blockierenden Modus, das gleiche Verhalten.
Die DLL wird zu früh entladen, die laufende Funktion mit der while-Schleife hat keine Zeit zum Abschluss und bleibt hängen.

 
Roman:

Die DLL wird zu früh entladen, eine laufende Funktion mit einer while-Schleife hat keine Zeit zum Beenden und es kommt zu einem Hänger.

Bei einer normalen Umsetzung kann es nicht zu Problemen kommen.

 

Ist jemand auf das folgende Problem mit benutzerdefinierten Symbolen gestoßen? Die Funktion CustomRatesUpdate empfängt normale Kurse, aber das Diagramm und das Datenfenster enthalten etwas Seltsames (in diesem Fall sind die Schluss- und Tiefstwerte 100 Mal kleiner als die übergebenen Werte):

Außerdem werden parallel dazu einzelne Ticks mit CustomTicksAdd mit denselben Werten des Schlusskurses emuliert wie im Protokoll (unmittelbar vor CustomRatesUpdate), d. h. es ist nicht klar, woher die reduzierten Werte in Anführungszeichen kommen.

UPD:

Ich habe "umgekehrte" Situation auf USDCAD - Zitate erhöhen 10 mal nach dem Schreiben. Das ist das Protokoll, das ich erhalte:

2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]  [high]   [low] [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32987 1.32987 1.32980 1.32987           457       48             0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) Retry: 1 0
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1)                  [time]  [open]   [high]   [low]  [close] [tick_volume] [spread] [real_volume]
2019.08.23 00:04:10.579 RenkoCharts (USDCAD,M1) [0] 2019.08.23 00:02:00 1.32980 13.29730 1.32980 13.29730           457       52             0

Der erste ArrayPrint ist das, was in CustomRatesUpdate geschrieben wurde, und der zweite ArrayPrint ist das, was mit CopyRates aus dem letzten letzten Takt unmittelbar nach dem Schreiben gelesen wurde. Erstens ist der Unterschied die letzte Ziffer in Open, aber noch wichtiger ist, dass High und Close um den Faktor 10 erhöht werden.

 
Stanislav Korotky:

Ist jemand auf das folgende Problem mit benutzerdefinierten Symbolen gestoßen? Die Funktion CustomRatesUpdate empfängt normale Kurse, aber das Diagramm und das Datenfenster enthalten etwas Seltsames (in diesem Fall sind die Schluss- und Tiefstwerte 100 Mal kleiner als die übergebenen Werte):

Außerdem werden einzelne Ticks parallel mit CustomTicksAdd mit denselben Werten des Schlusskurses wie im Protokoll (unmittelbar vor CustomRatesUpdate) emuliert, d. h. es ist nicht klar, woher die reduzierten Werte in den Notierungen kommen.

Ja, ich bin darauf gestoßen, aber meine Null war nicht klar. Sie haben die 100-fache Anzahl von Stacheln.
Ich habe eine zusätzliche Nullkontrolle durchgeführt, aber das hat nicht geholfen, es funktionierte völlig falsch, und dann hat es solche Ausschläge gezeichnet.
Meistens wurde dieses Verhalten beim ersten Start des Programms beobachtet, und beim ersten Mal, als es Verlaufsdateien mit einem nicht existierenden Datum erstellte.
Gereinigt Ordner Zecken, korrigiert Code, um zu finden, wo der Fehler, gelangweilt, für jetzt verschoben, sondern auch, um dieses Problem zurückzukehren ((
Überprüfen Sie auch den Ordner "Benutzerdefinierte Historie", möglicherweise gibt es Dateien mit einem Datum, das nicht existiert )))
Im Allgemeinen lebt der Fehler dort spezifisch.

Bitte duplizieren Sie das Problem in diesem Thread
Ich glaube, Slava ist dort für die benutzerdefinierten Zeichen zuständig.
Um an das Problem zu erinnern.
 

Wurde dieser Fehler schon einmal erwähnt? Ich kann es nicht finden. Fazit: Beim Laden von Optimierungsergebnissen aus der Cache-Datei werden die Vorwärtsergebnisse nicht korrekt angezeigt. Die Parameterwerte haben die falschen Ziffern.

Sie gehen auf die Registerkarte Optimierung. Wählen Sie den Expert Advisor. Wählen Sie eine der früheren Optimierungen. Backtests werden normal geladen. Stürmer geben dies:



MT5, neueste Version. x64.

1...253425352536253725382539254025412542254325442545254625472548...3184
Neuer Kommentar