Tuval harika! - sayfa 55

 
Roman :

Borland'ı hatırlarsanız, grafiksel arayüz görsel bir düzenleyicide birleştirildi, panele bir kontrol düzeni koydu ve sonra işleyicileri yazdınız.
ME'nin görsel modda mizanpajları bir araya getirmek için böyle bir grafik yeteneği olsaydı, bu, grafik uygulamaların yapımını büyük ölçüde basitleştirirdi.
Bir GUI oluşturmayı öğrenen modern programcıların çoğu (öğretildiği gibi) görsel bir grafik düzenleyiciye alıştığından,
ve bir grafik uygulamanın saf C-stili koddaki yerleşimi kimsenin pek ilgisini çekmez. Bu zaten hardcore C tarzı olduğundan.
Bir grafik uygulama oluşturmak için bir görsel düzenleyiciye ihtiyacınız var ve daha sonra insanlar onu incelemek için çekilecek ve VS veya RadStudio'da çalışanlar genellikle görsel düzenleyicide hızlı bir şekilde ustalaşacaklar.

Burada, MQL'de böyle bir görsel düzenleyicinin bir prototipi zaten vardı. Ancak halk dağa karşı ayağa kalktı. Ticarette buna ihtiyacın yok dediler.

Genel olarak, ellerinden geldiğince morallerini bozdular. Bu nedenle, topluluk için gerçekten neyin gerekli olduğunu bilmiyorum.


 
Алексей Барбашин :

Toplama yeteneğine sahip olmanın gerekli olduğunu tamamen destekliyorum...

Gerekli olup olmadığı başka bir sorudur.

Acaba geliştiriciler, terminali bir ticaret aracı mı yoksa bir programlama aracı olarak mı görüyorlar?

Belki şu anda yanılıyorum, ancak her zaman ME'nin, kullanıcının ticaret için ihtiyaç duyduğu işlevselliğin uygulanması için özel olarak sağlandığını düşündüm. Bu ticaret!

Ancak şu anda, ME'deki programlamanın derinliği, küpleri "toplayabilmeniz" ve programlamayı çok ciddi bir şekilde anlamanız gereken alanlara girdi ....

Ve sonunda neye yol açar? Ayrıca, gelişmiş ticaret araçları yalnızca deneyimli programcılar tarafından kullanılabilir!

Yani programcı değilseniz ticaretle uğraşmanıza gerek yok... Ama bu çok saçma...

ME, yalnızca eksik işlevselliği doldurmak için bir yardımcıdır. bu, terminalin kendisinde yerleşik olarak daha doğru olurdu (çeşitli ustalar).

Ve aslında ME, artık kullanıcılardan daha fazla bilgi gerektiren yeni bir geliştirme ortamı olarak gelişiyor.

Bu sonuca dayanarak, görselleştirme araçlarına ihtiyaç vardır, ancak bunların kullanımı, programlama konusunda derin bilgiye sahip olmayan kullanıcılar için de erişilebilir olmalıdır.

Sadece bu yaklaşımla talep görecekler.

Bu sadece benim görüşüm ve bunu kimseye empoze etmiyorum.

CCanvas sınıfını düşünürsek, grafik ilkelleri çizmek için yaklaşık 20 fonksiyon vardır. Diyelim ki kullanıcı hepsini biliyor ve OOP kurallarını ve sözdizimini biliyor. Ancak, verilerinin en basit görselleştirilmesinden önce bu çok az. En basit kontrol düğmelerinin oluşturulmasından bahsetmiyorum bile. Yani, bir tuval üzerine ilkelleri çizmek nispeten kolaydır, ancak bu ilkelleri bir görselleştirme veya GUI oluştururken kullanmak çok daha zordur. Ve burada sadece bilgi olmadan yapamazsınız - burada geliştiricinin YETENEĞİ olmadan yapamazsınız. Birçok insanda var mı? Bu kilit konu.

