Hatalar, hatalar, sorular - sayfa 989
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
Hayır, tüm arabalar bireyseldir. Piggy'den WS'ye kadar eksenler bile lisanslıdır. İçimde bir suçluluk karinesi var ... Kendimizi mazur görmeliyiz ... Kendimizi haklı çıkarmalıyız ... Günlükler, bu, bu ...
Ve işlemcinin çekirdeklerinden daha fazla kilit ajanı sayısını koymak için yasama düzeyinde yasaklanmalı ve bu kadar!
...
Ve işlemcinin çekirdeklerinden daha fazla kilit ajanı sayısını koymak için yasama düzeyinde yasaklanmalı ve bu kadar!
Güzel gün. Geliştiricilere bir sorum var. İdeal anlaşma oluşturma döngüsü aşağıdaki aşamalardan oluşur:
1. OrderSend() aracılığıyla bir istek gönderme ve ardından yöntemin doğru ve geçerli bir ret kodu döndürdüğünü kontrol etme.
2.Ardından, OnTradeTransaction() aracılığıyla sunucudaki isteğin ilerlemesini izlemeniz gerekir. Bu işleyici çok kullanışlıdır ve süreç üzerinde tam kontrol sağlar.
Ancak, gerçek dünyada yaşıyoruz ve örneğin bir bağlantı hatası nedeniyle veya yalnızca işlemin "teslimat sırasında kaybolması" nedeniyle TRADE_TRANSACTION_REQUEST türünde bir işlem bekleyemeyebiliriz. Böylece bekleme döngüsü sonsuz hale gelecek ve işlemin istek üzerine tamamlanıp tamamlanmadığının tespiti imkansız hale gelecektir.
Herhangi bir mücbir sebep durumunda mantıksal olarak doğru bir süreç sonlandırmasının açık bir şekilde alınmasıyla bu tür acil durumları ele almak için herhangi bir YASAL prosedür var mı? Örneğin, 20 (veya 30 veya 40) saniye içinde TRADE_TRANSACTION_REQUEST'i beklemediysek, daha yavaş ama doğru bir algoritmaya geçeriz, yani: mevcut hacmi sembolle, OrderSend()'den önceki hacimle karşılaştırır, ararız. Tarihte bir sipariş ve durumunu hesaplayın, sinyali açmak veya atlamak için başka bir istekte bulunup bulunmayacağını belirleriz. OrderSendAsync() yöntemi için görev daha da karmaşıktır - belirli bir siparişin çalışmadığına dair kesin bir kriteriniz olması ve bu kriteri ne zaman uygulamaya başlayacağınızı bilmeniz gerekir. Bir şeyi yanlış anlarsam, lütfen beni düzeltin.
OrderSendAsync() yöntemi için görev daha da karmaşıktır - belirli bir siparişin çalışmadığına dair kesin bir kriteriniz olması ve bu kriteri ne zaman uygulamaya başlayacağınızı bilmeniz gerekir. Bir şeyi yanlış anlarsam, lütfen beni düzeltin.
HistorySelectByPosition - teoride yardımcı olması gerekir, bir sipariş gönderildiğinde kimlik verilir.
VanHelsing :
32x sistemlerde de Win7 zaten gerçek sayılarla işlemlerde sorun yaşıyor, XP'de değerleri "wininet.dll" kitaplığına aktarırken hiç çalışmıyor.
1. Mevcut tikte işlem emirleri göndermeyi bir kural haline getirin ve bir sonraki tikte gerçekleştirilmelerini kontrol edin. O zaman sonsuz döngüleriniz olmayacak.
2. Bir önceki tikte verilen emirlerin yürütülmesini kontrol ederken, her türlü OnTrade()/OnTradeTransaction() ile uğraşmayın. Hesabınızın durumunu kontrol edin, ör. orijinal ile çalışın. Sonuçta, herhangi bir ticaret emri, ticaret hesabınızın durumunu değiştirmeyi amaçlar. Öyleyse bu durumun değişimini kontrol edin.
3. Kontrol sonuçlarına bağlı olarak robotunuzun daha fazla mantığını yapın.
OnTrade()/OnTradeTransaction() gibi işlevleri kullanmadan önce, sizin için neyin daha önemli olduğuna karar verin:
a). belirli piyasa koşulları altında bir pozisyon açma/kapama/değiştirmeyi başarmak;
b). ticaret emrinizin uygulanmamasının nedenini bulmak için zaman harcayın ve suçlanacakları arayın.
Yine de, hala biraz kafa karışıklığım var. Bir sonraki kene üzerindeki kontrol sonucunda pozisyon değişikliği ALAMADIysak , bu durumda ne yapmalıyız. Değişim eksikliğinin nedenleri tamamen farklı olabilir. Bir seçenek olarak:
sunucuda istek üzerine bir sipariş oluşturuldu, ancak bir nedenle reddedildi,
sunucu aşırı yüklendi - gecikmeli yürütme,
bir süre bağlantı koptu.
Siparişin yerine getirilmediğine dair kesin bir kritere sahip olmak istiyorum. Asenkron bir sistemde zaman bağlama, bana belirsizliğe izin vererek çok doğru değil gibi görünüyor. Belki geçmişten bir sipariş seçip durumunu kontrol etmek veya sion tarafından önerildiği gibi HistorySelectByPosition'ı kullanmak mantıklı olabilir. Geliştiriciler bu sistemi böyle tasarladılarsa, bu tür önemli işlemleri gerçekleştirmek için "doğru" yöntemler olması gerektiği gerçeğinden yola çıkıyorum.
Siparişin yerine getirilmediğine dair kesin bir kritere sahip olmak istiyorum
sana zaten söylendi
Her türlü OnTrade()/OnTradeTransaction() ile uğraşmayın.
orijinal ile çalışmak
Merhaba!
Komut dosyası başladığında, "Uzmanlar" sekmesinin tüm içeriğinin üzerine yazılacak şekilde nasıl yapılır? (cls komutu gibi), aksi takdirde, komut dosyasının önceki çalıştırmasından ve mevcut olandan yazdırma çıktısının nerede bittiğini anlamak zor olabilir.
Teşekkürler!!
Merhaba!
Komut dosyası başladığında, "Uzmanlar" sekmesinin tüm içeriğinin üzerine yazılacak şekilde nasıl yapılır? (cls komutu gibi), aksi takdirde, komut dosyasının önceki çalıştırmasından ve mevcut olandan yazdırma çıktısının nerede bittiğini anlamak zor olabilir.
Teşekkürler!!
ve satırı deinit betiğine eklersiniz
Yazdır ("==================== Son ===================")