Fragen von Neueinsteigern zu MQL4 und MQL5, Hilfe und Diskussion über Algorithmen und Codes - Seite 520
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
Was ist an einem solchen Entwurf so schlimm?
Oder ist es besser,datetime zu einem langen Typ zu machen?
Aber es gibt ein offensichtliches Verlangen nach Genauigkeit (datetime ist größer als time_t, um es gelinde auszudrücken).
und es sollte für Zeitvergleiche eher lang sein. Wenn der Compiler etwas optimiert, wirft er es weg, und es bleibt ein Depot für die Zukunft :-)
Bis jetzt sehe ich kein Problem.
Aber es gibt eine offensichtliche Tendenz, genauer zu sein (datetime ist sanft größer als time_t)
und es ist wahrscheinlicher, dass diese Länge zum Vergleich der Zeiten verwendet werden sollte. Wenn der Compiler etwas optimiert, wirft er es weg und hinterlässt ein Depot für die Zukunft :-)
Sie können es also ohne Konsequenzen nutzen, ohne zu schummeln?
Sie können es also ohne Konsequenzen nutzen, ohne zu schummeln?
Nun, wie könnte es ohne Konsequenzen sein :-)
long x = TimeCurrent(); bekommt schon eine "Ohrfeige" in guter Gesellschaft :-) Die Typen unterscheiden sich nicht nur in der Physik, sondern auch in den Abmessungen, und Sie wandeln einen größeren Typ in einen kleineren um.
Aber ja, alle Sekunden aus (datetime)TimeCurrent scheinen in long zu passen
Es gibt eine großartige Funktion StringFind() - suchen Sie nach "#" oder "von #".
und was machen wir damit?
InStringSubstr, ist alles klar, Sie erhalten Ziffern sofort - Ticket, aber hier inStringFind , wissen wir bereits, dass es"zu #" in den Kommentar
Gefunden
und was ist damit zu tun?
InStringSubstr ist alles klar, wir bekommen die Zahlen sofort - Ticket, aber hier inStringFind was, wir wissen bereits, dass es"zu #" im Kommentar ist
aber wir wissen nicht, wo.) StringFind sagt uns, ob sich das gesuchte "to #" an dieser Stelle befindet oder nicht. Verlassen Sie sich nie auf etwas, das aus dem Netz kommt und das Sie persönlich nicht kontrollieren :-) Wir spielen hier mit Geld - das ist eine ernste Sache.
aber ich weiß nicht, wo :-) StringFind sagt Ihnen, dass das gesuchte "to #" genau an dieser Stelle steht, oder dass es gar nicht existiert. Verlassen Sie sich nie auf etwas, das aus dem Netz kommt und das Sie persönlich nicht kontrollieren :-) Wir spielen hier mit Geld - das ist eine ernste Sache.
Sie müssen das Ticket im Kommentar hervorheben und das "to #" weglassen.
das Ticket für eine offene Position wird mit dem Ticket im Kommentar für eine geschlossene Position verglichen
Warum suchen wir überhaupt nach dem "to #"?
Die FunktionStringSubstr gibt den rechten Teil des Kommentars zurück. Warum gibt diese Funktion den Gewinn einer offenen Position zurück und nicht den Gewinn einer geschlossenen Position? Ich gehe durchMODE_HISTORY
Was ist der Schaden einer solchen Konstruktion?
Oder ist es besser,datetime zu einem langen Typ zu machen?
Das Ticket sollte aus dem Kommentar hervorgehoben werden und das "to #" sollte entfallen.
das Ticket für eine offene Position sollte mit dem Ticket im Kommentar für eine geschlossene Position verglichen werden
Warum suchen wir überhaupt nach dem"to #"?
Wir suchen danach, um herauszufinden, ob der Kommentar überhaupt von# oder nach# lautet. Wenn dies nicht der Fall ist, dann ist dieser Auftrag nicht Teil einer geschlossenen Position und wir brauchen ihn nicht.
Wenn StringFind(OrderComment(), "#to") größer oder gleich Null ist, bedeutet dies, dass der Kommentar den gesuchten Teilstring enthält, und erst jetzt können wir die Position der Ticketnummer in diesem String berechnen.
Die FunktionStringSubstr gibt den rechten Teil des Kommentars zurück. Warum gibt diese Funktion den Gewinn einer offenen Position zurück und nicht den Gewinn einer geschlossenen Position? Ich gehe durchMODE_HISTORY.
Und das ist die Antwort auf diese Frage.
Forum zum Thema Handel, automatisierte Handelssysteme und Strategietests
Alle Fragen von Neulingen zu MQL4, Hilfe und Diskussion über Algorithmen und Codes
PolarSeaman, 2018.04.07 00:25
GefundenUnd was ist damit zu tun?
Alles ist klar, inStringSubstr, erhalten Sie Zahlen - Ticket, aber hier inStringFind was, wir wissen bereits, dass es"zu #" in den Kommentar
Aber wenn Sie das nicht tun, werden Sie etwas ganz anderes bekommen.