Canvas sınıfının potansiyelini kullanmak için, grafik temel öğelerini daha karmaşık nesneler (kontroller) halinde birleştirebilmeniz, çalışmalarını bir olay modeline bağlayabilmeniz, işlevlerle bağlantılar yazabilmeniz... Veya dijital verileri çeşitli grafik eğrilerine dönüştürebilmeniz gerekir. ... Bu yetenekli ve çok çalışkan kullanıcılar için bir iştir. Aslında - kullanıcılar değil, geliştiriciler.

 
Реter Konow :

Burada, MQL'de böyle bir görsel düzenleyicinin bir prototipi zaten vardı. Ancak halk dağa karşı ayağa kalktı. Ticarette buna ihtiyacın yok dediler.

Genel olarak, ellerinden geldiğince morallerini bozdular. Bu nedenle, topluluk için gerçekten neyin gerekli olduğunu bilmiyorum.


Wah, yani bir prototip var.
Peki geliştiriciler, topluluğun dar görüşlü görüşlerini yeniden gözden geçirebilir mi? Ve görsel mod geliştirme planına devam edin.
Elbette, çok popüler fırsatların moralini bozması bir şekilde garip.
Ne de olsa, C stilinde bir grafik arayüzün nasıl monte edileceğini öğrettikleri birkaç yer var, eğer hala öğretiyorlarsa.
Artık herkese görsel modlu bir IDE'de çalışması öğretiliyor ve MT5 uzun süredir sadece bir ticaret platformunun ötesine geçtiğinden,
o zaman grafik uygulamaları oluşturmanın görsel modu büyük talep görecektir.
Dürüst olmak gerekirse, geliştiricilerin buna karşı olanların dar görüşlü görüşlerini dinledikleri için şok oldum.

 
Реter Konow :

CCanvas sınıfını düşünürsek, grafik ilkelleri çizmek için yaklaşık 20 fonksiyon vardır. Diyelim ki kullanıcı hepsini biliyor ve OOP kurallarını ve sözdizimini biliyor. Ancak, verilerinin en basit görselleştirilmesinden önce bu çok az. En basit kontrol düğmelerinin oluşturulmasından bahsetmiyorum bile. Yani, bir tuval üzerine ilkelleri çizmek nispeten kolaydır, ancak bu ilkelleri bir görselleştirme veya GUI oluştururken kullanmak çok daha zordur. Ve burada sadece bilgi olmadan yapamazsınız - burada geliştiricinin YETENEĞİ olmadan yapamazsınız. Birçok insanda var mı? Bu kilit konu.

Canvas sınıfının potansiyelini kullanmak için, grafik temel öğelerini daha karmaşık nesneler (kontroller) halinde birleştirebilmeniz, çalışmalarını bir olay modeline bağlayabilmeniz, işlevlerle bağlantılar yazabilmeniz... Veya dijital verileri çeşitli grafik eğrilerine dönüştürebilmeniz gerekir. ... Bu yetenekli ve çok çalışkan kullanıcılar için bir iştir. Aslında - kullanıcılar değil, geliştiriciler.

Peter, doğru kelimeleri söylüyorsun!

Bu yüzden, OOP'ye aşina olmayan programcılar için sezgisel olacak bu tür kütüphaneler oluşturmaktan yanayım.

Ve bu sadece GUI için geçerli değildir.

Standart kütüphanede ve Anatoly kütüphanesinde basit bir form oluşturmak için kafanızı kırmanız gerekiyor! Gerçekten! Örneklerin sağına veya soluna gidin ve hepsi bu, hiçbir şey işe yaramıyor, karmaşıklıkları anlamanız gerekiyor.

Tüm dillerde, elbette, GUI de kütüphaneler üzerine kuruludur, ancak önemli bir AMA var! Kitaplığın çekirdek düzeyinde birbirine tamamen "bağlı" olan bir ilk kontrol grubu vardır, tüm temel olay işleyicileri "atılır", yalnızca davranışı veya görünümü değiştirmek istiyorsanız onlara abone olmak için kalır. .

