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
Alıntıların gelmesinden bağımsız olarak çubukların açıldığını zaten yanıtladım. Teklif yoksa, yeni çubuğun fiyatı bir öncekinin kapanış fiyatı olacaktır. Yeni bir çubuğun gerçeği, bir zamanlayıcı üzerinde çalışan sayaçların kendileri tarafından, tekliflerin gelmesinden bağımsız olarak kaydedilecektir.
Belirli bir zaman çerçevesi önemli değil, çünkü bu yalnızca değerine ulaşan bir sayaç ve o zaman çerçevesinin yeni çubuk olayı ayarlandı. Bu, yalnızca farklı zaman dilimlerindeki yeni çubukların görünümüyle bir senkronizasyon yöntemidir. SENK.
Alet de önemli değil. Eğer alıntılar aynı sunucudan geliyorsa, yeni çubukların aynı görünüm zamanına sahip oldukları anlamına gelir. Dolayısıyla bu aletler dünyanın bir noktasından olduğu sürece hangi alet olduğunun bir önemi yoktur.
Söylediklerimi bitirip diğer şeylere geçeceğim. Güzel şeyler küçük paketlerde gelir.)
Samimi olarak.
PS Yeni bir barın oluşumu, yeni bir bar açmanın bedeli olan yeni bir tick'in gelmesiyle başlar. Algoritmanızda, yeni bir tick'in gelmesiyle ilgisi olmayan bir zamanlayıcı hesaplaması var, bu nedenle anlaşmazlık. Aslında, algoritmanız yeni bir çubuk açma gerçeğini değil, çubukta ilk teklifi bekleyebileceğiniz zamanın başlangıcını verir.
Sizde var, algoritmanızda çubuğun açık olduğu kabul ediliyor. Aslında - fiziksel olarak - henüz terminalde değil. Bu, sunucunun gerçekleriyle tam bir tutarsızlıktır.
Spesifik TF de önemlidir.
Aracın yanı sıra - birden çok para birimi programlarına yaklaşan herkes bunu bilir.
Sizi yönlendirdiğimiz sonuca - görsel olarak ve somut, somut bir örnek kullanarak - gelmek istememeniz üzücü.
Yeni bar olayı için hangi sembolün olduğunun bir önemi yok. Farklı sembollerden oluşan yeni çubuklar eşzamanlı olarak görünür (her zaman çerçevesi için).
Zamanlayıcının her zaman dilimi için kendi sayacı vardır. Sayaç kendi zaman diliminin değerine ulaştığında sıfırlanır ve bu zaman diliminde yeni bir bar olayı ayarlanır.
Ayrıca, işlevin çağrılması, geçerli çubuk sırasında bir kez yeni bir çubuğun olayını döndürür.
Bunun için hepinize teşekkür ederim ve hoşçakalın.
Yeni bar olayı için hangi sembolün olduğunun bir önemi yok. Farklı sembollerden oluşan yeni çubuklar eşzamanlı olarak görünür (her zaman çerçevesi için).
Zamanlayıcının her zaman dilimi için kendi sayacı vardır. Sayaç kendi zaman diliminin değerine ulaştığında sıfırlanır ve bu zaman diliminde yeni bir bar olayı ayarlanır.
Ayrıca, işlevin çağrılması, geçerli çubuk sırasında bir kez yeni bir çubuğun olayını döndürür.
Bunun üzerine çiğnemeyi bitirdim.
Hepinize teşekkürler ve hoşçakalın.
Çiğnemiyorsunuz - mantığınız açık. Ama ne yazık ki yanılıyor. İşlem ortamından - sonuç olarak sunucudan - veri almak gerekir.
Ve sunucuda yeni bir fiyat teklifi yoksa, terminalde yeni bir çubuk açılmaz.
Bir zamanlayıcıda çalışan algoritmanız, piyasa kapandığında yeni çubukları "damgalayacaktır". Ancak sunucuda ve buna göre terminalde değiller.
Ve inanın bana, farklı semboller için tırnakların gelişindeki fark, yeni bir çubuğun açılmasında bir fark yaratır - yeni bir çubuk oluşturmanın başlangıcı, yalnızca zamanına karşılık gelen bir onay işaretinin (alıntının) gelmesiyle etkinleştirilir. bu çubuk. M1'deki son çubuğun kapanmasından 4 dakika 15 saniye sonra kene geldiyse, üzerine inşa edilecek bir teklif olmadığından üç çubuk atlanacaktır.
Sana bir ipucu verdim .
Hatalısınız.
Samimi olarak.
PS Yeni bir barın oluşumu, yeni bir bar açmanın bedeli olan yeni bir tick'in gelmesiyle başlar. Algoritmanızda, yeni bir tick'in gelmesiyle ilgisi olmayan bir zamanlayıcı hesaplaması var, bu nedenle anlaşmazlık. aslında, algoritmanız yeni bir çubuk açma gerçeğini değil, çubukta ilk teklifin gelmesini bekleyebileceğiniz süreyi verir.
Evet, bir zamanlayıcıda. Alıntı olmadan bile yeni bir çubuk görünür. Bar görünüm olayıyla ilgileniyoruz ve alıntıyı OnTick()'te düzeltebiliriz;
Çubuk yine de görünecektir. Hafta sonuysa ve bar yoksa, o zaman korkutucu değil. İşlev başarısız olmayacak ve oturum başladığında, çubukların gelişiyle hala senkronize olacaktır.
Çiğnemiyorsunuz - mantığınız açık. Ama ne yazık ki yanılıyor. İşlem ortamından - sonuç olarak sunucudan - veri almak gerekir.
Ve sunucuda yeni bir teklif yoksa, terminalde yeni bir çubuk açılmaz.
Bir zamanlayıcıda çalışan algoritmanız, piyasa kapandığında yeni çubukları "damgalayacaktır". Ancak sunucuda ve buna göre terminalde değiller.
Ve inanın bana, farklı semboller için tırnakların gelişindeki fark, yeni bir çubuğun açılmasında bir fark yaratır - yeni bir çubuk oluşturmanın başlangıcı, yalnızca zamanına karşılık gelen bir onay işaretinin (alıntının) gelmesiyle etkinleştirilir. bu çubuk. M1'deki son çubuğun kapanmasından 4 dakika 15 saniye sonra kene geldiyse, üzerine inşa edilecek bir teklif olmadığından üç çubuk atlanacaktır.
Sana bir ipucu verdim .
Evet, bir zamanlayıcıda. Alıntı olmadan bile yeni bir çubuk görünür. Bar görünüm olayıyla ilgileniyoruz ve alıntıyı OnTick()'te düzeltebiliriz;
Çubuk yine de görünecektir. Hafta sonuysa ve bar yoksa, o zaman korkutucu değil. İşlev başarısız olmayacak ve oturum başladığında, çubukların gelişiyle hala senkronize olacaktır.
Samimi olarak.
Artyom Trishkin :
Ve inanın bana, farklı semboller için tırnakların gelişindeki fark, yeni bir çubuğun açılmasında bir fark yaratır - yeni bir çubuk oluşturmanın başlangıcı, yalnızca zamanına karşılık gelen bir onay işaretinin (alıntının) gelmesiyle etkinleştirilir. bu çubuk. M1'deki son çubuğun kapanmasından 4 dakika 15 saniye sonra kene geldiyse, üzerine inşa edilecek bir teklif olmadığından üç çubuk atlanacaktır.
Bu soruya gelince, bence yanılıyorsunuz. Lütfen servis masasında kontrol edin. Soruyu doğru bir şekilde cevaplamalarına izin verin: tekliflerin gelmesinden bağımsız olarak platformda yeni çubuklar oluşturuldu mu? Değilse, yeni bir çubuk durumunda, üzerinde bir teklif olup olmadığını kontrol edin. Öyle olsaydı, ama yeni bir bar oluştu. Öyle olabilir. Çok değiştirmenize gerek yok.
Diyelim ki yeni bir çubuğun başlaması durumunda 1. ve 2. çubuklardaki gösterge okumalarını almak istiyorsunuz. Algoritmanızın mantığına göre, teklif gelmeden yeni bir çubuğun başlangıcını alacaksınız ve çubuk grafikte belirecek, sonuç olarak gösterge okumalarını okumaya çalıştığınızda, aşağıdaki değerleri alacaksınız. Teklif geldiğinde 1 ve 2 çubuk olması gerektiği gibi, ancak 1 ve 2 çubuk değerleri, teklif geldiğinde yeni fiyat teklifi geldiğinde 1 çubuk hareket edecek ve 2 ve 3 çubuk olacaktır. bu açıkça danışmanın çalışmasını etkileyecektir.
Samimi olarak.
Belki. Yeni bir çubuğun her etkinliğine bir teklifin gelişi için bir kontrol ekleyin ve hepsi bu kadar. Yeni bir bar olayıyla değil, örneğin bir bar ve alıntı olayıyla çalışın.
Samimi olarak.
OnTick()'ten alıntılar alın. Yeni bir bar açma olayını, bir teklifin gelişinin onayı ile ilişkilendirebilirsiniz. Bunu yapmazdım. Ama bu herkes için kişisel bir meseledir.
Fiyat teklifi almayı biliyorum :)
Çoklu para birimi programında - gerekli semboller arasında bir döngüde bir zamanlayıcıda. Ve yeni bir çubuğun açılması (sizinki gibi fiziksel, sanal değil - hatalı -) son alıntı zamanı ve bu zamanın sembolün sıfır çubuğunun zamanı ile karşılaştırılması ile kontrol edilir.
Bunu rastgele yaparsınız - var olmayabilecek sanal bir çubuk. Hafta sonları müsait değiller, ama iddiaya göre sizde var - bu örnek olarak gösterilebilecek en basit şey.
Ve bunu tek başına yapmayacağını anla. Gerisi doğru ve güvenli olanı yapar. Ama bu, elbette, sadece kendi işiniz.
Size bunu nasıl doğru yapacağınızı anlatmak ve aynı problemi çözerken OOP'de yazmanın basitliği ve prosedürel stildeki karmaşık kıvrımlar ve dönüşler arasında büyük bir fark göstermek istedim.
Ama muhtemelen daha fazlasını biliyorsun ve buna ihtiyacın yok. Artık senin önünde bir şey biliyormuş gibi görünmeye cesaret edemiyorum. Afedersiniz.