Mt4 End desteği. - sayfa 40
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
Yani, OOP'nin avantajlarını paramparça etmeye devam etmemi istiyorsun ve herkes beni trollemeye devam etti?)) Ama aslında haklısın. Tartışma yanlış yöne gitti.
Ama trollemem. Trollere cevap vermeyin.
TWS'de, tekliflerin gelmesinden bağımsız olarak çubuklar zamanla oluşturulur. Teklif yoksa, ancak yeni bir bar zamanı geldiyse, bar, son teklifin fiyatında bir tire olarak görünür. Aynı zamanda, tüm göstergeler MT'dekiyle aynı şekilde çizilir. Barlarla ilgili tüm fikirlerim TWS'deki deneyimlerimden geliyor.
MT'de aynı olsaydı, benim çözümüm en etkili olurdu. Ancak, öyle değil...
Bu nedenle, artık kullanıma sunmayacağım.
Peter, ikinci kez tartışmak için farklı bir konu öneriyorum. Hiçbir şey yazmanıza gerek yok, sadece teori.
Ama trollemem. Trollere cevap vermeyin.
Apaçık. Yani bar, iBars'ın isteği sırasında gelmeyebilir, ancak istekten bir dakika sonra gelebilir. Daha sonra sistem için atlanacaktır. Durumda.
Sonra ne, sürekli çevirmek mi? - açıkça en iyi çözüm değil.
Ancak birinin buna ihtiyacı varsa - başka bir sembolün yeni bir çubuğunun gelişini OnTimer'da sürekli yoklama olmadan mümkün olduğunca çabuk almak için, o zaman kullanıcı kesintileri de vardır.
Bir barın yerel konseptini yeniden düşünürseniz, her şey yerine oturacaktır. Kaynaklar kaydedilecek ve çözüm basit olacak. Benim düşünceme göre, çubuk alıntılara değil zamana bağlı olmalıdır.
Kodumda hata olmadığı ortaya çıktı. Platformlar arasında bar konseptinde fark var.
Tartışacak ne var. En saf haliylepolimorfizm . OOP kuralları.
Konuya girenleri tartışacak bir şey yok. İşte en azından OOP'ye biraz aşina olma kararına nasıl geldiğime dair örnek bir hikaye.
Yeni bir çubuk tanımlama işlevini örnek olarak almama şaşmamalı. İşte benim için her şey burada başladı. Mevcut TF'de yeni bir çubuk belirleyen bu fonksiyon uzun zaman önce yazılmıştır. Aniden buna ihtiyacım vardı, ancak yalnızca belirtilen TF'de tanımlayıcı olanı. Sorun değil. Yarım vuruşta, yeniden yazdım. Ama birdenbire sadece şu anki TF için tekrar ihtiyaç duyuldu... Ve bu fonksiyona neden PERIOD_CURRENT geçeyim, ama sorun değil, tekrar yazdım ve farklı isimlerde ikisi vardı.
Evet, ne kadarını yeniden yazabilirsin veya hangisini aramam gerektiğini hatırlayabilirsin. Ve aynı isimde ve farklı girdi parametreleriyle birden fazla fonksiyona sahip olmanın mümkün olduğunu anlayınca azabım sona erdi...
Kodumda hata olmadığı ortaya çıktı. Platformlar arasında bar konseptinde fark var.
Bu arada, çözümümde diziyi doldurma sıklığını değiştirirsem ve dakika başına bir duraklama yerine saniyede bir dönüyorlarsa, sorun tamamen çözülebilir. Aynı zamanda, sistem üzerindeki yükün artması olası değildir. Kontrol edebilirsin.
if(Dakika*Zamanlayıcı_Frekans >= 60000) ile if(Dakika*Zamanlayıcı_Frekans >= 1000) değiştirin.
Üzgünüm Peter, ama kodunuz sadece bir tür kaos.