MQL5 için dilekler - sayfa 18
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
Bu arada grafiklerle ilgili bir şey daha var mesela ben 1'e 1 skala kullanıyorum grafikte fiyat skalasının otomatik ayarlanması esin kaynağı olmuyor ama fiyat skalasını direkt görsel olarak değiştirmek çok uygun. Bu eylemin sonucu olarak farklı dönemlerden bahsedersek, döneme bağlıysa yoğunluk çok önemlidir. Ek olarak, MT4'teki çizelgelerin sınırlandırılması, ulaşılan fiyat ve tüm çizelgenin zamanında sona erer; bu, nesneleri çizerken tamamen elverişsizdir, çünkü gizlendikleri ortaya çıkar. 1'e 1 grafik, fiyat yoğunluğunda bir değişiklik olmaması dışında herkes için uygundur, bu koşullarda dikey fiyat ölçeği yatay bir zaman ölçeği ile ilişkilendirilir. Ayrıca, otomatik denkleştirme 1'e 1 ölçeğinde dikey fiyat oranını hesaba katmaz. Otomatik denkleştirme yalnızca zamana göre çalışır. Ek olarak, özellikle yeterince büyük bir ekran çözünürlüğünde, farklı girintiler farklı enstrümanlar için farklı girintiler gerektirebileceğinden, mevcut zamanın girintisini grafiğin sonundan değiştirilebilir yapmak daha iyi olacaktır. Fiyat ve zaman ölçeği ayarlama alt bölümü bence hem ayrı hem de birlikte yapılandırılmalıdır. Ek olarak, ölçeklendirmenin kendisinin çok sınırlı olduğunu söyleyebilirim, birkaç ölçek seçeneği, daha ince ayar veya bu seçeneklerin düzenlenmesi bir seçenek veya yüzdenin tam bir tanımlamasını verir.
Daha da derine inerseniz, alfa kanalı ve kenar yumuşatma kullanımı, örneğin bir pikselin onda birini veya daha doğrusu bir rengin onda birini kullanarak aynı çizgileri çizme kalitesini artırmanıza olanak tanır. çarpıcı olmak, bu benim gibi grafik arayüzün gurmeleri için daha olası olsa da, onsuz yapabilirim, ancak onsuz yapamam, yüksek kaliteli arayüzleri damgalamayı seviyorum (.NET 3.0 Presentation Framework ):) Tabii ki bir şey demiyorum, belki şu anki duruma benzer bir şey MFC'de zaten uygulandı, son yenilikleri incelemedim.
xnsnet'i "henüz .NET / Visual Studio'dan ( uygulamalı yazılımlar için) daha iyisi yok" anlamında destekliyorum.
Herkesin Microsoft'un yetenekleri yoktur ve bir "mucize" görmemiz olası değildir :)
Editör.
C++ Builder 6 / Delphi 7 seviyesine "tutarsak" - bu bir mucize olacak.
Sevgili geliştiriciler, lütfen anahat oluşturmayı/daraltmayı unutmayın. (Okumaya söz verdiniz!)
Dilim.
Dile gelince, senin yerinde olsam (biliyorum, biliyorum - herkes buralara kadar büyümedi :) ), C#'ı temiz yırtardım.
C++ uzmanları ne derse desin, "OrderType.Buy" saf "OP_BUY" dan daha uygundur (%100, Win95/Win98'de olduğu gibi hala "klasik" ana menüye sahiptirler). İki katı uzun olsa bile.
C# stilinde Enum o kadar sıradan ve kullanışlı ki, 10-15 yıl önce ortaya çıkmamasına şaşırıyor. (Herhangi bir yerde ortaya çıktıysa, yayılmadı !)
Beyler "SINIF" diyen geliştiriciler, "ŞABLONLARI" unutma! Bence bu olmazsa, bu konuyla ilgili birçok dilek hemen düşecek. Tabii ki, henüz sınıflar/yapılar yok - ne tür şablonlar var. .. Ama nasıl görünecekleri, soru hemen ortaya çıkacak. Dil programcıya yönelik gibi görünüyor ve programlamadaki kalıplar akrobasi olmaktan uzak.
Çeşitli.
Grafiğin olay penceresi, TWinControl/CWnd/System'in halefi gibi bir şeydir. Windows.Forms.Control/System::Windows::Forms::Control - vay, bu harika olurdu!
Ve arada...
Metaquotes Corp. herhangi bir üçüncü taraf .NET vb. kullanmaya çalışmaz. "Made by Metaquotes" etiketine sahip bir başka yumuşak şirketin çeşitlenmesini görmeyeceğiz. Veya en azından "Metaquotes tarafından desteklenmektedir"?... :)
Saygılarımla, pxx
Şablonlar C#'ta bir şeydir, ancak bunu uzun süredir, 2 tam yıldır ve 3.0 belirtimi de dahil olmak üzere çerçevelerde yazılan her şeyin uygulanması için üç yıl daha bekliyorlar.
Genel olarak, MQL4, C#'a çok benzer, ne yazık ki ilk sürüm değil.
Ve C#'daki şablonlar kesinlikle bir şeydir, dock ve kodum dışında bu tür şablon kullanımını hiç görmedim, ancak bunları uygulamak için neredeyse her şeyde hayal edebileceğinizden çok daha fazla yol var:
[DebuggerDisplay("Count = {Count}")]genel soyut sınıf ClhList<TList, TItem>: IList<TItem>
burada TList: ClhList<TList, TItem>
nerede TItem: ClhItem<TList, TItem> {
}
Genel olarak, C# spesifikasyonuna bakıldığında, gerçekliğe hala hayret ediyorum ve hata ayıklama ayrıştırıcısındaki kodu kontrol ettiğinizde, görüş neredeyse çarpıtılıyor :)
Ama tartışmaları körüklemem :) Birisinin MQ'nun üstesinden geleceğinden şüpheliyim, hatırladığım kadarıyla 500 $'a sadece bir müşteri satan mağdurlar olsa da, DC için yazılım maliyetinden bahsetmiyorum bile, kesinlikle sağlarlar. .NET'i kullanma olasılığı, ancak, böyle bir fiyat aralığında geliştirme, ah, ne kadar zor, özellikle de herkesin bedava kelimesiyle heyecanlandığı bizde. Diyelim ki rakipler kendi başlarına hayatta kalacaklar :) Nedense burada MQ'nun tarafındayım, muhtemelen bu kelimeye kendim de düşüyorum ya da belki bir vatansever, henüz çözemedim, ama orada içlerinde yerel bir şey :) Bu yüzden hemen olmasa da minimal bir geliştirme, uygulama için umut edeceğiz :)
Zaten başka bir iş parçacığında. Tekrarlıyorum.
1. Uzmanların yatırımcının şifresini devre dışı bırakmasını sağlayın. Bir yatırımcının şifresine sahip olduğunuzdan, bir uzmanın çalışmasını kısıtlama olmaksızın çoğaltabilirsiniz. Ayrıca böyle bir parolanın DC tarafından tehlikeye atılmaması da gereklidir. Varsa, terminal işlemini klonlamak için diğer fırsatları engelleyin.
2. Terminal sürümünü bildiren bir işlev ekleyin.
3. Harici değişkenlerin görüntülenmesini engelleyen bir işlev ekleyin.
4. Uzmanların dijital imza ile terminali benzersiz bir şekilde tanımlamasını sağlayın. İpuçlarına bakılırsa, terminalin zaten bir dijital imzası var. Buna uzmandan erişim vermeniz gerekir. Ardından, terminalin dijital imzasını uzman için lisansa girmek mümkün olacaktır.
5. Bir DC'nin dijital imza ile tanımlanmasını etkinleştirin. Bu, dolandırıcılığa karşı korumayı artıracaktır.
6. MQL'ye http desteği ekleyin.
Dolandırıcılık riskini azaltmak için, sunucuların (terminallerin) dijital imzalarının halka açık bir deposunun oluşturulması arzu edilir. İdeal olarak, her terminal, toplu icq mesajları gibi bir sinyal dağıtıcısına dönüşebilmelidir.
xnsnet'i "henüz .NET / Visual Studio'dan ( uygulamalı yazılımlar için) daha iyisi yok" anlamında destekliyorum.
.....
Bu "mucize" PHP'nin yanında durmadı.
Oh-oh-oh, Kişisel Ana Sayfa Araçları dünyayı yönetiyor! ))))))))))))
Veya yeni bir şekilde "PHP: Hypertext Preprocessor"!
Sonsuza kadar betik dilleri!
Alıntı: Başlangıçta PHP, web sayfalarının geliştirilmesini kolaylaştırmak için Perl'e bir eklenti olarak oluşturuldu. ( https://ru.wikipedia.org/wiki/PHP ).
Orijinal "C", başlangıçta biraz farklı amaçlar için yaratılmıştır. ..))
Peki ya PHP'den "VirtualAlloc" veya "CreateFileMapping" çağrısı yapmaya ne dersiniz, kimse size söylemeyecek? :)
Üçüncü taraf nedenlerle savaşları karıştırmayın, Perl gibi PHP, yorumlayıcı tarafından doğrudan kaynak kodundan uygulanan komut dosyalarıdır, .NET çok platformlu ve çok işlevli bir bayt kodu mimarisidir, çok dillidir, Linux'ta analogu Mono neredeyse çok platformda uygular RTOS hariç herhangi bir eksen. Farklar oldukça önemlidir ve amaçlar farklıdır, tıpkı PHP'de bir kullanıcı arayüzü ile bir program yazmak ve C/C++ ile bir web uygulaması veya hizmeti yazmak gibi. Daha fazlasına ihtiyacınız var ve daha çok .NET gibi, Java da var, ancak Java ile her şey daha zor, bir zamanlar analogları olmamasına rağmen, Flash da bir nedenden dolayı yaratıldı, ama burada .NET tam orada, Sonuç olarak, XBAP'tan bahsetmeden Silverlight belirir. Bana şimdi .NET'in nerede kullanılmadığını ve bu koşullarda ne kadar rekabetçi olduğunu söylesen iyi olur? Ve biliyorsunuz ki bazı insanlar hala bir programı C++'a çevirmek için Java Yorumlayıcısının uygulanmasıyla uğraşıyorlar, neden olduğu anlaşılıyor, ama böyle bir şey var. Her zaman, insanlar program kodunu küreselleştirme, her koşul için daha uygun hale getirme sorununu çözmeye çalıştılar, ancak ilk olarak, insanların seçilen dile bağlılığı var ve ikincisi, çok platformlu, sonuç olarak .NET, tüm bunlar arasındaki bağlantı. .NET halefi olmaya hazır düzinelerce dil var, çerçevelerde kullanılabilen birçok teknoloji var, bunlar sadece sarmalayıcılar, ancak tüm bunlar orada ve sadece sarmalayıcılar görünmüyor. Ve şimdi tüm bunları desteklediğiniz o dar yönle karşılaştırmaya çalışın, karşılaştırmaya çalışıyorsunuz, bunu reddetmeniz gerektiğini söylemiyorum, sadece karşılaştırmanız gerekir, vatanseverlik elbette iyidir, ama sadece görenler için, kim görür ve başka bir fikrin özünü, bu yüzden yöntemlerin seçimine saygı duymalısın, yoksa bir gün işsiz kalabilirsin :) .NET mimarisinde MQL dilini hayal etmeye çalış, değil mi? Güvenliği mi düşünüyorsun? Kriptografi kullanıyor musunuz? .NET'te uzun süredir uygulanmakta olan aynı ilkeleri uygulamak için ne kadar çaba harcıyorsunuz? Karşılaştırma ve tekrar karşılaştırma, hatalar ve delikler de karşılaştırılmalıdır.
.NET yönüne gittiğim için çok şey kaybettim, tanıdıklar ve arkadaşlar çemberi (şimdi onlarla iletişim kuracak hiçbir şeyim yok), çok zaman, ama daha da fazlasını kazandım, ana şey gelişme :) , asıl mesele yeni bir tane icat etmek değil :) Tabii ki beyin yıkama için özür dilerim, ama onsuz hiçbir yerde :)
Bu "mucize" PHP'nin yanında durmadı.
Oh-oh-oh, "Kişisel Ana Sayfa Araçları" dünyayı yönetiyor! ))))))))))))
Veya yeni bir şekilde "PHP: Hypertext Preprocessor"!
Sonsuza kadar betik dilleri!
Alıntı: Başlangıçta PHP, web sayfalarının geliştirilmesini kolaylaştırmak için Perl'e bir eklenti olarak oluşturuldu. ( https://ru.wikipedia.org/wiki/PHP ).
Orijinal "C", başlangıçta biraz farklı amaçlar için yaratılmıştır. ..))
Peki ya PHP'den "VirtualAlloc" veya "CreateFileMapping" çağrısı yapmaya ne dersiniz, kimse size söylemeyecek? :)
2. http://www.php.net/manual/ru/ adresinde PHP'nin olanaklarına bakmak için küçük bir istek, böylece ne hakkında olduğunu bilirsiniz.
3. Diğerlerinin aksine, en iyisini alır (hem C'den hem de Lisp'ten ve Perl'den ve diğerlerinden).
4. ...Script dilleri - hafızam bana hizmet ediyorsa (ve beni asla başarısızlığa uğratmıyorsa), VB, Delphi ve diğerlerinin ataları böyleydi.
5. Ayrıca, Delphi'nin bacakları Pascal'dan büyür - şimdi ölü bir adam.
6. "VirtualAlloc" veya "CreateFileMapping" çağrılmasıyla ilgili olarak... - Delphi'de rar_close var mı? :))
7. .NET - kimin küçük yumuşaktan hoşlandığını sorun?
7. .NET - kimin küçük yumuşaktan hoşlandığını sorun?
Bu arada, evet...
Ana şey, MKL5'in Şarapta boğulmaması;)))