Hatalar, hatalar, sorular - sayfa 1667
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
Tabii ki pek anlamıyorum, ama nedense farklı "sahipler" tarafından oluşturulan, aynı parametrelerle ve aynı grafikte üst üste bindirilmiş gösterge kopyalarının farklı tutamaçlara sahip olacağını düşünüyorum. Ve prensip olarak, göstergenin halihazırda var olan bir kopyasını bilmiyor olabilirler ve bilmemelidirler. Çizildiğinde, birbirleriyle örtüşürler.
Hatalı olduğumu tamamen kabul ediyorum. Ancak mantık, önceki paragrafta yazıldığı gibi olması gerektiğini öne sürüyor.
Tabii ki, ben bir MQ geliştiricisi değilim, ancak bu süreç bana anlatıldığı kadarıyla, hindilerin etkili bir şekilde önbelleğe alınması ilk beşte yapıldı, bu nedenle her zaman yalnızca bir "özdeş" hindi olacak ve birkaç " sahipleri" buna bir bağlantı alacak. Belki tutamaçlar farklı olacaktır - kontrol etmedim - ama içinde aynı varlık olacak. Hiç kimse "mevcut kopyayı bilmeleri gerektiğini" söylemedi - lütfen spekülasyon yapmayın. Kesinlikle, "sahip" dışında hiç kimse göstergelerini bilmiyor ve gösterge, farklı "sahiplerden" kendisine referanslar veriyor, ancak sahipleri tanımıyor.
Uygulamanın gösterdiği gibi, farklı insanların mantığı farklıdır. Örneğin benim mantığım çoğu zaman MQ'nun mantığıyla örtüşmez ama ben burada sadece onlardan duyduklarımı anlatıyorum.
Tabii ki, ben bir MQ geliştiricisi değilim, ancak bu süreç bana anlatıldığı kadarıyla, hindilerin etkili bir şekilde önbelleğe alınması ilk beşte yapıldı, bu nedenle her zaman yalnızca bir "özdeş" hindi olacak ve birkaç " sahipleri" buna bir bağlantı alacak. Belki tutamaçlar farklı olacaktır - kontrol etmedim - ama içinde aynı varlık olacak. Hiç kimse "mevcut kopyayı bilmeleri gerektiğini" söylemedi - lütfen spekülasyon yapmayın. Kesinlikle, "sahip" dışında hiç kimse göstergelerini bilmiyor ve gösterge, farklı "sahiplerden" kendisine referanslar veriyor, ancak sahipleri tanımıyor.
Uygulamanın gösterdiği gibi, farklı insanların mantığı farklıdır. Örneğin benim mantığım çoğu zaman MQ'nun mantığıyla örtüşmez ama ben burada sadece onlardan duyduklarımı anlatıyorum.
iMA, iAC, iMACD, iIchimoku, vb. gibi tüm işlevler, istemci terminalinin global önbelleğinde ilgili teknik göstergenin bir kopyasını oluşturur. Bu parametrelere sahip göstergenin bir kopyası zaten mevcutsa, yeni bir kopya oluşturulmaz, ancak bu kopyaya yapılan referansların sayacı artırılır.
Yürütme sırasında bir hata ile orijinal programa yakın bir test komut dosyası oluşturmak mümkün oldu
Sonuç: 'Script2.mq5' içinde geçersiz işlev işaretçisi çağrısı
1405 build. Kendi başına, bu hata kaldı - programın başka bir bölümüne geçiyorum - daha sonra çözeceğim
Ama daha önce var olmayan yenileri var.
Sonuç: geçersiz EX5 dosyası (8)Dizi öğelerini Shift+F9 hata ayıklamasında nasıl görünür hale getirebilirim?
Aslında, vakaların %99'unda IndicatorRelease çağrısı bir programcının mantıksal hatasıdır.
Gösterge oluşturmak, çok derin hesaplama mekanizmalarını tetikleyen en pahalı işlemlerden biridir. Gösterge tutamağını kapatmaya çalışmak, uygulamasının gerçek derin süreçlerini düşünüyorsanız, aynı zamanda çok pahalı bir işlemdir. Göstergelerin sık sık oluşturulması ve kapatılması, geliştiricinin işlemlerin özünü hiç anlamadığını gösterir.
Bunu anlamak çok basit.
Kullanıcının IndicatorCreate yerine iCustom kullanırken, IndicatorRelease sorumluluğunu geliştiricilerin evrensel (ve dolayısıyla optimal olmayan) çözümüne kaydırdığını doğru anlıyor muyum?
Oluşturulan göstergelerin belirli bir sıklıkta erişilirken bir süre saklandığı. Bir süre arama olmazsa, zorunlu bir IndicatorRelease vardır. Doğru?
Onlar. iCustom, uygulama karmaşıklığı ve performans arasındaki altın ortalama açısından kullanım için idealdir. Ancak, maksimum hız istiyorsanız, gösterge kullanımınızın özelliklerini bilerek, kendi daha hızlı (evrensel değil) gösterge depolama algoritmanızı oluşturarak her şeyi IndicatorCreate aracılığıyla yapmaya çalışmak daha iyidir.
doğru mu anladım
Kullanıcının IndicatorCreate yerine iCustom kullanırken, IndicatorRelease sorumluluğunu geliştiricilerin evrensel (ve dolayısıyla optimal olmayan) çözümüne kaydırdığını doğru anlıyor muyum?
Oluşturulan göstergelerin belirli bir sıklıkta erişilirken bir süre saklandığı. Bir süre arama olmazsa, zorunlu bir IndicatorRelease vardır. Doğru?
Onlar. iCustom, uygulama karmaşıklığı ve performans arasındaki altın ortalama açısından kullanım için idealdir. Ancak, maksimum hız istiyorsanız, gösterge kullanımınızın özelliklerini bilerek, kendi daha hızlı (evrensel değil) gösterge depolama algoritmanızı oluşturarak her şeyi IndicatorCreate aracılığıyla yapmaya çalışmak daha iyidir.
doğru mu anladım
Hayır, yanlış.
Her iki işlev de tamamen eşdeğerdir. Her iki işlev de gösterge tutamağını döndürür
Hayır, yanlış.
Her iki işlev de tamamen eşdeğerdir. Her iki işlev de gösterge tutamağını döndürür
iCustom'dan sonra IndicatorRelease yapmalı mıyım?
Prensip olarak, MT5'te MT4 Uzman Danışmanlarını çalıştırmanın oldukça mümkün olduğu ortaya çıktı. Diğer göstergeleri dahili olarak kullanmayanlar için oldukça basittir. Kullanımlar - MT4-iCustom depolamanın bir analogunu oluşturarak tamir edin. Verilerin hazırlanamaması sorunlarını da çözmek oldukça mümkündür.
Böyle bir bağdaştırıcı yazın ve herhangi bir MT4 göstergesi MT5'te başarıyla başlatılacaktır. Ama sonra Nikolai Kositsyn işini kaybedecek ... hayır, istemem.
iCustom'dan sonra IndicatorRelease yapmalı mıyım?
Prensip olarak, MT5'te MT4 Uzman Danışmanlarını çalıştırmanın oldukça mümkün olduğu ortaya çıktı. Diğer göstergeleri dahili olarak kullanmayanlar için oldukça basittir. Kullanımlar - MT4-iCustom depolamanın bir analogunu oluşturarak tamir edin. Verilerin hazırlanamaması sorunlarını da çözmek oldukça mümkündür.
Böyle bir bağdaştırıcı yazın ve herhangi bir MT4 göstergesi MT5'te başarıyla başlatılacaktır. Ama sonra Nikolai Kositsyn işini kaybedecek ... hayır, istemem.