Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret 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
"normal" robotlarda, tarif ettiğim durumu hiç fark etmedim; ama bir tanesinde bir güvenlik sistemi yapmam istendi: koşul, pozisyonların her zaman kilitli olmasıydı (gerçek pozisyonlar veya bekleyen bir emir ), yani. Alınacak lot sayısı satılacak lot sayısına eşittir. Bu vaka beni ilk beşte siparişleri / pozisyonları / anlaşmaları saymanın nüanslarıyla tanıştırdı.
fark, kendime açıkladığım gibi, :), aracıdan bir yanıt alan dördü, önce "tablolarını" açık siparişler ve geçmişle senkronize eder ve ardından kullanıcıyı aracının yanıtı hakkında bilgilendirir. beşi hemen bu cevabı bize yayınlar ve paralel olarak "tablolarını" düzenler (ve tüm mql programları bu "tablolardan" verileri okur). Milisaniye zamanlayıcısını yakaladığımız an bu andır. Ama o zaman, neden bununla test cihazında karşılaşmıyoruz?
Sonuçta, anlaştım...
Hayır, işler kötüye gidiyor.
Bekleyen (veya piyasadan) geçmişe (yürütülen veya iptal edilen) dönüşüm anındaki emir, bir süre için terminalden tamamen kaybolur. Ne bekleyen (veya "başlayan" piyasalar arasında) ne de tarihi olanlar arasında.
Yani, yürütme ile ilgili değil, bu iki tabloyu senkronize etmekle ilgili. Sunucudan yanıt geldi ("sipariş verildi, şöyle ve böyle bir işlem oluşturuldu"), bir tablodan silindi ve diğerine girilmedi.
Hayır, işler kötüye gidiyor.
Bekleyen (veya piyasadan) geçmişe (yürütülen veya iptal edilen) dönüşüm anındaki emir, bir süre için terminalden tamamen kaybolur. Ne bekleyen (veya "başlayan" piyasalar arasında) ne de tarihi olanlar arasında.
Yani, yürütme ile ilgili değil, bu iki tabloyu senkronize etmekle ilgili. Sunucudan yanıt geldi ("sipariş verildi, şöyle ve böyle bir işlem oluşturuldu"), bir tablodan silindi ve diğerine girilmedi.
Bunu kontrol etmek ilginç. Igor Makanu bir sorunla ilgimi çekti https://www.mql5.com/en/forum/6343/page1097#comment_12518742
Dizdeki ilk yaklaşımda yapılmıştır. Sonra OnOrder ve OnOrderTransaction'ın çalışması ve terminalin ticaret ortamının durumu hakkında istatistikler toplayacağım ve çok tembel değilse, farklı hesaplarda / brokerlerde nasıl olduğunu görmek için demo testlerine koyabilirsiniz.
o zaman analiz etmek mümkün olacaktır. Şu ana kadar aşağıdaki varsayımlar yapılmıştır: 1. Kısmi işlem kontrol edilmedi ve hesaptaki işlem özellikleri kontrol edilmedi, piyasa emri gönderdim, açık pozisyonu hatırladım, işlemin bu pozisyonun kapanmasını bekliyorum. oturum açın ve ters yönde tekrar açın. 2. İdeal olarak, OnOrderTransaction'da belirli bir işlemi yakalamak için, ancak şimdiye kadar bunu yaptım - her iki olayda da her şeyi aynı şekilde kontrol ediyorum.
Doğal olarak, kod optimal değildir. Her şey yukarıdaki gönderide açıklandığı kadar kötüyse, sipariş-pozisyon kayıplarının nerede olacağını zaten görüyorum.
Bunu kontrol etmek ilginç. Igor Makanu bir sorunla ilgimi çekti https://www.mql5.com/en/forum/6343/page1097#comment_12518742
Dizdeki ilk yaklaşımda yapılmıştır.
Bu demoyu izlemek daha iyidir. ForexTimeFXTM-Demo01
"normal" robotlarda, tarif ettiğim durumu hiç fark etmedim
Bitler için herhangi bir ticaret kitaplığı, çeşitli demo hesaplarında stres testleri yoluyla kontrol edilebilir ve edilmelidir. Her şeyi sorunsuz atlatmalı.
Bunun olması için yazarın MT5 şakalarıyla şahsen tanışması gerekecek. Uygulamamda bunun bile yeterli olmadığı ortaya çıktı.
Sunucuları takas etmek için korkunç spam siparişleri tarafından ortaya çıkarılmayan çok özel şeyler var. Geri bildirim sayesinde, geliştiricilerin bile farkında olmadığı çok garip davranışlar bulmak mümkün oldu.
tartışmada bir çözüm vardı https://www.mql5.com/ru/forum/6343/page1098#comment_12519819 , ancak tartışmanın bir kısmı kayboldu (((
Çözüm, MT4Orders iş parçacığındadır. Ama her tırmığı kendin hissetmelisin ;)
Evet, komisyon her zaman ilginçtir ve sonra profesyonellerin bunu nasıl yaptığını görün. fxsaber çözümü, özlü olması bakımından dahicedir, ancak bu çözümde bir şeyde bir pusu görüyorum - kılavuzlar, pozisyon biletinin GENELLİKLE açılan siparişin bileti olduğunu, ancak HER ZAMAN DEĞİL olduğunu söylüyor.
Kararımda bundan yola çıktım.
Bitler için herhangi bir ticaret kitaplığı, çeşitli demo hesaplarında stres testleri yoluyla kontrol edilebilir ve edilmelidir. Her şeyi sorunsuz atlatmalı.
tarif ettiğim robotta komisyoncu değil, zamanlayıcıydı. Testler için 200ms kullandım ve geri verdiğimde kişi 5ms olarak ayarladı. beşte neredeyse her zaman herhangi bir hesapta çalıştı.
Önemli olup olmadığını bilmiyorum, ancak orada timeBeginPeriod(1) şarapları kullanıldı, yani. standart 20 ms'nin altında her şey oldu
pozisyon bileti GENELLİKLE açılan siparişin biletidir, ancak HER ZAMAN DEĞİLDİR.
Pek iyi hatırlamıyorum ama hep hatırlıyorum.
Pek iyi hatırlamıyorum ama hep hatırlıyorum.
evet haklısın çünkü bu durumda, ömrü boyunca sabit olan bir konum tanımlayıcıdan bahsediyoruz. Rollover ve netleştirme sırasında değişen pozisyon bileti ile karıştırdım.
Sadece anlamadım - bir pozisyon kısmen kapatıldığında - bilet chtoli'yi pozisyonu etkileyen son siparişin bilete değiştirmiyor mu?
Fırsatları kullanmak gereksiz o zaman, kodlarımı gözden geçireceğim, teşekkürler. Foruma girmeme şaşmamalı)
Ne güncel listede ne de tarihi listede olmayan "kayıp düzen" sorusuna: Bana öyle geliyor ki bu bir bug değil, işin özelliklerine dikkatlice bakmanız yeterli.
bağlamalar Terminal-Server MT-Market (Anında yürütme durumunda piyasa kaybolur). Bence öyle, bakın - terminal bir piyasa emri gönderir, senkronize bir işlev olması durumunda bekler ve sunucudan bir yanıt alır,
bir hata değilse, o zaman cevap yalnızca TRADE_RETCODE_DONE olabilir (anlık yeniden teklifler durumunda, ancak şimdiye kadar piyasa yürütme türü hakkında), bu da esasen sunucunun siparişi piyasaya ve kendisine daha fazla gönderdiği anlamına gelir.
bir cevap beklemek. Siparişin şu anki durumu yanılmıyorsam ORDER_STATE_STARTED ve bileti biliniyor. Emir gerçekleşirse, sunucu terminale OnTradeTransaction gönderir ve emir durumu ORDER_STATE_FILLED olarak değişir ve işlem bilinir hale gelir.
ve konum. Sadece şu anda terminal, siparişi tarihe kaydeder. Daha önce, bunu yapmaz çünkü. ona ne olduğu kesin değil, sunucunun birincil yanıtını zaten verdi.
Bu, emirlerin ECN ağında veya başka bir yerde yürütüldüğü zamandır ve her iki listede de yoktur. Onlar. bir piyasa emri söz konusu olduğunda, genellikle yalnızca geçmişte görünür (anlık yürütme sırasında yeniden fiyatlama durumundan emin değil),
asla açık listede olmayacak. Ve beklemedeyken, çalıştığında, zaten bir piyasa emri haline geldiği için açık olanlar listesinden çıkarılır ve ayrıca piyasa sunucusunun yanıt vermesini bekler ve ardından tarihe kaydedilir.
doğru mu konuşuyorum