Aslında, standart kitaplığın mimarisi çok düşüncelidir ve daha gelişmiş bir kitaplığın temeli olarak kullanılabilir.

 
Roman :

Wah, yani bir prototip var.
Peki geliştiriciler, topluluğun dar görüşlü görüşlerini yeniden gözden geçirebilir mi? Ve görsel mod geliştirme planına devam edin.
Elbette, çok popüler fırsatların moralini bozması bir şekilde garip.
Ne de olsa, C stilinde bir grafik arayüzün nasıl monte edileceğini öğrettikleri birkaç yer var, eğer hala öğretiyorlarsa.
Artık herkese görsel modlu bir IDE'de çalışması öğretiliyor ve MT5 uzun süredir sadece bir ticaret platformunun ötesine geçtiğinden,
o zaman grafik uygulamaları oluşturmanın görsel modu büyük talep görecektir.
Dürüst olmak gerekirse, geliştiricilerin buna karşı olanların dar görüşlü görüşlerini dinledikleri için şok oldum.

Diğer bazı faktörler de şaşırtıcı: göstergelerin %100'ünde görsellik, vakaların %80'inde danışmanların görselliği, %20'sinde senaryolar var. Beğenin ya da beğenmeyin, her şeyde bir görsellik vardır ve bunun anlaşılması yüzeyde yatmaktadır. Ancak, diğer geliştirme ortamları ile entegrasyon konusunda geliştirmeler devam ediyor ve yüzeyde ne var ....

Görünüşe göre her ikinci terminal kullanıcısı python ve sql hakkında sorular soruyor.

Roman, Peter, Nikolai... terminal geliştiricilerin kendi vizyonları vardır, onlar yazılım ürününün yazarları ve sahipleridir. ME'nin ve bir bütün olarak terminalin işlevselliğinin geliştirilmesinin pazarlama araştırmasına dayandığına inanıyorum.
Ama kimse bizi konuşmaktan rahatsız etmiyor :)

 
Алексей Барбашин :

Diğer bazı faktörler de şaşırtıcı: göstergelerin %100'ünde görsellik, vakaların %80'inde danışmanların görselliği, %20'sinde senaryolar var. Beğenin ya da beğenmeyin, her şeyde bir görsellik vardır ve bunun anlaşılması yüzeyde yatmaktadır. Ancak, diğer geliştirme ortamları ile entegrasyon konusunda geliştirmeler devam ediyor ve yüzeyde ne var ....

Görünüşe göre her ikinci terminal kullanıcısı python ve sql hakkında sorular soruyor.

Roman, Peter, Nikolai... terminal geliştiricilerin kendi vizyonları vardır, onlar yazılım ürününün yazarları ve sahipleridir. ME'nin ve bir bütün olarak terminalin işlevselliğinin geliştirilmesinin pazarlama araştırmasına dayandığına inanıyorum.
Ama kimse bizi konuşmaktan rahatsız etmiyor :)

O gibi.

Benim düşüncem şu: Danışmanların görsel arayüzü, pazar satışlarını olumsuz yönde etkileyecek stratejileri tek bir uygulamada toplamanıza izin verecek. Herkes dinamik bir strateji seti ile kolayca Uzman Danışmanlar oluşturabilirse (GUI buna izin verir), Pazardaki akıcı rotasyonları düşecek ve bu da satışları etkileyecektir. İlk sırayı, kendi içinde birleşip strateji değiştiren ve sadece ortam veya birkaç koşulda farklılık gösteren klonları yok eden uzmanlar alacak. Piyasa için iyi olacak mı? bilmiyorum. Ancak danışmanların seviyesi artacak ve onlara pencereden bakmak çok daha ilginç hale gelecek.

 
Реter Konow :
Belki de çoğu kullanıcı, çalışmak için OOP ilkeleri ve sözdizimi bilgisi gerektiren sınıflar yerine CCanvas, CGrafic ve CCanvas3D'nin gerekli görselleştirmeleri sağlayan uygulamalar olmasını ister. Ve sadece bilmek değil, aslında - Nikolai'nin yaptığı gibi kendi görselleştirme sisteminizi oluşturmak.

