[Arşivle!] Forumu kirletmemek için herhangi bir acemi sorusu. Profesyonel, kaçırmayın. Sensiz hiçbir yerde - 2. - sayfa 486
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
global_trailing_SP global değişkenini nasıl okuduğunuzu gösterin
Ancak, ana konum hatasız izlendiğinden, bununla ilgili herhangi bir sorun yoktur. Problem aynı değeri başka pozisyon(lar)a atamak.Şu anda, ana konum için takip, ATR tarafından şu şekilde hesaplanır:
Yani anlamadım. Ana siparişin değiştirildiği sırada bekleyen bir sipariş var mı?
Varsa, ana siparişin değiştirilmesi ve bekleyen siparişin değiştirilmesi bir blokta gerçekleşir. Ve eğer ana emir değiştirildiyse, o zaman, eğer öyle istiyorsanız, bekleyen emir de değiştirilmelidir.
Başka bir şey, planlananın işe yaramadığıdır. Yani durumda bir hata var. Yukarıda gösterdiğim gibi, ana sırayı değiştirme koşuluyla her şeyi aynı şekilde yapmaya çalışın. Bana mantık hatası gibi geliyor. Şaşırtıcı değil. Bir şey senin için zor. Yapması daha kolay.
Daha kolay olması mümkündür. Bu deneyimsizlikten kaynaklanıyor.))
Şu anda, ana konum için ayrı bir işlev izliyor. Daha sonra, bekleyen emirler veya başka büyülerle başka pozisyonlar varsa, ana büyünün durdurulmasıyla değerleri kontrol edilir. Ve eğer farklılarsa, ana değer alınır.
Şaşırtıcı değil. Bir şey senin için zor. Yapması daha kolay.
Kolaylaştırdı. Sorun ortadan kalktı gibi görünüyor. Teşekkürler.)))
Gecikme chtoli değiştirildi mi? :)
El yazısının değiştirilmesi gerekiyor. El yazısı ne kadar net olursa, o kadar az hataya izin verilir. Her şeyi mümkün olduğunca az değişken ve her türlü gereksiz şeyi tek bir yığına sokmamaya çalışın. Blokların açıkça görülebilmesi için her zaman yeni bir satıra kaşlı ayraçlar yazın.
Gecikme chtoli değiştirildi mi?
Evet, yukarıdaki işlevde, ATR tarafından takip edilir, sihir denetimi hariç tutulur ve gecikmeler eklenir:
if (OrderType() == OP_SELL || OrderType() == OP_SELLSTOP)
El yazısının değiştirilmesi gerekiyor. El yazısı ne kadar net olursa, o kadar az hataya izin verilir. Her şeyi mümkün olduğunca az değişken ve her türlü gereksiz şeyi tek bir yığına sokmamaya çalışın. Blokların açıkça görülebilmesi için her zaman yeni bir satıra kaşlı ayraçlar yazın.
Evet, yukarıdaki işlevde, ATR tarafından takip edilir, sihir denetimi hariç tutulur ve gecikmeler eklenir:
Evet. Bu doğru, sadece Magic hakkında konuşmak istedim. İşte görüyorsunuz. Ekstra değişkenler işe yaramaz. Görüşürüz.
Evet. Bu doğru, sadece Magic hakkında konuşmak istedim. İşte görüyorsunuz. Ekstra değişkenler işe yaramaz. Görüşürüz.
akıllıca düşünce - "ekstra değişkenler işe yaramaz"
ve magick "işe yaramaz" - neden magick için arama emrini kontrol edin?
Pekala, başka bir danışmandan gelen bir siparişi değiştirirseniz, sorun değil.
genel olarak, sihirbazı bir sınıf olarak dışlamak için - geliştiriciler boşuna tanıttı - sadece zaman kaybettiler - ve beyinlerimiz her türlü sihirbazla doluydu
ps Evet ve dansçı, o zaman arada ne var - kesmek daha iyi
akıllıca düşünce - "ekstra değişkenler işe yaramaz"
ve magick "işe yaramaz" - neden magick için arama emrini kontrol edin?
Peki, başka bir danışmandan gelen bir siparişi değiştirirseniz, sorun değil.
genellikle sihirbazı bir sınıf olarak hariç tutun
)))) Hayır, sihirbazdan ayrılmak daha iyidir. Ve sadece bekleyen emirleri bırakın.
Daha doğrusu, ihtiyaç duyulan büyüleri bırakın. Ve farklı tablolarda birden fazla Uzman Danışman kullanılıyorsa, kontrole sembolleri de dahil etmeniz gerekir. Ama henüz buna gelmedim. ))
Ben hiç sihir kullanmıyorum. Her ne kadar birkaç pozisyon olsa da. Bilet kullanıyorum. OrderSelect ile kontrol etmek çok daha kolay. Ve OrderSend işlevi daha net hale gelir. Eh, herkes kendi el yazısının ustasıdır. Şahsen, sihirbazlar olmadan hiç problem yaşamadım.
Bilet hiçbir yere gitmiyor. Onunla rahat.