
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
Kısaca mühendislik hakkında:
yeniden geliştirme yoluyla bazı "A"ları iyileştirme dürtüsü varsa, kritik eksikliklerini belirtmek gerekir. Bunları listeleyin ve "A"nın evrimsel gelişim sürecinde bunun neden kaçınılmaz olduğunu açıklayın.
öte yandan, kimse yasaklamıyor. Kod yazmayı, yazmayı seviyorum ... "A" yı yeniden yazacaksın, ama kendi yönteminle, ama yeni olacak
Max, merhaba!
Eh, benim açımdan standart kütüphanede ve Anatoly kütüphanesinde gördüğüm "eksiklikleri" defalarca açıkladım.
Her iki kütüphanenin de bence önemli bir dezavantajı var: arayüz ayrık grafik nesneleri üzerine kuruludur, yani arayüzde ne kadar fazla kontrol varsa, grafiğin kendisinde o kadar ayrı nesneler. Bir yandan, bu kendi içinde bir sorun gibi görünmüyor, ancak diğer yandan, sürüklenen tek bir "elemanlı form" nesnesi değil, birçok farklı eleman olduğu için diyalogları sürüklerken sorun yaratıyor. . Ve bu ek kaynaklar gerektirir.
Anatoly'nin kütüphanesi çok şık, ancak kompozisyon açısından karmaşık ve ana programa entegre edilmesi zor. Orijinal mimari bence çok iyi olsa da, standart kütüphane kontrollerde sınırlıdır.
Aslında, en iyi çözüm Petr Konov'un yapmaya çalıştığı şey olurdu: GUI kod oluşturma özelliğine sahip, ancak yalnızca genişletilmiş bir olay modeline sahip bir grafik arayüz tasarımcısı, böylece ana programla entegrasyon sırasında devasa GUI kodu (MVVM analogu gibi bir şey) ve elbette kullanıcıların kendi başlarına genişletebilecekleri nesnelerle.
Max, merhaba!
Eh, benim açımdan standart kütüphanede ve Anatoly kütüphanesinde gördüğüm "eksiklikleri" defalarca açıkladım.
Her iki kütüphanenin de bence önemli bir dezavantajı var: arayüz ayrık grafik nesneleri üzerine kuruludur, yani arayüzde ne kadar fazla kontrol varsa, grafiğin kendisinde o kadar ayrı nesneler. Bir yandan, bu kendi içinde bir sorun gibi görünmüyor, ancak diğer yandan, sürüklenen tek bir "elemanlı form" nesnesi değil, birçok farklı eleman olduğu için diyalogları sürüklerken sorun yaratıyor. . Ve bu ek kaynaklar gerektirir.
Anatoly'nin kütüphanesi çok şık, ancak kompozisyon açısından karmaşık ve ana programa entegre edilmesi zor. Orijinal mimari bence çok iyi olsa da, standart kütüphane kontrollerde sınırlıdır.
Aslında, en iyi çözüm Petr Konov'un yapmaya çalıştığı şey olurdu: GUI kod oluşturma özelliğine sahip, ancak yalnızca genişletilmiş bir olay modeline sahip bir grafik arayüz tasarımcısı, böylece ana programla entegrasyon sırasında büyük GUI kodu ve elbette kullanıcıların kendilerini genişletebilecekleri nesnelerle.
Alıntı aşağıdan yukarıya doğru okunmalıdır. Aşağıda (altı çizili olan) daha önemlidir. Genel olarak belirler
Tüm İnsan Arayüzünün tüm modern gelişimi ile birlikte, koordinat temsillerinin ve şekil öğelerinin ön plana çıktığını görmek oldukça şaşırtıcı.
Aynı zamanda herkes sakince Rest/Ajax ile tarayıcıları kullanıyor, MVC'nin ne olduğunun farkındalar, ancak danışman ile GUI arasındaki arayüz hakkında düşünmüyorlar.
model açıklanırsa ve onunla nasıl çalışılacağına dair bir protokol varsa, GUI herhangi biri olabilir ve danışmandan kıskançlık olmaz. Pencereleri danışmana yönlendirme yönergesi, bu bir tür kötülük-kötü-kötülüktür. Uzman Danışmanlar için asıl görev ticaret yapmaktır, geri kalan her şey ana koddan çıkarılmalı ve isteğe bağlı olmalıdır.
Alıntı aşağıdan yukarıya doğru okunmalıdır. Aşağıda (altı çizili olan) daha önemlidir. Genel olarak belirler
Tüm İnsan Arayüzünün tüm modern gelişimi ile birlikte, koordinat temsillerinin ve form öğelerinin başa konduğunu görmek oldukça şaşırtıcı.
Aynı zamanda herkes sakince Rest/Ajax ile tarayıcıları kullanıyor, MVC'nin ne olduğunun farkındalar, ancak danışman ile GUI arasındaki arayüz hakkında düşünmüyorlar.
model açıklanırsa ve onunla nasıl çalışılacağına dair bir protokol varsa, GUI herhangi biri olabilir ve danışmandan kıskançlık olmaz. Pencereleri danışmana yönlendirme yönergesi, bu bir tür kötülük-kötü-kötülüktür. Uzman Danışmanlar için asıl görev ticaret yapmaktır, geri kalan her şey ana koddan çıkarılmalı ve isteğe bağlı olmalıdır.
Burada, geliştiricilerin başlangıçta arayüzlerin işlevselliğinin gerekli olabileceği gerçeğini düşünmedikleri gerçeğinden yola çıkmaya değer olduğuna inanıyorum. Hatırlarsanız, ilk dönemlerde mql'de OOP bile yoktu, asıl amacı sadece gösterge yazmaktı ve her şey buna göre ayarlanmıştı.
Ve bugün metakotaların zaten hem soketler hem de veritabanları ile çalıştığını ve program çekirdeğinin kendi düzeyinde olduğunu gözlemliyoruz... Ve kullanıcı ile program arasındaki etkileşim mekanizmaları bir kenara kaldı.
Aynı zamanda, geliştiricilerin kendileri neredeyse on yıl önce, arayüz geliştirmenin kullanıcı ve uygulama arasındaki etkileşim için çok önemli bir mekanizma olduğunu belirttiler ve bu konuda standart bir kütüphane geliştirdiler, ancak sadece görevler için uygulanabilirliğini göstermediler. ve aslında bugün bile birçok programcı onun varlığından haberdar değil.
Boşlukları doldurmaya çalışacağız. Diğer katılımcılar tarafından talep edilmese bile, yine de bir miktar deneyim kazanılacaktır.
Kitaplığınızla başladım, teşekkür ettim, sonra biraz taradım, sonra bir tane daha, sonra bir tane daha))) sonunda yeniden yazılan çizgi işlevleri dahil her şeyi değiştirdim, ayrıca geniş çizgi işlevi tuval kaynağından, sahte işlevleri kaldırdım , olaya bir taslak koyun. W yapısından henüz tamamen çıkmadı, ancak orada da çok az şey kaldı. Sırasıyla üçüncü taraf öğeler arasında ikili arama ile soldan ve sağdan çubuğun hesaplanması eklendi, ikili aramanın kendisine daha büyük veya daha küçük bir değer seçme yeteneği ile iki yönlü eklendi. Ayrıca herhangi bir tür diziden oluşturma yeteneğini de ekledim (zaman serisi / normal) Ve tasarımı değiştirmenin gerekli olduğu sonucuna vardım)))))
Harika.
Evet, kütüphaneler ya acemi programcılar için evrensel olmalı ya da daha gelişmiş olanlar için dar odaklı olmalıdır.
Farklı amaçlar için kendi iCanvas'ımın birkaç versiyonuna sahibim.
Bu nedenle, bir niyet ve hedefler listesi oluşturmaktan veya en azından yönü belirtmekten bahsetmeye başladım. Ve düzenlenebilir durumdayken bu listeyi ilk gönderiye koyun.
Genel olarak, ya yanlış bir şey yapıyorum ya da sınıfları (boş) bildirmek için şablonlar çalışmak istemiyor. Kodu özellikle uygun olmayan kılan nedir?
Nasıl değiştirileceğini düşünmek
Çocuklar, madem bana öğrettiniz, ben de size öğreteyim.
Bir dakika - bu, temellerin temelinden başka bir şey değil. Ve GUI'yi bitireceğim gerçeği pek olası değil - bunu en başta söyledim. Büyük projelerle ilgili olarak - Bunu kodunuzda söyleyeceğim, büyük projelerle rekabet etmek için yeterli satır yok .....
şimdi soru bu hile neden çalışmıyor
...
şimdi soru bu hile neden çalışmıyor