Benim yaklaşımım. Çekirdek - Motor. - sayfa 124
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
Çünkü OrderOpenPrice yerine OrderOpenTime() koymanız gerekiyor.
Aynen öyle. Kafası karışmış. :)
İtiraf etmeliyim ki test sonuçları beni biraz şaşırttı.
İşte tam da bu yüzden her şeyi kendin yapmanı ve duvardaki bezelye gibi hazır çözümler vermemeni istedim.
İşlev işaretçilerini duydum. Ancak çok az özelliğim var. Bu nedenle boşluk yoktur ve OOP kullanmaya gerek yoktur.
Farklı bir geliştirme konseptim var . Bütünsel çok işlevli blokların çalışmasının, küçük işlevlerin büyük komplekslerinden daha etkili olduğuna inanıyorum.
Mekanizmaların gelişimi açısından daha umut verici.
Bu benim görüşüm...
Birkaç büyük bloğum var. OOP'yi uygulamak için küçük işlevlere ayrılmaları, sınıflar halinde organize edilmeleri ve ardından işaretçiler ve diğer şeyleri kullanmaları gerekir.
Ama bunu yapamayacağım. Sadece farklı düşündüğüm için.
OOP kavramı, benim düşüncemin özellikleriyle örtüşmüyor ve onun içinde geri dönemem. Sebep bu.
Not, Nikolay, yazılım geliştirme konusunda hiçbir sorunum yok. Her şey çok hızlı gelişiyor.
Aynı zamanda, mekanizmalar normal şekilde çalışır.
Şimdi sendikalarda uzmanlaştım ve bunların kullanımını belirli bir görevde görüyorum - bir kaynağa dizeler yazmak.
EA testinde işlemcinin hızını ve yükünü kontrol etmeye çalışacağım ve sonucu göndereceğim.
İyiyse, hareketle danışman arasındaki bağlantıyı kaynaklara dayanarak yeniden kuracağım.
Belirsiz uzunluktaki dizileri transfer etmek için kaynakları kullanmak için, bu diziler bir char dizisine yazılmalıdır.
Ancak, boyutlarının yalnızca birlik içinde bildirildiği ve daha sonra değişmediği görülüyor.
Birlikten char dizisinin boyutunu ArrayResize aracılığıyla değiştirmeye çalıştım, ancak hiçbir etkisi yok.
Görünüşe göre char dizisinin boyutunun önceden ayarlanması gerekiyor. Ve maksimum olmalıdır.
İşte kod:
Şimdi, birleşimdeki char dizisinin boyutunun önceden bilinmesi gerektiği kesin olarak açıktır. Çünkü ArrayResize (u.Char, StrSize ) onu değiştirmez.
Bu nedenle, dizinin boyutunu maksimum dizenin uzunluğuna eşit olarak ayarlamanız gerekir...
İyi haberler. Her şey iyi çalışıyor.
Dize kaynağa yazılır ve başka bir EA tarafından başka bir çizelgede okunur.
İşlemciye yük binmiyor. Yük sadece hattı yazdıran Uyarının çağrısı ile verilir.
İşte danışman kodu:
1. Bir dizi oluşturan ve onu kaynağa yazan bir Uzman Danışman.
Başka bir grafikteki bir kaynaktan bir satır okuyan bir EA:
Kaynakları iletişim için kullanacağım. Tek dezavantajı, birleşimdeki char dizisinin maksimum boyutunu ayarlamanız gerektiğidir. Öte yandan, dizenin boyutunu ve MT nesnelerinin sayısını düşünmenize gerek yoktur.
Bu yöntem, MT nesneleri aracılığıyla iletişim yönteminden daha yavaştır, ancak oldukça uygundur.
Şimdi aşağıda açıklayacağım deneylerimin sonuçlarıyla tam olarak örtüşmese de, ilginç bir teoriniz var.
Testin gösterdiği gibi, işlemciyi en çok yükleyen piksel dizisinin başlatılmasıdır.
Aşağıdaki EA testine göz atın.
Sorunu okuyun:
Vasili Sokolov :
Peter, işte görev. MT4'te mevcut sipariş açılışlarını gösteren bir panel yapın. Sistem panelinin tam bir kopyasını oluşturmanıza gerek yok, açık siparişlerin temel özellikleriyle en basit tabloyu görüntüleyin: açık fiyat , yön, kâr. Gerisi size kalmış. Ana şey, bir siparişi kapattığınızda, tablonuzdaki görüntüsünün de kaybolmasıdır. Ve tam tersi, yeni bir sipariş açarken bu tabloda görünecektir.
Burada, ekrandaki tabloyu değiştirirken gerekli iki yeniden çizim işlemini görebilirsiniz: 1. bir anlaşmayı kapatırken ve 2. bir anlaşmayı açarken. Neden zamanın geri kalanında pikselleri yeniden çizelim?
Başka bir problem mi çözüyorsun?
Sorunu okuyun:
Vasili Sokolov :
Burada, ekrandaki tabloyu değiştirirken gerekli iki yeniden çizim işlemini görebilirsiniz: 1. bir anlaşmayı kapatırken ve 2. bir anlaşmayı açarken. Neden zamanın geri kalanında pikselleri yeniden çizelim?
Başka bir problem mi çözüyorsun?
Yani aynen dediğin gibi yeniden çiziliyorlar.
Ve işlemci üzerindeki yük, animasyon sırasında oluşur:
Burada piksel dizisindeki değerlerin sürekli olarak yeniden başlatılması var. Her 16 milisaniyede bir. Bu, işlemciyi %40'a kadar yükler.
Tam olarak neyin yüklendiğini anlamaya çalıştım. Kaynağı kaydetmeyi veya okumayı düşündüm. Çizim döngüsündeki dizinin yeniden başlatılması olduğu ortaya çıktı.
Ayrıca, ObjectSetInteger(0,"MT object",OBJPROP_SELECTED,1); öğesine yapılan sürekli çağrının; (Her 16 milisaniyede bir) işlemciyi de yükler. Yaklaşık %10.
Bu çağrıyı, başka bir EA'ya animasyon verileriyle bir kaynağı okuması gerektiğini söylemek için kullanıyorum.
Toplamda, animasyon sırasında işlemci üzerindeki yükün + ~% 50'si ortaya çıkıyor.