So prüfen Sie, ob ein Auftrag ausgewählt ist - Seite 19
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Im Prinzip ja, aber der "Zeiger" wird seinen eigenen Zeiger haben müssen. denken Sie über meinen Vorschlag mit der Funktion, es scheint mir eine universelle Lösung. natürlich gibt es eine Frage über die Geschwindigkeit eines solchen Codes, aber es scheint die dritte Frage zu sein.
Danke, ich freue mich immer über ein konstruktives Gespräch.
Wenn also die Funktion A im Programm eine bestimmte Reihenfolge in der Schleife auswählt und dann die Hilfsfunktion B aus der Bibliothek aufruft, sollte die Auswahl der Reihenfolge in der Funktion A durch die Rückkehr nicht beeinträchtigt werden, selbst wenn B im Verlauf des Prozesses eine andere Reihenfolge auswählt.
Vielen Dank, ich freue mich immer über ein konstruktives Gespräch.
Gern geschehen, aber ziehen Sie keine voreiligen Schlüsse.
Wenn Sie den Wert der Funktion in einer Variablen speichern, ja. Wenn nicht, ist die Funktion global und kann sich beim ersten Aufruf ändern.
Ich bin ein wenig verwirrt. Ich meinte die folgende Situation: Wir rufen die Bibliotheksfunktion B() aus der Funktion A() im Modul des Hauptprogramms auf, die zum Beispiel einfach die erste Reihenfolge in der Liste auswählt (unter der Annahme, dass es a priori eine Reihenfolge gibt):
void B(){
OrderSelect(0,SELECT_BY_POS);
}
Wenn die Kontrolle von der Bibliothek zum Hauptmodul zurückkehrt, nachdem diese Funktion aufgerufen wurde, und wir OrderTicket() oder eine andere Funktion darin aufrufen, die erwartet, dass die Bestellung vorausgewählt ist, erhalten wir genau denselben 4105-Fehler. Wenn aber vor dem Aufruf der Funktion B im Hauptmodul bereits eine andere Reihenfolge ausgewählt wurde, bleibt diese unabhängig von der neuen Auswahl in der Bibliothek ausgewählt, da die aktuell ausgewählte Reihenfolge, so wie ich es verstehe, nur innerhalb des Moduls eindeutig ist.
Rufen wir jedoch dieselbe Funktion B von der Funktion A des Hauptmoduls aus auf, so ändert sich die in der Funktion A vor dem Aufruf von B gewählte Reihenfolge in die Reihenfolge 0 (d. h. die aktuell gewählte Reihenfolge nach der Rückkehr aus der Funktion B ist die Reihenfolge 0, unabhängig davon, welche Reihenfolge vor dem Aufruf von B gewählt wurde).
Wenn wir also eine Funktion aufrufen, die OrderSelect selbst verwendet, sollten wir sicherstellen, dass wir, wenn wir von dieser Funktion zurückkehren, die Reihenfolge gewählt haben, bevor wir diese Funktion aufrufen, damit wir sie später verwenden können. Wenn Sie das nicht sicherstellen, kann das zu schwer zu findenden logischen Fehlern in Ihrem Code führen.
Konkret ist der "Zeiger" - der Zustand der aktuellen Auftragsauswahl - innerhalb des Moduls global, d.h. dieser Zeiger ist für die Bibliothek gleich und für das Programmmodul unterschiedlich. Das heißt, wenn die Funktion A im Programm eine bestimmte Reihenfolge in der Schleife auswählt und dann die Hilfsfunktion B aus der Bibliothek aufruft, dann sollte die Auswahl der Reihenfolge in der Funktion A bei der Rückkehr nicht geändert werden, selbst wenn B während seiner Operation eine andere Reihenfolge auswählt. Aber wenn beide Funktionen innerhalb eines Moduls sind, dann bei der Rückkehr von B-Funktion, müssen wir uns erinnern und wieder die aktuelle Reihenfolge Auswahl entweder vor und nach B in A-Funktion selbst oder in B-Funktion aufgerufen wird, wenn es beginnt und beendet seine Arbeit, so dass die Logik der A-Funktion Arbeit ist nicht an diesem Punkt verletzt.
Ihr Standpunkt ist klar...
Ich sehe eine Analogie zu gängigen Expert Advisor-Konstrukten, bei denen Ticket-Nummern in Variablen gespeichert und später verwendet werden (bei den nächsten Ticks, z. B. wenn ein Byyticket geöffnet wurde usw.)...
Wenn Sie ein Ticket für die zuletzt geöffnete Bestellung erhalten möchten, verwenden Sie einfach die Eigenschaften dieser Bestellung, OrderSelect(), und alles wird gut sein.Das bedeutet, dass der Expert Advisor zu jedem Zeitpunkt "verstehen" muss, in welchem Zustand sich die Handelsstrategie befindet, und dass er entsprechend dieses Zustands handeln muss, unabhängig davon, was mit der Elektrizität und anderen funktionierenden Expert Advisors im Terminal geschieht.
Wenn die Kontrolle von der Bibliothek zum Hauptmodul zurückkehrt, nachdem diese Funktion aufgerufen wurde, erhalten wir genau denselben 4105-Fehler, wenn wir die Funktion OrderTicket() oder eine andere Funktion darin aufrufen, die für die Vorauswahl der Bestellung vorgesehen war. Wenn aber vor dem Aufruf von Funktion B im Hauptmodul bereits eine andere Reihenfolge ausgewählt wurde, bleibt diese unabhängig von der neuen Auswahl in der Bibliothek ausgewählt, da die aktuell ausgewählte Reihenfolge, so wie ich es verstehe, nur innerhalb des Moduls eindeutig ist.
Es ist erwiesen, dass es so funktioniert, oder glauben Sie, dass es so funktioniert?
Für mich gibt es keine Trennung in Module und Bibliotheken... einmal kompiliert arbeitet der Code als ein einziges Konstrukt...
wo immer OrderSelect() aufgerufen wird, wird das gleiche OrderTicket() der zuletzt ausgewählten Bestellung zurückgegeben...
Ich denke, es sollte folgendermaßen funktionieren...
Es ist erwiesen, dass es so funktioniert, oder glauben Sie das?
Für mich gibt es keine Unterteilung in Module und Bibliotheken... nach der Kompilierung arbeitet der Code als ein einziges Konstrukt...
Immer wenn OrderSelect() aufgerufen wird, wird das gleiche OrderTicket() der zuletzt ausgewählten Bestellung zurückgegeben...
Ich denke, es sollte folgendermaßen funktionieren...
Es wurde überprüft, dass die in der Bibliothek ausgewählte Reihenfolge nicht die ausgewählte Reihenfolge ist, wenn sie im Hauptmodul zurückgegeben wird. Daher sollte der logischerweise ausgewählte Auftrag der zuletzt ausgewählte Auftrag im Hauptmodul sein, obwohl ich das noch nicht überprüft habe.
Ich habe dieses Problem für mich selbst gelöst, indem ich Wrapper für Bibliotheksfunktionen in der Include-Bibliotheksdatei mqh ähnlich der folgenden erstellt habe:
bool GetOrder(int a=0){
return(OrderSelect(_GetOrder(a),SELECT_BY_TICKET));
}
Übrigens können Sie auch keine Standardparameter an Bibliotheksfunktionen übergeben.
Hier ist _GetOrder(int a) die eigentliche Bibliotheksfunktion, die eine Ordnung findet und zurückgibt. Die Funktion wird aus der Bibliothek mit einem expliziten Parameter "a" aufgerufen, in der Wrapper-Funktion ist er standardmäßig 0, außerdem wird das zurückgegebene Ticket im Wrapper im Hauptprogramm-Modul neu ausgewählt, da seine Auswahl in der Bibliotheksfunktion den "Empfänger" nicht erreicht.
Ich denke auch, dass, egal von wo aus diese Funktion aufgerufen wird, sie einen Satz ausgewählter Parameter für eine bestimmte Reihenfolge vorgibt, und das Programm wird sie bis zum nächsten Aufruf dieser Funktion nicht ändern, egal von wo aus dieser Aufruf kommt.
Warum sonst sollten Sie diese Funktion in eine zusätzliche, völlig unnötige Funktion verpacken?
PYSYS. Ratschlag - erstellen Sie eine statische Integer-Variable, übergeben Sie den Wert der Bestellung nach dem Öffnen, es wird sich nicht ändern, bis Sie es wollen, und wird genau das tun, was Sie geplant haben.
Es wurde überprüft, dass die in der Bibliothek ausgewählte Reihenfolge nicht die ausgewählte Reihenfolge ist, wenn man zum Hauptmodul zurückkehrt. Logischerweise sollte also der ausgewählte Auftrag bei der Rückkehr der zuletzt ausgewählte Auftrag im Hauptmodul sein, obwohl ich das noch nicht überprüft habe.
Und diese Aussage bedarf der Klarstellung: Die Aussage ist wahr, wenn wir über ein Modul (Bibliothek) sprechen, das NUR kompiliert wurde (*.mg4-libraries aus dem Bibliotheksordner). Für Module, die Teil der kompilierten Hauptdatei (*.mgh-library) sind, trifft diese Aussage NICHT zu!
MQH ist kein separates Modul, sondern eine Einfügung in das Hauptmodul, das sich in einer anderen Datei befindet. Es handelt sich also um eine separate .ex4-Bibliothek