Canvas üzerinde bir kitle kaynaklı proje yapma - sayfa 36
Ticaret fırsatlarını kaçırıyorsunuz:
- Ücretsiz ticaret 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
Herhangi bir diyalog elemanı (form, kontrol elemanı (düğme, liste, resim)) bazı özelliklere sahiptir. Prosedürel programlama, "mülk" veya "alan" kavramını tanımlamaz. Prosedürel programlamada fonksiyonlarımız ve değişkenlerimiz vardır (global veya local). Ancak değişkenler paylaşılır, yani her bir kontrolün özelliklerini tanımlamak için kullanılamazlar. O zaman çıkış yolu nedir? Evet basit - yapılar!
Evet, bir yapı, bir kontrol elemanının gerekli özelliklerinin tanımına ve aynı zamanda iç içe (kabul edilebilir) kontrol elemanları dizisine sahip olabilir.
Her şey bir dizi iletişim kutusunda saklanır.
Daha evrensel hale getirilebilir: kontrol tanımlama yapısı iki diziden oluşur: bir dizi özellik ve bir dizi alt öğe. Bir özellik dizisi, bir Özellik-Değer çiftinin yapılarının bir dizisidir. Bu yaklaşımla, her yeni denetim herhangi bir isteğe bağlı özellik kümesine sahip olabilir. Ancak işleme için uygun değildir. Kontrol öğesinin belirli özelliklerini yapıda belirtmek daha mantıklı olacaktır: boyutlar, konum, renk, çerçeve, vb. - herhangi bir kontrol öğesinin ihtiyaç duyduğu her şey.
Pekala, yapıda bu öğenin bir dizi pikseli de olacaktır.
Bir fare olayı alındığında, imlecin belirli bir kontrole vurup vurmadığını kontrol etmek için döngü tüm diziler boyunca yinelenir. Kontrol, sondan birinciye doğru yapılır.
İmlecin hangi kontrole çarptığı ortaya çıkar çıkmaz, bu dizi elemanı yeniden çizim işlevine gönderilir ve ardından kaynak diziyi günceller ve grafikteki resmi güncelleriz.
GUI'de ne yazdığı ve ne yaptığı önemli bilmiyorum ama benim konularımda tek bir teknik öneride bulunmadı, tek bir çözüm üretmedi ve konuyla ilgili herhangi bir tartışmaya da öncülük etmedi. Yalnızca boş trolleme, üçüncü taraf çözümlerine işaret etme ve tekerleği yeniden icat etmeme çağrıları.
Konuya geri dönelim.
Standart kitaplığa aşina olduğum kadarıyla (aslında çok az), orada öğeler ve pencereler MT nesnelerinden oluşur. Yani bizim bağlamımızda tuval üzerine çizilmiyorlar. Elbette çizilirler, ancak tuvalimizde değil, bu da bize piksel renklerini kontrol etme, yüzey gradyanları oluşturma ve çok daha fazlasını sağlamaz.
Teorik olarak, kütüphanenin yapısını alabilir, kopyalayabilir ve tuval üzerine bir analog yapabilirsiniz. Teoride...
Sorun, Ccanvas'ın kendisinin üzerinde bir GUI oluşturmak için uygun olmamasıdır. Niye ya? Çünkü orada tuval sistemi temel olarak grafik ilkellere uyarlanmıştır. Yani aslında bu sınıf ilkellerden başka bir şey sağlamaz. GUI mimarisinin kendiniz inşa edilmesi gerekiyor. Ve bu durumda, sınıf isteğe bağlıdır. Kendi kararlarını vermek daha iyidir. Sonuçta, bu sınıf olmadan dikdörtgen bir etiket çizebilirsiniz. Bir tuval nasıl oluşturulur veya yüklenir. Çok basit. Bu nedenle, çözümümü tercih ettim.
Ancak, herhangi bir şekilde CCanvas'ı olmayan birine. Bu nedenle ısrar etmiyorum.
CCanvas ile ilgili sorun, GUI'sinin kesinlikle grafik penceresine bağlı olmasıdır.
Yani, terminal arayüz modülü şeklinde tam teşekküllü bir pencere yapılamaz.
Ve kendi arayüz modüllerinizi yazmak çok güzel olurdu.
biraz farklı tabii :-)
Python/Ruby/etc'de GUI olarak paylaşılan Tk grafiklerine sahip bir Tcl DLL'sine (bir Araç Ortak Dili olan) bir arayüz gönderdim.
GUI elde etmek amaç değildi, bu bir tür güzel yan etki :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
bence uygun ve en önemlisi kısa :-)
Kimseyi kışkırtmıyorum - tcl / tk biliyorum, kullanıyorum, en iyi uygulamalarımı paylaştım (bkz. sourceforge atcl)
Evet Max, TCL'den ve daha sonra tartıştığımız prototipinden bahsediyorum. Kullanıcının bilgisayarında uygun kitaplığı yüklemesi gerektiğine dair bir sınırlama vardı. Zor değil gibi görünüyor, ama yine de bu belirli bir sınırlama.
Geçmişte bırakalım. Max, mantığa katıl. Roman, ayrıca bağlayın))).
Yukarıdakilere dayanarak, yapı öğesinin belirli bir diyalog kontrolü olduğu, kendi özelliklerini içerdiği ve iç içe kontroller içerebileceği anlaşılabilir. Böyle bir evrensel kontrolün özellikleri, yalnızca geliştiricinin hayal gücü ile sınırlıdır.
Tabii ki, yapıya yükselemezsiniz, ancak çok boyutlu bir dizideki kontrollerin özelliklerini tanımlayabilirsiniz, ancak bu başlangıçta uygun maliyetli değildir, çünkü bazı özelliklerin hangi dizinde saklandığını açıkça hatırlamanız gerekir. Ve bir dizi heterojen veri türleri içeremez. Prosedürel programlamada bir kontrol elemanını sadece yapılar aracılığıyla tanımlamanın mümkün olduğu ortaya çıktı. Yani, bir yapı elemanı belirli bir kontrol elemanıdır, yani kendi özelliklerine sahip belirli bir diyalog nesnesidir.
CCanvas ile ilgili sorun, GUI'sinin kesinlikle grafik penceresine bağlı olmasıdır.
Yani, terminal arayüz modülü şeklinde tam teşekküllü bir pencere yapılamaz.
Ve kendi arayüz modüllerinizi yazmak çok güzel olurdu.
o zaman bir ters çöp olacak - arayüzü programa bağlamak için. Örneğin, kesinlikle bir zaman damgasına ve bir fiyata bağlı bir düğme yapın.
işte uçuşta yazılmış ayrı bir GUI - tüm tablolar, sekmeler, menüler ve ıslıklarla. C# veya hatta BASIC'te. Ve grafiğin içinde - bu, harici uygulamalar için önemli bir sorundur.
Herhangi bir diyalog elemanı (form, kontrol elemanı (düğme, liste, resim)) bazı özelliklere sahiptir. Prosedürel programlama, "mülk" veya "alan" kavramını tanımlamaz. Prosedürel programlamada fonksiyonlarımız ve değişkenlerimiz vardır (global veya local). Ancak değişkenler paylaşılır, yani her bir bağımsız kontrolün özelliklerini tanımlamak için kullanılamazlar. O zaman çıkış yolu nedir? Evet basit - yapılar!
Evet, bir yapı, kontrol öğesinin gerekli özelliklerinin yanı sıra bir dizi iç içe (kabul edilebilir) kontrol öğesinin bir açıklamasına sahip olabilir.
Her şey bir dizi iletişim kutusunda saklanır.
Daha evrensel hale getirilebilir: kontrol tanımlama yapısı iki diziden oluşur: bir dizi özellik ve bir dizi alt öğe. Bir özellik dizisi, bir Özellik-Değer çiftinin yapılarının bir dizisidir. Bu yaklaşımla, her yeni denetim herhangi bir isteğe bağlı özellik kümesine sahip olabilir. Ancak işleme için uygun değildir. Kontrol öğesinin belirli özelliklerini yapıda belirtmek daha mantıklı olacaktır: boyutlar, konum, renk, çerçeve, vb. - herhangi bir kontrol öğesinin ihtiyaç duyduğu her şey.
Pekala, yapıda bu öğenin bir dizi pikseli de olacaktır.
Bir fare olayı alındığında, imlecin belirli bir kontrole vurup vurmadığını kontrol etmek için döngü tüm diziler boyunca yinelenir. Kontrol, sondan birinciye doğru yapılır.
İmlecin hangi kontrole çarptığı ortaya çıkar çıkmaz, bu dizi elemanı yeniden çizim işlevine gönderilir ve ardından kaynak diziyi günceller ve grafikteki resmi güncelleriz.
1. Temel kontrollerin en basit yapısını tasarladığınızı varsayalım - bir pencere, bir düğme, bir onay kutusu. Her biri bir dizi bileşen parçadan oluşur - nesne. Onay kutusu - taban, metin, simge. Düğme - taban, metin, simge vb. Her öğenin her nesnesi kendi özelliklerine sahip olmalıdır. Bunları bir yapı veya sınıf içinde yazabilirsiniz ama bence sakıncalı. Niye ya? - çünkü onları pencereye yerleştirerek, imleçle tuval üzerinde bulmanız gerekir. İmleci hareket ettirdiğinizde, odakta olmaları gerekir. Bunun için mevcut koordinatları bir dizide olmalıdır. Ve tüm özelliklerinin (geçerli koordinatlar dahil) tek bir dizide olması daha uygundur. Böylece, imlecin odağına giren tuval üzerindeki herhangi bir öğenin herhangi bir özelliğine anında erişebilirsiniz. Ayrıca, bir dizi öğe üzerinde döngü yapmak daha kolaydır.
Yani, imlecin çarptığı öğe için arama döngüsünde BİR diziyi atlamak daha kolaydır. Ve bu dizi global ise daha da kullanışlıdır. Daha sonra herhangi bir fonksiyonda gerekli bilgileri ondan alabilir ve herhangi bir fonksiyonda gerekli özelliklerin, gerekli elemanların değerlerini değiştirebilirsiniz.
Bu, öğelere en kısa ve en verimli erişim ve bunların en hızlı işlenmesidir. Bu benim çekirdeğim.
2. Ancak, profesyonellerin kaprislerinin standart OOP'nin maksimum taklidi için çaba gösterdiğini bilerek, bu teknolojiyi sunmuyorum.
3. Bir piksel dizisinin herhangi bir yerde saklanması gerekmez. Dizideki elemanların parametrelerine göre ihtiyaç anında oluşturulur. Örneğin: pencereyi yeniden çizmeniz gerekiyor. Yeniden çiz işlevini çağırıyoruz. İşlev, öğe dizisine erişir, tüm özellikleri görür, bir piksel dizisi bildirir, boyutunu hesaplar, nesnelerini sırayla öğeler üzerinde bir döngü içinde çizer, ResourceCreate() öğesini çağırır. Herşey.
4. İmlecin altındaki öğe, yeniden çizim için aynı işleve gönderilir. Bir bildirim (eleman yeniden çizim bayrağı) ve eleman dizisindeki numarasını alır. Ardından, işlev gerekli kaynağı ResourceReadImage() aracılığıyla çağırır, onu piksel dizisine iter ve ardından piksel dizisinin içinde istenen öğenin alanını bulur ve tüm nesnelerini yeniden çizer. ResourceCreate() ile kaydeder. Herşey.
1. Temel kontrollerin en basit yapısını tasarladığınızı varsayalım - bir pencere, bir düğme, bir onay kutusu. Her biri bir dizi bileşen parçadan oluşur - nesne. Onay kutusu - taban, metin, simge. Düğme - taban, metin, simge vb. Her öğenin her nesnesi kendi özelliklerine sahip olmalıdır. Bunları bir yapı veya sınıf içinde yazabilirsiniz ama bence sakıncalı. Niye ya? - çünkü onları pencereye yerleştirerek, imleçle tuval üzerinde bulmanız gerekir. İmleci hareket ettirdiğinizde, odakta olmaları gerekir. Bunun için mevcut koordinatları bir dizide olmalıdır. Ve tüm özelliklerinin (geçerli koordinatlar dahil) tek bir dizide olması daha uygundur. Böylece, imlecin odağına düşen tuval üzerindeki herhangi bir öğenin herhangi bir özelliğine anında erişebilirsiniz. Ayrıca, bir dizi öğe üzerinde döngü yapmak daha kolaydır.
Yani, imlecin çarptığı öğe için arama döngüsünde BİR diziyi atlamak daha kolaydır. Ve bu dizi global ise daha da kullanışlıdır. Daha sonra herhangi bir fonksiyonda gerekli bilgileri ondan alabilir ve herhangi bir fonksiyonda gerekli özelliklerin, gerekli elemanların değerlerini değiştirebilirsiniz.
Bu, öğelere en kısa ve en verimli erişim ve bunların en hızlı işlenmesidir. Bu benim çekirdeğim.
2. Ancak, profesyonellerin kaprislerinin standart OOP'nin maksimum taklidi için çaba gösterdiğini bilerek, bu teknolojiyi sunmuyorum.
3. Bir piksel dizisinin herhangi bir yerde saklanması gerekmez. Dizideki elemanların parametrelerine göre ihtiyaç anında oluşturulur. Örneğin: pencereyi yeniden çizmeniz gerekiyor. Yeniden çiz işlevini çağırıyoruz. İşlev, öğe dizisine erişir, tüm özellikleri görür, bir piksel dizisi bildirir, boyutunu hesaplar, nesnelerini sırayla öğeler üzerinde bir döngü içinde çizer, ResourceCreate() öğesini çağırır. Herşey.
4. İmlecin altındaki öğe, yeniden çizim için aynı işleve gönderilir. Bir bildirim (eleman yeniden çizim bayrağı) ve eleman dizisindeki numarasını alır. Ardından, işlev gerekli kaynağı ResourceReadImage() aracılığıyla çağırır, onu piksel dizisine iter ve ardından piksel dizisinin içinde istenen öğenin alanını bulur ve tüm nesnelerini yeniden çizer. ResourceCreate() ile kaydeder. Herşey.
Aslında, bu inşaat teknolojisinden bağımsız olarak gerçekleşmelidir. Sadece farklı algılanabilir. Sizin durumunuzda, dizide dolaşıp imlecin hangi kontrolde olduğunu belirlersiniz. Yukarıdakilere dayanarak, dizini belirledikten sonra, bulunan öğenin özelliklerini hemen görürsünüz. Ancak farklı türdeki verileri tek bir büyük dizide nasıl saklayabilirsiniz?
Aslında, bu inşaat teknolojisinden bağımsız olarak gerçekleşmelidir. Sadece farklı şekillerde algılanabilir. Sizin durumunuzda, dizide dolaşıp imlecin hangi kontrolde olduğunu belirlersiniz. Yukarıdakilere dayanarak, dizini belirledikten sonra, bulunan öğenin özelliklerini hemen görürsünüz. Ancak farklı türdeki verileri tek bir büyük dizide nasıl saklayabilirsiniz?
Prensip olarak, türleri genelleştirmek mümkündür. Nesne özelliklerinin büyük çoğunluğu int türündeyse, kötü bir şey olmayacağı sonucuna vardım. Diğer tüm (çift, grafik nesnelerinin özelliklerinde pratik olarak yoktur) kısaltılmış türler, basitleştirme uğruna reddettim. Belleğin "aşırı harcanması" o kadar önemsizdir ki, onu düşünmenin bir anlamı yoktur. Tabii ki, profesyonelliği yükseltmek uğruna, hiçbir şekilde böyle bir küfüre gidemezsiniz))) Ama şimdi 21. yüzyıl ve yangın beni tehdit etmiyor.))
Nesnelerin adlarını numaralandırdım ve bunları genel nesne özellikleri satırına koydum.
Farklı bir veri tipine ihtiyaç duyduğum tek yer kontrollerin parametreleriydi. Orada, parametrelerin özelliklerini depolayan ikinci bir çekirdek oluşturdum ve değerlerin kendisi, herhangi bir şeye kolayca aktarabileceğim (daha doğrusu parametre özelliklerinde yazılanlara) dize türündedir.
not. "Bir kontrolün parametresi", ELEMAN TARAFINDAN KONTROL EDİLEN PARAMETRE anlamına gelir.1. Temel kontrollerin en basit yapısını tasarladığınızı varsayalım - bir pencere, bir düğme, bir onay kutusu. Her biri bir dizi bileşen parçadan oluşur - nesne. Onay kutusu - taban, metin, simge. Düğme - taban, metin, simge vb. Her öğenin her nesnesi kendi özelliklerine sahip olmalıdır. Bunları bir yapı veya sınıf içinde yazabilirsiniz ama bence sakıncalı. Niye ya? - çünkü onları pencereye yerleştirerek, imleçle tuval üzerinde bulmanız gerekir. İmleci hareket ettirdiğinizde, odakta olmaları gerekir. Bunun için mevcut koordinatları bir dizide olmalıdır. Ve tüm özelliklerinin (geçerli koordinatlar dahil) tek bir dizide olması daha uygundur. Böylece, imlecin odağına düşen tuval üzerindeki herhangi bir öğenin herhangi bir özelliğine anında erişebilirsiniz. Ayrıca, bir dizi öğe üzerinde döngü yapmak daha kolaydır.
Yani, imlecin çarptığı öğe için arama döngüsünde BİR diziyi atlamak daha kolaydır. Ve bu dizi global ise daha da kullanışlıdır. Daha sonra herhangi bir fonksiyonda gerekli bilgileri ondan alabilir ve herhangi bir fonksiyonda gerekli özelliklerin, gerekli elemanların değerlerini değiştirebilirsiniz.
Bu, öğelere en kısa ve en verimli erişim ve bunların en hızlı işlenmesidir. Bu benim çekirdeğim.
2. Ancak, profesyonellerin kaprislerinin standart OOP'nin maksimum taklidi için çaba gösterdiğini bilerek, bu teknolojiyi sunmuyorum.
3. Bir piksel dizisinin herhangi bir yerde saklanması gerekmez. Dizideki elemanların parametrelerine göre ihtiyaç anında oluşturulur. Örneğin: pencereyi yeniden çizmeniz gerekiyor. Yeniden çiz işlevini çağırıyoruz. İşlev, öğe dizisine erişir, tüm özellikleri görür, bir piksel dizisi bildirir, boyutunu hesaplar, nesnelerini sırayla öğeler üzerinde bir döngü içinde çizer, ResourceCreate() öğesini çağırır. Herşey.
4. İmlecin altındaki öğe, yeniden çizim için aynı işleve gönderilir. Bir bildirim (eleman yeniden çizim bayrağı) ve eleman dizisindeki numarasını alır. Ardından, işlev gerekli kaynağı ResourceReadImage() aracılığıyla çağırır, onu piksel dizisine iter ve ardından piksel dizisinin içinde istenen öğenin alanını bulur ve tüm nesnelerini yeniden çizer. Herşey.
vay canına, bu sonsuz olumsuzluk, hat boyunca
Oraya nasıl geldiğini hiç merak ettiniz mi? Gerçek şu ki, prosedürel tarzda yazan ve OOP hakkında bilgisi olmayan birçok kişi, fonksiyonları gruplama arzusuyla karşı karşıya kalır, daha sonra bu arzu, bu fonksiyonları tek bir hafıza alanında birleştirme ve ona atıfta bulunma arzusuna dönüşür, yani. fiziksel olarak bir değişkende saklanan işlevlere sahip bir bölüme bağlantı. Ardından, seçilen işlev grubumuzda kodu çoğaltmadan değişiklik yapma arzusu var (miras alıyoruz). Bu nedenle, başlangıçta yalnızca prosedür stiline aşina olan bir kişi, bir süre sonra şu soruyu sorar - µl'de neden bu kadar çok kısıtlama var (çoklu kalıtımın referansı).
Genel olarak, bir kişinin OOP'yi hemen öğretmesinin daha kolay olduğuna inanılmaktadır, çünkü prosedürel stile aşina olursa, yeniden eğitim çok zor olacaktır (insanların çoğu için), ancak başkaları da var çünkü. başlangıçta sadece prosedürel bir tarzdı... yukarıda açıklanan.
Tehdit OOP'de, prosedürel kod düzeyinde OOP'ye aşina olduğu varsayılan bir çeşitlilik vardır ve ben gerçekten OOP'yi sonuna kadar kullanıyorum.
Bir sınıf, ana diziyi korurken yeniden yazılabilen ve eklenebilen işlevlerin belleğine (tablosu) bir başvurudur + değişkenlere bir başvurudur. ve başka ne olduğunu çoktan unuttum .... (32 bayt ağırlığında olmalı)
Arama sonsuz bir iştir, son zamanlarda yerleşik sıralama işlevini Kırmızı sıralama ile karşılaştırdım (şablon olanlardan biri), belirli koşullar altında 3-6 kat hız kaybediyor (yerleşik olan kayıp =)
GUI'DE standart yöntemler olduğunu düşünüyorum.
,
vay canına, bu sonsuz olumsuzluk, hat boyunca
Oraya nasıl geldiğini hiç merak ettin mi? Gerçek şu ki, prosedürel tarzda yazan ve OOP hakkında bilgisi olmayan birçok kişi, fonksiyonları gruplama arzusuyla karşı karşıya kalır, daha sonra bu arzu, bu fonksiyonları tek bir hafıza alanında birleştirme ve ona atıfta bulunma arzusuna dönüşür, yani. fiziksel olarak bir değişkende saklanan işlevlere sahip bir bölüme bağlantı. Ardından, seçilen işlev grubumuzda kodu çoğaltmadan değişiklik yapma arzusu var (miras alıyoruz). Bu nedenle, başlangıçta yalnızca prosedür stiline aşina olan bir kişi, bir süre sonra şu soruyu sorar - µl'de neden bu kadar çok kısıtlama var (çoklu kalıtımın referansı).
Genel olarak, bir kişinin OOP'yi hemen öğretmesinin daha kolay olduğuna inanılmaktadır, çünkü prosedürel stile aşina olursa, yeniden eğitim çok zor olacaktır (insanların çoğu için), ancak başkaları da var çünkü. başlangıçta sadece prosedürel bir tarzdı... yukarıda açıklanan.
Tehdit OOP'de, prosedürel kod düzeyinde OOP'ye aşina olduğu varsayılan bir çeşitlilik vardır ve ben gerçekten OOP'yi sonuna kadar kullanıyorum.
Bir sınıf, ana diziyi korurken yeniden yazılabilen ve eklenebilen işlevlerin belleğine (tablosu) bir başvurudur + değişkenlere bir başvurudur. ve zaten başka ne olduğunu unuttum .... (32 bayt ağırlığında olmalıdır)
Arama sonsuz bir iştir, son zamanlarda yerleşik sıralama işlevini Kırmızı sıralama ile karşılaştırdım (şablon olanlardan biri), belirli koşullar altında 3-6 kat hız kaybediyor (yerleşik olan kayıp =)
GUI'DE standart yöntemler olduğunu düşünüyorum.
,
OOP kavramına karşı olumsuz bir tavrım yok. Ben de onun hayranıyım. Standartlara karşı olumsuz bir tutumum var. Daha doğrusu, onları akılsızca takip etmek.)
Aksi takdirde, OOP için varım. Ancak, basitleştirilmiş için.