![MQL5 - MetaTrader 5 müşteri terminalinde yerleşik ticaret stratejileri dili](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Boris, bunun böyle olduğunu varsayalım... Varsayalım. Ancak, fonksiyon bir emir değiştirme emrini yeniden gönderirse, değiştirilmesi gerekir. Ve hiç değiştirmiyorum. Logdaki loga baksak bile şunu göreceğiz:
Sipariş neden gönderiliyor? Eğer doğru parametrelere sahip değilse, fonksiyon lanetleyecektir... Ve sonra OK... gönderilmiş gibidir. Sonra bir hata olduğu ortaya çıktı.. Mantık nedir?Sadece açıldı! Victor, eğer "tamam" ise, o zaman bazı parametreler değişmiştir ve hata 1 almak, parametrelerden birinin değiştirilmesinin istendiği, ancak değiştirilmediği anlamına gelir. Bu yüzden bu tür durumlardan kaçınmak için mantığınızı düzeltmeniz gerekiyor, ancak gerçek hayatta tüm bu yanlışlıklar tekrar alıntılara ve bir sürü hataya dönüşecek!
Her şeyin farklı yerlere dağıldığı bu tür bir programlama kullanmadığımı biliyorsunuz. Programı mantıklı bir senaryo olarak yazıyorum, tüm olaylar sırayla gelişiyor ve her şey her koşulda gözümün önünde, bir şey aramak için didinmeye gerek yok. Son eylemi gerçekleştirmek ve hataları kontrol etmek için harici işlevleri kullanıyorum.
Ve acemiler için neye sahip olduğun ve nerede kontrol edildiği belli değil, her şey gizli, git tahmin et, gerekli koşulu geçtin mi, geçmedin mi?! Her nasılsa, şu anda sahip olduğum gibi çok fazla kelime var, ancak programınız özü aktarmıyor. Açık ve net olmalı!
Boris, elbette, her şeyin benim için tek bir yerde olmadığını anlıyorum. Ancak, değiştirme işlevinden hemen önceki giriş parametreleri yazdırılır. ekran görüntüsü attım. Mevcut ve yeni OOP, SL ve TP var. Ve hepsi farklı. Her şey yakındaysa neden ormana tırmanalım? Yazdırılırsa ve parametrelerin farklı olduğunu görebiliyorsanız, bunlar gerçekten farklıdır. Ya da belki baskıya güvenmemek?
Ve ondan önce, yukarıda gösterdiğim gibi bir kontrol var:
Ne kadar daha spesifik? Sonra yukarıdan birkaç palyaço masal yazmaya başladı. Görünüşe göre ne sorduğumu anlamak istemiyorlar ya da anlamak istemiyorlar. Yani sebepsiz yere gülüyorlar. Ve soru ilginç.
Sonuçta, örneğin farklı türde bir parametreyi veya yanlış numarayı veya hatta diğer seçenekleri OrderModify()'a gönderirseniz, hemen hatalar oluşur. Ve burada yürütülür, Tamam gibi yazar ve sonra hiçbir parametrenin değiştirilmediği ortaya çıkar.
Soru, orada neyin yanlış olduğunu nasıl bulacağımızdır? Sonuçta, işlevimi yayınladım. Orada her şey net olmalı. İşte burada:
Tüm satırları özellikle yorumladım. Kodu karıştırmak kolaydır. Herhangi bir yorumunuz varsa, lütfen yardım edin.
Boris, elbette, her şeyin tek bir yerde olmadığını anlıyorum. Ancak, değiştirme işlevinden hemen önceki giriş parametreleri yazdırılır. ekran görüntüsü attım. Mevcut ve yeni OOP, SL ve TP var. Ve hepsi farklı. Her şey yakındaysa neden ormana tırmanalım? Yazdırılırsa ve parametrelerin farklı olduğunu görebiliyorsanız, bunlar gerçekten farklıdır. Ya da belki baskıya güvenmemek?
Ve ondan önce, yukarıda gösterdiğim gibi, bir kontrol var:
Her şeyMaalesef bunu anlayamıyorum çünkü döngüdeki koşulları göremiyorum, bu da sipariş parametrelerinin birbiriyle karıştırılmamasını sağlıyor!
Bir hatanın varlığı, bir yerde mantıksal bir hata yaptığınızı gösterir. Ama aynı zamanda programın çalıştığını söylüyor ama biz programın kalitesiyle ilgileniyoruz!
Maalesef bunu anlayamıyorum çünkü döngüdeki koşulları göremiyorum, bu da sipariş parametrelerinin birbiriyle karıştırılmamasını sağlıyor!
Bir hatanın varlığı, bir yerde mantıksal bir hata yaptığınızı gösterir. Ama aynı zamanda programın çalıştığını söylüyor ama biz programın kalitesiyle ilgileniyoruz!
Emirli tüm işlemler bir döngüde gerçekleşir! Bu, kodunu yukarıda verdiğim fOrderModify() yönteminin çağrıldığı yerdir:
Orada her şey görülebilir... Döngünün her yinelemesinden sonra hatanın sıfırlandığı da açıktır. Bu, bir önceki siparişteki hatanın, eğer varsa, bir sonrakine atlamamasını sağlar (tabii değerini kastediyorum)
Nerede daha kolay olabilir? Burada herşey çok basit..
bir mesaj buldum
Aynı terminal hatası var. Hiç böyle bir şeyim olmadı. Çünkü Daha önce bekleyen emirlerin 3 parametresini (OOP, SL ve TP) aynı anda değiştirmeye çalışmadım. Bu yüzden aldı ... Ve bir hatayla karşılaştım.
Anladığım kadarıyla, örneğin açılış fiyatı ve stop loss değişmediyse ve bunların yerine aynı değerler alındıysa, ancak alım değişti. Bu da bir hataya neden oluyor mu? Sonra belgelerin çarpık olduğu ortaya çıkıyor. Ve bu an desteklenmiyor ya da ne?
bir mesaj buldum
Aynı terminal hatası var. Hiç böyle bir şeyim olmadı. Çünkü Daha önce bekleyen emirlerin 3 parametresini (OOP, SL ve TP) aynı anda değiştirmeye çalışmadım. Bu yüzden aldı ... Ve bir hatayla karşılaştım.
Anladığım kadarıyla, örneğin açılış fiyatı ve stop loss değişmediyse ve bunların yerine aynı değerler alındıysa, ancak alım değişti. Bu da bir hataya neden oluyor mu? Sonra belgelerin çarpık olduğu ortaya çıkıyor. Ve bu an desteklenmiyor ya da ne?
Her tikte mesafeyi de kontrol ediyor musun?! Uzun zamandır bir TF çubuğunun açılışında emir açmayı ve sadece M1'deki bir çubuğun açılışında değiştirmeyi ve kapatmayı bir kural haline getirdim! Yukarıdaki kod bana yapılan iş için her şeyin var gibi göründüğü, ancak belirli bir şeyin olmadığı bir raporu hatırlatıyor! Tüm eylemleri belirli koşullara göre tanımladığınız bir döngü görmüyorum! Sadece bana neyin değiştirilmesi gerektiğini söyleyen bir döngü görüyorum, sonra sadece değiştirmeyin ve hiçbir hata olmayacak.
Hatalarınızın küresel düzeyde yapılması gerekenler ve yerel düzeyde neler yapılması gerektiği konusundaki kafa karışıklığından kaynaklanabileceğine ve hataların her zaman sonuncusu olduğuna, öncekilerin, işlevden çıkıldığında katılımınız olmadan sıfırlandığına dair Renat'ın önemli açıklamasına dikkat edin. !
Her tikte mesafeyi de kontrol ediyor musun?!
Değil! Yalnızca koşul karşılandığında değişiklik yapma iznim var. Bu durumda, değişiklik koşulu, hesaplanan seviyelerde bir değişikliktir. Bunun gibi:
Sadece? Sadece....
Uzun zamandır bir TF çubuğunun açılışında emir açmayı ve sadece M1'deki bir çubuğun açılışında değiştirmeyi ve kapatmayı bir kural haline getirdim! Yukarıdaki kod bana yapılan iş için her şeyin var gibi göründüğü, ancak belirli bir şeyin olmadığı bir raporu hatırlatıyor! Tüm eylemleri belirli koşullara göre tanımladığınız bir döngü görmüyorum! Sadece bana neyin değiştirilmesi gerektiğini söyleyen bir döngü görüyorum, sonra sadece değiştirmeyin ve hiçbir hata olmayacak.
Ben de sadece M1'in açılışında değişiklik yapmak için benzer düşüncelerim vardı ve bu, değişiklik önceden belirlenmiş bir değerle gerçekleştirilirse geçerlidir. Ancak bu verileri M1'de kontrol etmem gerekmediği durumlar var. Örneğin, durağım zaten hesaplanmış bir seviyede takip ediyor. Ardından, yukarıda gösterdiğim gibi OnInit() işlevinde bir kontrolüm var:
Onlar. seviye değiştiyse, o zaman ... değişir. Bu sayede gereksiz modifikasyon girişimlerinden kurtulmuş oluyoruz. Tabiri caizse, bir zamanlayıcıyla değil, bir sinyalle değişiklik. Burası açık mı?Tüm eylemleri belirli koşullara göre tanımladığınız bir döngü görmüyorum! Sadece bana neyin değiştirilmesi gerektiğini söyleyen bir döngü görüyorum, sonra sadece değiştirmeyin ve hiçbir hata olmayacak.
Orada her şeyi yazdırdım. Neyi anlamıyorsun... :(
Hatalarınızın global düzeyde yapılması gerekenler ve yerel düzeyde neler yapılması gerektiği konusundaki kafa karışıklığından kaynaklanabileceğine ve hataların her zaman sonuncusu olduğuna, öncekilerin, fonksiyondan çıktığınızda katılımınız olmadan sıfırlandığına dair Renat'ın önemli açıklamasına dikkat edin. !
Ve yol boyunca karar verilmedi ve bunu çözmeyecekler. Belki geliştiriciler tembeldir? Hatalarla düzgün çalışmıyorsam, biri iş parçacığı oluşturursa, aynı Renat koda girebilir ve sadece benim sorunum olduğunu söylemekle kalmaz.
Sonunda modifikasyon fonksiyonundan önce değiştirilmesi planlanan parametrelerin yeni ve güncel değerleri yazdırılırsa bu değerlerin orada olduğu anlaşılır. Neden bir yerden daha yükseğe tırmansın? Değerler var, hata olmadığı açık (hatalar için orada yazdırdım). Yani mantıkta her şey doğru. Değişiklik işlevinde cant anlamına gelir.
Değil! Yalnızca koşul karşılandığında değişiklik yapma iznim var. Bu durumda, değişiklik koşulu, hesaplanan seviyelerde bir değişikliktir. Bunun gibi:
Sadece? Sadece....
Ben de sadece M1'in açılışında değişiklik yapmak için benzer düşüncelerim vardı ve bu, değişiklik önceden belirlenmiş bir değerle gerçekleştirilirse geçerlidir. Ancak bu verileri M1'de kontrol etmem gerekmediği durumlar var. Örneğin, durağım zaten hesaplanmış bir seviyede takip ediyor. Ardından, yukarıda gösterdiğim gibi OnInit() işlevinde bir kontrolüm var:
Onlar. seviye değiştiyse, o zaman ... değişir. Bu sayede gereksiz modifikasyon girişimlerinden kurtulmuş oluyoruz. Tabiri caizse, bir zamanlayıcıyla değil, bir sinyalle değişiklik. Burası açık mı?Orada her şeyi yazdırdım. Neyi anlamıyorsun... :(
Bu sorun, öğrendiğim gibi, sadece benim başıma gelmiyor. İşte bir örnek ...Ve bu yolda karar verilmedi ve bunu çözmeyecekler. Belki geliştiriciler tembeldir? Hatalarla düzgün çalışmıyorsam, biri iş parçacığı oluşturur, aynı Renat koda girebilir ve sadece benim sorunum olduğunu söylemekle kalmaz.
Sonunda modifikasyon fonksiyonundan önce değiştirilmesi planlanan parametrelerin yeni ve güncel değerleri yazdırılırsa bu değerlerin orada olduğu anlaşılır. Neden bir yerden daha yükseğe tırmansın? Değerler var, hata olmadığı açık (hatalar için orada yazdırdım). Yani mantıkta her şey doğru. Değişiklik işlevinde cant anlamına gelir.
Bu örneğe zaten baktım. Ama daha iyisi kalmayana kadar her koşula başvurmak zorundayız. Kodunuz beni ikna etmiyor. Şimdi öğle yemeği yiyeceğim, sonra SL'yi ayarlamak, kullanılmışa aktarmak ve hataların aniden ortaya çıkarsa işlendiği modifikasyon işlevine sadece bir çağrı için trol yapmak için açıkça işe yarayan bir döngü örneği vereceğim. operasyonda, test cihazında ortaya çıkmazlar.
Değiştir() işlevini istiyor musunuz?
Sonunda modifikasyon fonksiyonundan önce değiştirilmesi planlanan parametrelerin yeni ve güncel değerleri yazdırılırsa bu değerlerin orada olduğu anlaşılır. Neden bir yerden daha yükseğe tırmansın? Değerler var, hata olmadığı açık (hatalar için orada yazdırdım). Yani her şey mantıksal olarak doğru. Değişiklik işlevinde cant anlamına gelir.
Victor, işten çıkarmalarda neden SL ve TP'yi değiştirmeye başladın?! Genel olarak, SL'yi yalnızca bir pozisyon açtıktan sonra ve TP'yi SL'yi Kullanılmış'a aktardıktan sonra koymak mantıklıdır! Öyleyse neden sunucuyu bu kadar boş yere rahatsız ediyor ve bu eziyete ihtiyacınız var?!
Kodun hızlı ve net bir şekilde çalışması için minimuma indirilmesi ve basitleştirilmesi gerekiyor ve ardından piyasanın kaprisleri nedeniyle düzeltmesi daha kolay olacak! Piyasanın gerçekleriyle ilgili tüm nüansları dikkatlice düşünün!