Dersleri bilmek yetmez. Kütüphanelerden kendi çözümlerinizi "düşük" bir seviyede bir araya getirebilmeniz gerekir. Kendi geliştiriciniz olmalısınız. Bu da kullanıcıların yüzde 1'ine veriliyor.

Onlara hazır görselleştirme uygulamaları verilirse, kullanıcıların artık öğrenmelerine gerek kalmayacak, ancak daha fazlası olacaktır.

Bu gerekli mi? bilmiyorum.

Sevgili Tanrım, burada bilmeniz gereken OOP ilkesi nedir? Buna bir son verip listeden bir yöntem mi seçiyorsunuz?

 
aleger :

Bir karşı soru: toplam sayılarından kaç tane ve hangi "en güçlü" ve "en basit" MQL işlevi

herhangi biri için tamamen işlevsel ve potansiyel olarak en karlı Uzman Danışmanı yazmak için yeterlidir.

dünyanın en büyük döviz çiftlerinden?

Ve buradaki herkesin kafasını kaybettiği R veya Python'un hangi işlevi yazmak için yeterli? .. Ve bak, oturduğun tabure - neye uygun? ...

 
Roman :

Borland'ı hatırlarsanız, grafiksel arayüz görsel bir düzenleyicide birleştirildi, panele bir kontrol düzeni koydu ve sonra işleyicileri yazdınız.
ME görsel modda düzenleri bir araya getirmek için böyle bir grafiksel yeteneğe sahip olsaydı, o zaman bu , grafik uygulamaların yapımını büyük ölçüde basitleştirirdi.
Bir GUI oluşturmayı öğrenen modern programcıların çoğu (öğretildiği gibi) görsel bir grafik düzenleyiciye alıştığından,
ve bir grafik uygulamanın saf C-stili koddaki yerleşimi kimsenin pek ilgisini çekmez. Bu zaten hardcore C tarzı olduğundan.
Bir grafik uygulama oluşturmak için bir görsel düzenleyiciye ihtiyacınız var ve daha sonra insanlar onu incelemek için çekilecek ve VS veya RadStudio'da çalışanlar genellikle görsel düzenleyicide hızlı bir şekilde ustalaşacaklar.

Neden burada onlara ihtiyaç var?

 
Реter Konow :

O gibi.

Benim düşüncem şu: Danışmanların görsel arayüzü, pazar satışlarını olumsuz yönde etkileyecek stratejileri tek bir uygulamada toplamanıza izin verecek. Herkes dinamik bir strateji seti ile kolayca Uzman Danışmanlar oluşturabilirse (GUI buna izin verir), Pazardaki akıcı rotasyonları düşecek ve bu da satışları etkileyecektir. İlk sırayı, kendi içinde birleşip strateji değiştiren ve sadece ortam veya birkaç koşulda farklılık gösteren klonları yok eden uzmanlar alacak. Piyasa için iyi olacak mı? bilmiyorum. Ancak danışmanların seviyesi artacak ve onlara pencereden bakmak çok daha ilginç hale gelecek.

Tamamen sahte bir sorun.
Toplama stratejileri için görsel arayüz, küplere ihtiyaç duyan gereksizdir, o zaman bu tslab'de.
Evet ve ağda bir şekilde görsel modda küpler halinde stratejiler toplayan mql kodu oluşturmak için programlarla tanıştım.
Ticaret stratejileri ve göstergeleri geliştirmek için görsel moda gerek yoktur, gerçekten gereksizdir.
Ancak modüler grafik uygulamalar için GIF'de gösterdiğiniz gibi görsel mod kullanışlı olacaktır.