Ticaret ortamıyla çalışırken yaygın hatalar ve bunları ortadan kaldırmanın yolları - sayfa 6
Alım-satım fırsatlarını kaçırıyorsunuz:
- Ücretsiz alım-satım uygulamaları
- İşlem kopyalama için 8.000'den fazla sinyal
- Finansal piyasaları keşfetmek için ekonomik haberler
Kayıt
Giriş yap
Gizlilik ve Veri Koruma Politikasını ve MQL5.com Kullanım Şartlarını kabul edersiniz
Hesabınız yoksa, lütfen kaydolun
zaten tartışıldı . evrensel olarak çalışmayacak, çünkü birinin birine ihtiyacı var, diğeri diğerine.
Gerçeğe dönüş çağrısı yapıyorum. Ve bir piyasa emri şeklinde bir belirsizlik varsa, o zaman ya sonucunu bekleyin ve daha önce olanları yayınlayın ya da programın nasıl işleneceğine karar vermesine izin verin. Ancak miktarı kesinlikle rastgele iade etmeyin.
Bu belki değil, ama olduğu gibi. Tamamen düzenlenebilir iki konum ve bir dondurulmuş (değişmez) konum vardır. Sadece üç pozisyon var. Referans olarak aldığınız MT4 mantığına tam olarak uyuyor.
MK normal bir senkron işlem yapsaydı böyle bir soru hiç olmazdı.
Üstelik fxsaber yaptığı şeyi neden yaptığını ve mantığımın ona neden uymadığını da açıkladı.
Ticaret, otomatik ticaret sistemleri ve ticaret stratejilerinin test edilmesi hakkında forum
Ticaret ortamıyla çalışırken yaygın hatalar ve bunları ortadan kaldırmanın yolları
fxsaber , 2018.02.24 16:25
Hatta bu tür iptal edilmiş piyasa emirlerinin nasıl göründüğünü göstereceğim.
Sadece hata yok.
Bu örnek çok daha havalı çıktı. Aracının kendisi tarafından belirlenen TP kaydedildi! Ve hemen hemen (115 ms kadar bekledim - görünüşe göre bir MT5 hatası ) reddedildikten sonra, komisyoncu bir sonraki TP'yi belirledi, ki bu ortaya çıktı. Siparişlere yapılan yorumlar ekranda görünmüyordu. Yeşil renk - ORDER_REASON_TP . Ve buna göre reddetme emrinin bir ORDER_POSITION_ID'si bile var.
MK normal bir senkron işlem yapsaydı böyle bir soru olmazdı.
Böyle bir OrderSend kodlayıcının kendisi tarafından yazılabilir. OrderSend'in senkron versiyonunu kullandığımda kullandığım çözüm tam olarak bu.
Aynı zamanda, bunu kendi başlarına yazarlarsa MK'nin bir zaman aşımına uğrayabileceğini anlamak gerekir. MK'nin üçüncü taraf bir sisteme gönderilen piyasa emirlerinden sorumlu olmaması mantıklıdır.
Çok uğraştım ama 2+1 != 3'ün nerede önemli olduğunu çözemedim.
Tehdit Eşzamansız bir varyant da vardır. Ve orada bir piyasa emrine girme olasılığı oldukça yüksek. Bu nedenle, MC bir "normal senkron işlem" yapsa bile , konumların sayısını saymak için böyle bir işlev uygun olacaktır.
Böyle bir OrderSend kodlayıcının kendisi tarafından yazılabilir. OrderSend'in senkron versiyonunu kullandığımda kullandığım çözüm tam olarak bu.
Aynı zamanda, bunu kendi başlarına yazarlarsa MK'nin bir zaman aşımına uğrayabileceğini anlamak gerekir. MK'nin üçüncü taraf bir sisteme gönderilen piyasa emirlerinden sorumlu olmaması mantıklıdır.
Çok uğraştım ama 2+1 != 3'ün nerede önemli olduğunu çözemedim.
Hayır, öyle değil. Sizin durumunuzda: 2 + 1 - 1 = 3
Farklı aritmetiklerimiz olduğunu fark ettim. Muhtemelen devam etmeye değmez. Ancak tasarım bürosunu hatalarla kod göndermeyi bırakması için etkilemeye değeceğini düşünüyorum.
Farklı aritmetiklerimiz olduğunu fark ettim. Muhtemelen devam etmeye değmez. Ancak tasarım bürosunu hatalarla kod göndermeyi bırakması için etkilemeye değeceğini düşünüyorum.
Çok uğraştım ama 2+1 != 3'ün nerede önemli olduğunu çözemedim.
strateji, açık bir pozisyona anında tepki vermeyi gerektirdiğinde. bu durumda reddetme mantığı bozabilir.
vakaların ezici çoğunluğunda, herhangi bir muhasebe (hem pozisyon olarak bir emir hem de bir ara, çalışmayan durum olarak bir emir) sorunları ortadan kaldırır.
Böyle bir OrderSend kodlayıcının kendisi tarafından yazılabilir.
garip bir mantık, böylece bir terminal yazabilirim. MT4'ten sonra sorunları kodlayıcının kafasına kaydırmak gibi görünüyor. ve ne ile çok.
strateji açık bir pozisyona anında tepki vermeyi gerektirdiğinde. bu durumda reddetme mantığı bozabilir.
Korkarım bu hatalı bir mantık. Ama yanılıyor da olabilirim tabii. Mantığını duymak ilginç olurdu.
garip bir mantık, böylece bir terminal yazabilirim. MT4'ten sonra sorunları kodlayıcının kafasına kaydırmak gibi görünüyor. ve ne ile çok.
Muhtemelen, mesele hala bilgi eksikliği veya zayıf Belgeler. Bence orada bununla ilgili her şey normal bir şekilde yazılsaydı, daha az hata ve bu tür konuşmalar olurdu. Ama bu forum bunun için var. Çünkü Dokümantasyondaki her şeyi hesaba katmanın imkansız olduğu açıktır.
ZY Kamuya açıklanan hazır kararın kaynak kodu.