Benim yaklaşımım. Çekirdek - Motor. - sayfa 170
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
Ölüyorum :)))
Aferin, sen ****** raftan bir turta al.
Tamam, açıklamaya çalışacağım:
Çözümünüzü izlerseniz, kullanıcının yine de statik sınıfın kaynak kodunu projeye kopyalaması gerekir; bu, olayları yayınlayacak, formu ayrı bir iş parçacığında çalıştıracak vb. Ek olarak, formu bu sınıfa statik olarak bağlamanız gerekecek, yani. sınıf formunun ve bileşenlerinin adını açıkça girin. Onlar. form değiştiğinde veya bir öğe eklendiğinde katman kodunuzu açıkça değiştirin. Başka bir deyişle, basit ve doğrudan bir çözüm, gösterdiğiniz gibi belirli bir formla etkileşimi göstermek için iyi çalışacaktır. Genelleştirilmiş durumda, yaptığım şey olan kontrol mantığını ve ekran mantığını ayırmak daha iyidir. Ayrıca bu ayırma, denetleyiciyi vasıfsız değişikliklerden korumanıza olanak tanır.
İşte neden böyle yapıldığı sorusuna tam olarak cevap veren bir yorum, başka türlü değil:
muhtemelen haklısınız, kullanıcının VS2017'deki forma grafik öğeleri çizmesi daha kolaydır, ardından VS'de çalıştırarak yaratımını kontrol edin, "her şeyin döndüğünden" emin olun, programın etkileşimini oluşturmaya devam edebilir .Net ve MT5'te
...
Sizin yolunuz muhtemelen daha pratiktir.
Aynen öyle. Resimlerle birlikte büyük bir Kib kodları veritabanı olacak. İçeri girdim, seçtim, kodu aldım, yapıcıya ekledim, bağlantı dosyalarıyla birlikte çekirdeği aldım. Ve bağlantı zaten düşünülmüş ve çok daha kolay.
Yani ve orada her form ayrı bir dosyada. Daha kolay olsa bile, olanaklar sınırlıdır.
Yani ve orada her form ayrı bir dosyada. Daha kolay olsa bile, olanaklar sınırlıdır.
Dürüst olmak gerekirse, teknolojiyi henüz tam olarak araştırmadım, bu yüzden Vasily'nin çözümünün sınırlı olanakları hakkında hala bir şey söyleyemem.
Vasily, alınma, ama böyle bir panel:
Bunun gibi bir kodum var:
Bu kod basitçe birbirlerine aktarılabilir veya ortak bir veri tabanına yerleştirilebilir ve herkesin özel bir form çizmesine gerek yoktur.
Yapıcıya yapıştırdım ve elemanların ve bağlantıların tüm parametrelerini içeren başka bir pencere aldım.
Peter, aynı paneli sana çizebilmem için senin biçimlendirme dilini öğrenmem gerekiyor. Kullanıcının bu paneli Visual Studio'da çizebilmesi için hiçbir şeye ihtiyaç yoktur, sadece bir fare ve temel beceriler. Farkı hissediyor musun?
Dürüst olmak gerekirse, teknolojiyi henüz tam olarak araştırmadım, bu yüzden Vasily'nin çözümünün sınırlı olanakları hakkında hala bir şey söyleyemem.
Ve Vasily'nin kararı hakkında değil, sınırlılık hakkında yazdım.
Peter, aynı paneli sana çizebilmem için senin biçimlendirme dilini öğrenmem gerekiyor. Kullanıcının bu paneli Visual Studio'da çizebilmesi için hiçbir şeye ihtiyaç yoktur, sadece bir fare ve temel beceriler. Farkı hissediyor musun?
Vasily, biri biçimlendirme dilimi inceliyor ve bir panel yazıyor. Binlerce kişi panelin resmini görür ve bitmiş cybcode'u alır. Yapıcıma ekliyorlar ve bu paneli programlarına alıyorlar.
Daha önce okudum, ancak ayrıntılara girmek için tekrar okumaya devam edeceğim.
1. Makale neden saniyede 5 istek diyor? 30ms frekansım var.
2. Bin hücreli bir tablonun bağlantısının nasıl göründüğünü gösterebilir misiniz?
3. Anladığım kadarıyla, formdaki öğeleri GuiController::SendEvent işlevine gönderilen adlarıyla adreslemek? Tüm parametreleri belirtmem gerekiyor mu? İsim, olay, değer? Diğer bazı sıfırlar ... Ve zamanlayıcıda bir olay döngüsü yapmak mı?
Başka bir deyişle, kullanıcının kendisi bir olay sırası oluşturur ve ardından bunu bir zamanlayıcıda Kontrolöre mi iletir?
Temamın mükemmel reklamı için teşekkür etmeliyim.
1) önemli değil. Herhangi bir frekansı ayarlayabilirsiniz.
2) Tablolar artık desteklenmiyor (bu arada sevinmenizin sebebi mükemmel :)
3) Evet, isimle arayın, tüm parametreleri belirtmeniz gerekiyor. Ama en önemlisi de bu, tek bir monolitik olay modeli yok. Modelinizi ister misiniz - lütfen. İlkel yap. Gerçekten bir zamanlayıcı olmadan yapamazsınız.
Olay kuyruğu, olayların güvenilir şekilde ele alınması için genelleştirilmiş bir algoritmadır. Kullanıcı hiçbir şey oluşturmaz, kendisi tarafından oluşturulan olaylar kuyruğa girer. Sıranın kendisi, zamanın %99,9'unda yalnızca bir olaydan oluşur.
Tamam, açıklamaya çalışacağım:
Çözümünüzü izlerseniz, kullanıcının yine de statik sınıfın kaynak kodunu projeye kopyalaması gerekir; bu, olayları yayınlayacak, formu ayrı bir iş parçacığında çalıştıracak vb. Ek olarak, formu bu sınıfa statik olarak bağlamanız gerekecek, yani. sınıf formunun ve bileşenlerinin adını açıkça girin . Onlar. form değiştiğinde veya bir öğe eklendiğinde katman kodunuzu açıkça değiştirin. Başka bir deyişle, basit ve doğrudan bir çözüm, gösterdiğiniz gibi belirli bir formla etkileşimi göstermek için iyi çalışacaktır. Genelleştirilmiş durumda, yaptığım şey olan kontrol mantığını ve ekran mantığını ayırmak daha iyidir. Ayrıca, bu ayırma, denetleyiciyi vasıfsız değişikliklerden korumanıza olanak tanır.
İşte neden böyle yapıldığı sorusuna tam olarak cevap veren bir yorum, başka türlü değil:
En büyük sıkıntı formun ayrı bir thread'de çalıştırılmasıdır fakat iki satır kod ile çözülebilir yani sonuçta problem olmaz. Ayrıca benim örneğimde ikinci formun açılması bunu yapmanın ne kadar kolay ve basit olduğunu ve istenilen sayıda formun nasıl ayrı başlıklarda açılabileceğini göstermek için özel olarak yapılmıştır.
Ama alıntıda vurgulanan şey - saman nedir, saman nedir aynı şey? Evet! Bir muzu yemek için kabuğunu soymanız gerekir.
Dürüst olmak gerekirse, teknolojiyi henüz tam olarak araştırmadım, bu yüzden Vasily'nin çözümünün sınırlı olanakları hakkında hala bir şey söyleyemem.
olasılıklar üzerinde herhangi bir kısıtlama yoktur, her şey Windows grafik öğelerinin işlevselliği ile ne daha fazla ne de daha az sınırlıdır, " GuiController'ın başlığı altında " bölümündeki makaleyi okuyun, gerekli kontrolleri form tasarımcısına ekleyin ve hangi olayları düşündüğünüzü MT5'te almak için gerekli <öğe - işleyici olaylarının listesi> ekleyin
2) Tablolar artık desteklenmiyor (bu arada sevinmenizin sebebi mükemmel :)
Peter'ı da memnun edeceğim, .Net üzerinde .dll'de tabloyu ayrı bir şekilde çalıştırdım, sağ fare olayları, sıralama ve diğer dataGridView her şeyi sevindiriyor, tabloyu deneyler açısından bir terminal olarak yaptım ama oldukça kaprisli ve yavaş dataGridView , onunla çok denedim (ve bir datatable klonunu doldurdum ve ardından dataGridView'a bağlı bir datatable'a kopyaladım ve ... ve bir hafta boyunca google ve deneme, dataGridView tam bir fiyasko iken - sen 3-5 saniyeden daha sık yazamaz) 10 x 11 tablo, tablo içeren form ayrı bir iş parçacığında çalışsa bile zaten kritiktir
Not: Yaklaşık 5 yıl önce Delphi'de, StringGrid'i 2 saat içinde MT4'e vidaladım, orada her şeyin nasıl çalıştığı konusunda hiç endişelenmedim, ancak Microsoft dataGridView ile her şey uçtu, ancak bugün bir deneme yapmaya çalışacağım. üçüncü taraf SourceGrid, incelemelere göre dataGridView daha hızlı