Benim yaklaşımım. Çekirdek - Motor. - sayfa 26
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
GUI yapıcıları belirli bir grafik kitaplığı için yapılmıştır. MQL için bir GUI kurucusu olsaydı, burada olurdu.
habré gibi bir yerde bir makale gördüm, "Python için bir GUI yapıcısı oluşturuyoruz" gibi görünüyor, bu yüzden belki birinin kodunuzu ekleyebileceğiniz çok platformlu bir GUI gördüğünü düşündüm.
ve bu nedenle, sıfırdan bir kurucu yazarsanız, hemen MQL kullanmak daha iyidir
1. Sharp'a hiç yazmadım, ilgi yoktu ama yaklaşık 5 yıl önce .dll'yi butonlar ve formlarla Delphi'ye bağladım, her şey sorunsuz çalıştı ve tüm projeyi gün içinde Delphi'de yazdım ve harcadım yarım gün standart formların neden çalışmadığını araştırdım ve Windows sistem pencerelerinin çağrısıyla bağladığımda her şey düzgün çalıştı, ancak MT4 çok sıkıydı, yavaşladı, şimdi uçuyor
genel olarak, .dll'ye bağlanmak, standart mutekslerle uygun şekilde senkronize etmek için herhangi bir sorun yoktur - terminal ile iletişim kurmak için bir iş parçacığı başlattı ve bu kadar, o zaman her şey kendi başına - .dll'de ayrı bir form, ayrı olarak MT kimse beklemiyor herkes için
Not: Delphi'nin .dll oluşturmak için oldukça pratik olmadığını lütfen unutmayın, ancak eldeki şey (o zaman üzerinde oturuyordum) sonra kullandım)))
2. Konuya gelince, MT teslimatından standart sınıfları neden kullanamadığınızı anlamıyorum, grafik oluşturma sürecini birleştirmek en fazla ilginç olurdu, peki, evrensel bir içerik olsun gereksiz düğmeleri / diyalogları, vb. yorumlayabileceğiniz yer. .P.
1. Bu, soruna çok amatörce bir bakış açısıdır (alınma yok). Gündüz yapılan bir proje, Proje değildir. Bu küçük bir sorun.
Aralarında büyük veri tabloları, ayar pencereleri ve iletişim kutuları bulunan 10 pencereden oluşan bir uygulama oluşturduğunuzu hayal edin. Onları Delphi'de çiziyorsun. Sonra bir DLL oluşturursunuz. Ardından projenize MT üzerinden bağlanırsınız.
MT uygulamanızın, paylaşılan bellek aracılığıyla Delphi GUI'ye bağlanması gerekir. Fonksiyonları kontrollere, verileri tablo hücrelerine bağlayın. Uygulamanın iki bölümünün karmaşık etkileşimini düzenlemeniz ve her şeyi doğru düşünmeniz gerekir.
İki parça arasında senkronize çalışmaya ve parametre değerlerinin değiş tokuşuna ihtiyacınız var - GUI ve MT'de Uygulama.
Bir kez daha: uygulama büyük ve ciddiyse (tablolar, ayar pencereleri, iletişim kutuları, ağaç listeleri vb.), bir DLL aracılığıyla iki parçanın birleşik, iyi koordine edilmiş ve verimli çalışmasını oluşturmak ÇOK ciddi bir iştir. Ben yaptım ve neden bahsettiğimi biliyorum.
Ve bir günde çözülebilecek küçük bir sorundan bahsediyorsunuz. Bu ciddi değil.
2. Standart kitaplığı uzun süre kullanabilirsiniz. Ancak soru, gerekli işçilik maliyetleri ve elde edilen sonuçtur. Onlar neler? Anatoly'nin standart kütüphaneyi kendi kütüphanesini oluşturmak için bir sıçrama tahtası olarak kullandığını biliyorum. Ve standart kütüphane de çalışıyorsa neden yaptı? Cevap basit - her şeyi daha iyi uyguladı ve standart kütüphanenin ötesine geçti. AMA, kütle dağılımı ancak kullanım zorluğunu azaltarak sağlanabilir. Kullanımı ne kadar kolaysa, o kadar çok kullanıcı olacaktır (elbette kalite iyileştirmesini hesaba katarak).
1. Bu, soruna çok amatörce bir bakış açısıdır (alınma yok). Gündüz yapılan bir proje, Proje değildir. Bu küçük bir sorun.
Aralarında büyük veri tabloları, ayar pencereleri ve iletişim kutuları bulunan 10 pencereden oluşan bir uygulama oluşturduğunuzu hayal edin. Onları Delphi'de çiziyorsun. Sonra bir DLL oluşturursunuz. Ardından projenize MT üzerinden bağlanırsınız.
MT uygulamanızın, paylaşılan bellek aracılığıyla Delphi GUI'ye bağlanması gerekir. Fonksiyonları kontrollere, verileri tablo hücrelerine bağlayın. Uygulamanın iki bölümünün karmaşık etkileşimini düzenlemeniz ve her şeyi doğru düşünmeniz gerekir.
İki parça arasında senkronize çalışmaya ve parametre değerlerinin değiş tokuşuna ihtiyacınız var - GUI ve MT'de Uygulama.
Bir kez daha: uygulama büyük ve ciddiyse (tablolar, ayar pencereleri, iletişim kutuları, ağaç listeleri vb.), bir DLL aracılığıyla iki parçanın birleşik, iyi koordine edilmiş ve verimli çalışmasını oluşturmak ÇOK ciddi bir iştir. Ben yaptım ve neden bahsettiğimi biliyorum.
Ve bir günde çözülebilecek küçük bir sorundan bahsediyorsunuz. Bu ciddi değil.
hangi şikayetler? MT ve .dll arasındaki iletişimin dünya kadar eski olduğunu anlamıyorsunuz.
.dll yaptım çünkü daha önce MT'de düzgün grafikler yoktu, butonlar ve bir panel istedim
tablolar? - Peki, tablolar, kontroller çizin mi? - çiz .... Görevi bölemezsiniz, aynı Delphi'de hem veritabanları oluşturmak hem de onlarla çalışmak için birçok hazır bileşen vardır.
onlar. MT'den, yalnızca verilerin kendisine ihtiyaç vardır ve gerisi üçüncü taraf bir program tarafından yapılacaktır, bir kelime alabilirsiniz, ancak aynı Delphi'de veritabanı ile çalışma, tablolara, grafiklere vb. gün için;)
MT'deki veriler nedir? = bu yalnızca bir işaret ve bir çubuktur ve geçmişi .dll aracılığıyla "sürmek" anlamsızdır - her şeyi dosyaya bir kez dökmek ve dosyayla üçüncü taraf bir programda çalışmak yeterlidir
Not: Son zamanlarda forumdan biri, modern BT şirketlerinde çalışanlara, çalıştıkları kodu iyice anlayanlar tarafından değil, mümkün olan en kısa sürede çok sayıda görevi tamamlayabilenler tarafından değer verildiğini yazdı. diğer insanların gelişmelerini görevinize entegre edebilmelisiniz ve her seferinde her şeyi sıfırdan inşa etmemelisiniz! Ana faaliyetinizi bilmiyorum, hiç programcı olarak çalışmadım ama sürekli ilgili alanlarda çalışıyorum, uzun süre endüstriyel kontrolörlerin, otomatik kontrol sistemlerinin ve otomatik kontrol sistemlerinin bakımı ile uğraştım, mecbur kaldım. yazılım çözümleri ekleyin ve geliştiricilerle etkileşime geçin, bu yüzden tüm hazır yazılım çözümlerini araştırmak zorunda kaldım - burada her şeyi sıfırdan yazamazsınız))) ve endüstriyel donanım üreticileri özel programlama sistemleri kullanıyor, nerede C, nerede SCADA ve montajcı nerede ve her zaman başka birinin kodunu okuyabilmeniz gerektiğinde ;)
"Motorunuz" temelinde, programcıların gelecekte değiştiremeyecekleri, koşullu olarak uygulanabilir bir tasarım yaratmayı mı teklif ediyorsunuz?
hangi şikayetler? MT ve .dll arasındaki iletişimin dünya kadar eski olduğunu anlamıyorsunuz.
.dll yaptım çünkü daha önce MT'de düzgün grafikler yoktu, butonlar ve bir panel istedim
tablolar? - Peki, tablolar, kontroller çizin mi? - çiz .... Görevi bölemezsiniz, aynı Delphi'de hem veritabanları oluşturmak hem de onlarla çalışmak için birçok hazır bileşen vardır.
onlar. MT'den, yalnızca verilerin kendisine ihtiyaç vardır ve gerisi üçüncü taraf bir program tarafından yapılacaktır, bir kelime alabilirsiniz, ancak aynı Delphi'de veritabanı ile çalışma, tablolara, grafiklere vb. gün için;)
Not: MT'deki veriler nedir? = bu yalnızca bir işaret ve bir çubuktur ve geçmişi .dll aracılığıyla "sürmek" anlamsızdır - her şeyi dosyaya bir kez dökmek ve dosyayla üçüncü taraf bir programda çalışmak yeterlidir
MT'den yalnızca ona giren verileri alır ve DLL aracılığıyla Delphi veya C++ veya C# ile yazılmış bir uygulamaya aktarırsanız, bu KESİNLİKLE mümkündür . Ardından ticaret uygulaması tamamen başka bir programlama dilinde yazılacaktır.
Yani, zaman serisi , test cihazı , optimizasyon , sentetikler ve çok daha fazlasını BAĞIMSIZ OLARAK başka bir dilde oluşturmanız gerekir.
O zaman neden MQL'ye ihtiyaç duyuluyor? Doğrudan üçüncü taraf bir uygulamaya veri sağlamak ve platformu olayların ve siparişlerin ileticisi olarak kullanmak yeterlidir. Ve bu kadar. Ancak ticaret sistemlerinin dili olarak MQL'nin avantajları kaybolacaktır .
MQL neden gereklidir?
Daha sonra, bu MQL, ticaret uygulamaları yazmak için keskinleştirilmiş uygulamalı bir dildir. Bu onun ana avantajıdır. O hafif ve basittir. Programcılar için birçok hazır çözüme sahiptir. Alıp kullanıyorlar.
Programcıların bir seçeneği var:
Açıkçası, en çok tercih edilen seçenek MQL ve MT kullanmaktır, çünkü avantajlar sağlarlar - Test Etme, Optimizasyon, Araştırma (sentetik), Göstergeler, uygun işlevler, zaman serileri ... + Forumdaki dilin teknik desteği.
Ancak bu ideal varyantın ciddi bir dezavantajı vardır: Kaliteli bir GUI oluşturmanın zorluğu nedeniyle karmaşık uygulamalar oluşturma yeteneğinin sınırlı olması.
Bu son sorunu büyük ölçüde çözdüm .
Bu nedenle iş uygulamaya geldiğinde ve ciddi bir uygulama yazmaya başladığınızda kesinlikle MT'yi seçeceksiniz. Pek çok, diğerleri gibi.
...
"Motorunuz" temelinde, programcıların gelecekte değiştiremeyecekleri, koşullu olarak uygulanabilir bir tasarım yaratmayı mı teklif ediyorsunuz?
Motor, yapıcımda oluşturulan GUI'nin "taşıyıcısıdır". Değiştirilmesi gerekmez. Sadece uygulamaya bağlanın ve oluşturulan GUI çalışacaktır.
Bir kez daha: uygulama büyük ve ciddiyse (tablolar, ayar pencereleri, iletişim kutuları, ağaç listeleri vb.), bir DLL aracılığıyla iki parçanın birleşik, iyi koordine edilmiş ve verimli çalışmasını oluşturmak ÇOK ciddi bir iştir. Ben yaptım ve neden bahsettiğimi biliyorum.
Büyük ve karmaşık bir uygulama oluşturabilen herkes kesinlikle gui kitaplığını kullanacaktır. Bir geliştirici, uygulamasını geliştirirken örneğin animasyon eklemeye karar verirse ne yapmalıdır? Arayıp soruyorsun ya da her şeyi kırıp yeniden mi inşa ediyorsun?
Ve bir GUI oluşturma ile ilgili sorunlar olduğunu nereden anladınız? Piyasaya bakın, GUI ile birçok uygulama var.
1. Büyük ve karmaşık bir uygulama oluşturabilen herkes mutlaka gui kitaplığını kullanacaktır.
2. Bir geliştirici, uygulamasını geliştirirken örneğin animasyon eklemeye karar verirse ne yapmalıdır? Arayıp soruyorsun ya da her şeyi kırıp yeniden mi inşa ediyorsun?
3. Bir GUI oluşturma ile ilgili sorunlar olduğunu nereden anladınız? Piyasaya bakın, GUI ile birçok uygulama var.
1. Mesele sadece bu. GUI - ciddi programcılar için tasarlanmış bir kitaplık. Kullanımının zorluğu nedeniyle yaygın olarak dağıtılamaz. Ne anlamı var o zaman? Birimler kitaplığı inceleyecek ve karmaşık uygulamalar oluşturacak, diğerleri yapamayacak mı?
2. Geliştiricinin uygulamasında animasyon oluşturmasına izin verin. Ne yaptım? Bu animasyonu GUI ve Motordan bağımsız olarak çağırabilir veya kendi animasyon çağrısını bir tuşa bağlayabilir.
3. GUI'si ilgiyi hak eden sadece birkaç kişi var. Sen, Anatoly ve belki bir başkası ... Gerisi az ya da çok ciddi seviyeye ulaşmıyor.
3. GUI'si ilgiyi hak eden sadece birkaç kişi var.
Bu kadar kategorik olmazdım. Ve bir gui kütüphanesi geliştirmekten değil, gui ile uygulamalardan bahsetmiştim. Bu yüzden piyasada kendi geliştirmelerini kullanan, standart olan ve Anatoly'den kütüphane olan birçoğu var.
1. Mesele sadece bu. GUI - ciddi programcılar için tasarlanmış bir kitaplık. Kullanımının zorluğu nedeniyle yaygın olarak dağıtılamaz. Ne anlamı var o zaman? Birimler kitaplığı inceleyecek ve karmaşık uygulamalar oluşturacak, diğerleri yapamayacak mı?
2. Geliştiricinin uygulamasında animasyon oluşturmasına izin verin. Ne yaptım? Bu animasyonu GUI ve Motordan bağımsız olarak çağırabilir veya kendi animasyon çağrısını bir tuşa bağlayabilir.
3. GUI'si ilgiyi hak eden sadece birkaç kişi var. Sen, Anatoly ve belki bir başkası ... Gerisi az ya da çok ciddi seviyeye ulaşmıyor.
Peter, bence asıl sorununuz projenin konumlandırılmasında.
Sadece programlama konusunda oldukça iyi deneyime sahip, ancak aynı zamanda elleriyle ticaret yapmayı tercih eden katılımcılar için ilgi çekici olabilir.
Sizce çok mu var?
Bakın - gelişiminizin tüm eleştirmenleri, düzenli olarak "manuel" ticaret yapmayan insanlardır. Maksimum - zaman zaman. Ve projenize manuel tüccarlar gibi bakmadıkları için programcılar gibi bakıyorlar. Ve elbette, bir sürü şüpheli çözüm buluyorlar.
Bence sorunuz şimdi bu niş arayışında olmalı (bence çok dar) - elleriyle ticaret yapmayı tercih eden programcılar.
habré gibi bir yerde bir makale gördüm, "Python için bir GUI yapıcısı oluşturuyoruz" gibi görünüyor, bu yüzden belki birinin kodunuzu ekleyebileceğiniz çok platformlu bir GUI gördüğünü düşündüm.
ve bu nedenle, sıfırdan bir kurucu yazarsanız, hemen MQL kullanmak daha iyidir
Modern GUI kurucuları ("formlara butonları dağıtanlar") oldukça teknolojik bir şeydir ve onlara MQL öğeleri eklemek harika görünmüyor.
Hemen hemen herkesin, öğelerin konumunu ve ilişkilerini tanımlayan XML ile bir ara formu ( proje dosyası vb.) vardır.
Hedef platform kodu oluşturma - aslında bu, kendisini bir web programcısı olarak gören herkesin yapabileceği bir XSLT dönüşümüdür :-)
Örneğin, EasyAndFast (https://www.mql5.com/en/code/19703) bir nesne olduğu ve gerekli tüm bileşenlere sahip olduğu için alınmıştır. (ve bu arada konudan farklı olarak açık ve belgelidir),
ve çevirmen basitçe yazılmıştır.
Çok zor olduğu için değil, sadece talep edilmediği için gui-mql yapıcıları yoktur.