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
...
Peter, kendi stilinde bir GUI kitaplığı yaratmakla harika bir iş çıkardın. Ancak bu vakayı yayınlamayı planlıyorsanız, yine de başka bir teknoloji için her şeyi yeniden yapmaya değer. Bu konuda size yardımcı olmaya ve adım adım kitaplığınızın tüm gücünü yeni bir yöne aktarmaya hazırım.
Alexey, denemek isterim diyelim. Bunu nasıl yapmayı öneriyorsun? İş inanılmaz.
Peter, muhtemelen bu miktarda çalışmanın küçük bir kısmını bile hayal etmiyorum. harcadınız ve yaratılan nesnelerin tüm ölçeğini hafife aldığımdan fazlasıyla eminim. ANCAK!
Her zaman olduğu gibi AMA var!
Herhangi bir proje, mutlaka programlamada bile değil. hem genel hem de özel olarak ele alınabilir.
Başlangıç olarak, oluşturulan nesnelerden soyutlarız. Yani, onları matris, yapı veya sınıf olarak temsil etmeyeceğiz. OBJECT kavramını kabul edelim (bu bir kontroldür, bir formdur, bir bütün olarak bir arayüzdür, vb.). Nesnelerin etkileşimini yapısal olarak ifade etmeye çalışıyorsunuz. Birlikte inşa edilmiş olanın yapısını anladığımızda, buna dayanarak kalıpları belirlemeye çalışacağız. Prensip olarak, tanımlanmaları gerekmez, onları uzun zaman önce tanımladığınız ve onlar için birleşik işleme yaptığınız için, sadece çalışma prensibini ve amacını açıklarsınız. Ayrıca, projenizdeki bazı nesneleri başkalarıyla değiştireceğiz. Kesinlikle sıfırdan yazmaktan çok daha zor olacak. Ama bizim durumumuzda, biraz farklı bir hedef, yani genel olarak acele edecek hiçbir yer yok. Ancak bir matris algoritmasının bir nesneye çevrilmesiyle ilgili yayınlar muhtemelen sadece yeni başlayanlar için değil, ilgi çekici olacaktır. Diğer katılımcıların bu çalışma sürecine katılacağına, fikirlerini ifade edeceğine veya şu veya bu algoritmanın daha uygun bir uygulamasını önereceğine inanıyorum.
Öyle ya da böyle, fikrin kendisi her şeyden önce algoritmanın bir blok şemasıyla temsil edilmelidir.
Önerimi yaptım. Ancak başka türlü yapabilirsiniz, hepsi arzunuza ve bu konudaki görüşünüze bağlıdır (ortak çalışma).
Peter, muhtemelen bu miktarda çalışmanın küçük bir bölümünü bile hayal etmiyorum. harcadınız ve yaratılan nesnelerin tüm ölçeğini hafife aldığımdan fazlasıyla eminim. ANCAK!
Her zaman olduğu gibi AMA var!
Herhangi bir proje, mutlaka programlamada bile değil. hem genel anlamda hem de özel olarak ele alınabilir.
Başlangıç olarak, oluşturulan nesnelerden soyutlarız. Yani, onları matris, yapı veya sınıf olarak temsil etmeyeceğiz. OBJECT kavramını kabul edelim (bu bir kontroldür, bir formdur, bir bütün olarak bir arayüzdür, vb.). Nesnelerin etkileşimini yapısal olarak ifade etmeye çalışıyorsunuz. Birlikte inşa edilmiş olanın yapısını anladığımızda, buna dayanarak kalıpları belirlemeye çalışacağız. Prensip olarak, tanımlanmaları gerekmez, onları uzun zaman önce tanımladığınız ve onlar için birleşik işleme yaptığınız için, sadece çalışma prensibini ve amacını açıklarsınız. Ayrıca, projenizdeki bazı nesneleri başkalarıyla değiştireceğiz. Elbette bu, sıfırdan yazmaktan çok daha zor olacaktır. Ama bizim durumumuzda, biraz farklı bir hedef, yani genel olarak acele edecek hiçbir yer yok. Ancak bir matris algoritmasının bir nesneye çevrilmesiyle ilgili yayınlar muhtemelen sadece yeni başlayanlar için değil, ilgi çekici olacaktır. Diğer katılımcıların bu çalışma sürecine katılacağına, fikirlerini ifade edeceğine veya şu veya bu algoritmanın daha uygun bir uygulamasını önereceğine inanıyorum.
Öyle ya da böyle, fikrin kendisi her şeyden önce algoritmanın bir blok şemasıyla temsil edilmelidir.
Önerimi yaptım. Ancak başka türlü yapabilirsiniz, hepsi arzunuza ve bu konudaki görüşünüze bağlıdır (ortak çalışma).
İyi. Elimden geleni yapacağım. Çözümleri ve mimariyi anlatacağım. Ama sonunda başarılı olur mu bilmiyorum.
Artık nesneler çekirdekte sıralanmıştır. Çıkarılmaları ve sınıflara yerleştirilmeleri gerekiyor.
1. Muhtemelen üç temel sınıf oluştururdum: Dikdörtgen etiketlerin tüm temel özelliklerini içeren "Dikdörtgen_etiket", "Simge" ve "Metin". Bu nesneler neredeyse tüm kontrollerin bir parçasıdır.
2. Ayrıca, sınıflar-halefler grubu oluşturur. Aşağıdaki kriterlere göre bölüneceklerdir: a) parametreyi kontrol eden elemanlar. b) bir parametre tarafından kontrol edilen elemanlar.
3. Sınıflarda her elementin kendine has özelliklerini tanımlardım.
Bunlar sadece ilk fikirler. Belki de hatalı.
Böyle bir şema ile, kalıtımın hemen birden çok olduğu ortaya çıkar - eleman sınıfları (mirasçılar) aynı anda üç temel sınıfın özelliklerini içermelidir.
İyi. Elimden geleni yapacağım. Çözümleri ve mimariyi anlatacağım. Ama sonunda başarılı olur mu bilmiyorum.
Artık nesneler çekirdekte sıralanmıştır. Çıkarılmaları ve sınıflara yerleştirilmeleri gerekiyor.
1. Muhtemelen üç temel sınıf oluştururdum: Dikdörtgen etiketlerin tüm temel özelliklerini içeren "Dikdörtgen_etiket", "Simge" ve "Metin". Bu nesneler neredeyse tüm kontrollerin bir parçasıdır.
2. Ayrıca, sınıflar-halefler grubu oluşturur. Aşağıdaki kriterlere göre bölüneceklerdir: a) parametreyi kontrol eden elemanlar. b) bir parametre tarafından kontrol edilen elemanlar.
3. Sınıflarda her elementin kendine has özelliklerini tanımlardım.
Bunlar sadece ilk fikirler. Belki de hatalı.
Böyle bir şema ile, kalıtımın hemen birden çok olduğu ortaya çıkar - eleman sınıfları (mirasçılar) aynı anda üç temel sınıfın özelliklerini içermelidir.
Pekala, işte biraz tartışma.
"Üç temel sınıf oluştururdum: "Dikdörtgen etiketlerin tüm temel özelliklerini içeren "Dikdörtgen_etiket", "Simge" ve "Metin" - klasik olarak, ilk nesneye yalnızca Dikdörtgen veya Dikdörtgen denir, ikincisi genel olarak Görüntü ve üçüncüsü ya ayrı özelliklerle tanımlayabilir ya da onu ayrı bir nesne yapabilir. Oluşturulan veri türünün c++ ve mql'de bir sınıf olduğunu belirtmek için, tür adından önce C'yi, yani CRectangle, CImage, CText'i belirtmek gelenekseldir. Ancak, yalnızca heterojen veriler içeren basit türler, yapı olarak oluşturmak için daha uygundur.
Öncelikle MOST kontrollerinin tüm temel özelliklerini dikkate almaya değer. Gelecekte, herhangi bir özellik eklemek mümkün olacak, bu bir sorun olmayacak.
"a) parametreyi kontrol eden elemanlar. b) parametre tarafından kontrol edilen elemanlar." - bu, kod çözme gerektirir. Bu açıklamaların ne anlama geldiğini anlamıyorum.
"Sonunda başarı olup olmayacağı" - başarı olacağından emin olmak daha iyidir. Aksi takdirde, başlamamak en iyisidir.Pekala, işte biraz tartışma.
1. "Üç temel sınıf oluştururdum: "Dikdörtgen_etiket", dikdörtgen etiketlerin tüm temel özelliklerini, "Simge" ve "Metin" içerir - klasik olarak, ilk nesneye yalnızca Dikdörtgen veya Dikdörtgen denir, ikincisi genel olarak Görüntü ve üçüncüsü, lobu ayrı özelliklerle tanımlayabilir ve ayrıca onu bir ağartma nesnesi yapabilirsiniz. Oluşturulan veri türünün c++ ve mql'de bir sınıf olduğunu belirtmek için, tür adından önce C'yi belirtmek gelenekseldir, yani CRectangle, CImage, CText
2. "a) parametreyi kontrol eden elemanlar. b) parametre tarafından kontrol edilen elemanlar." - bu, kod çözmeyi gerektirir. Bu açıklamaların ne anlama geldiğini anlamıyorum.
"Sonunda başarı olup olmayacağı" - başarı olacağından emin olmak daha iyidir. Aksi takdirde, başlamamak en iyisidir.1. En temel sınıf CGObject'dir (temel grafik nesnesi). x, y, x_size, y_sixe özellikleri ve farklı tipte koordinat ankrajları olmalıdır. Bunlar, TÜM nesnelerin ortak özellikleridir.
2. Mirasçılar - CRec, CImage, CText. Spesifik, benzersiz özelliklere sahiptirler.
3. Ardından, pencere platformu sınıfları. Bunlardan birkaçı vardır: Menü penceresi, Ayarlar penceresi, İletişim penceresi, Dinamik pencere. Belirli bir dizi özellik vardır.
3. Ardından, - eleman sınıfları. 50 parçaya kadar olabilirler. Kategorilere ayrılmıştır: 1) parametreyi işleme yöntemine göre, 2) Dekoratif.
Bu en başlangıç. Sonuçta, bir kütüphane değil, bir biçimlendirme dili yapmalıyız. Aksi halde, amaç ne?
not. Çoğu kontrol, kendilerine verilen parametre ile çalışır. Amaçlarının özü, bazı kullanıcı parametrelerini kontrol etmektir. Ancak, her öğe bunu kendi yolunda yapar.
ZYY. Eklemeyi unuttum - özellikleriyle birlikte bir temel parametre sınıfına ihtiyacınız var. Örneğin СParam.
1. En temel sınıf CGObject'dir (temel grafik nesnesi). x, y, x_size, y_sixe özellikleri ve farklı tipte koordinat ankrajları olmalıdır. Bunlar, TÜM nesnelerin ortak özellikleridir.
2. Mirasçılar - CRec, CImage, CText. Spesifik, benzersiz özelliklere sahiptirler.
3. Ardından, pencere platformu sınıfları. Bunlardan birkaçı vardır: Menü penceresi, Ayarlar penceresi, İletişim penceresi, Dinamik pencere. Belirli bir dizi özellik vardır.
3. Ardından, - eleman sınıfları. 50 parçaya kadar olabilirler. Kategorilere ayrılmıştır: 1) parametreyi işleme yöntemine göre, 2) Dekoratif.
Bu en başlangıç. Sonuçta, bir kütüphane değil, bir biçimlendirme dili yapmalıyız. Aksi halde, amaç ne?
not. Çoğu kontrol, kendilerine verilen parametre ile çalışır. Amaçlarının özü, bazı kullanıcı parametrelerini kontrol etmektir. Ancak, her öğe bunu kendi yolunda yapar.
Küçük bir beyin patlaması var ...)) Bütün bunların çizilmesi gerekiyor, aksi takdirde sindirilmeyecek. )
Küçük bir beyin patlaması var ...)) Bütün bunların çizilmesi gerekiyor, aksi takdirde sindirilmeyecek. )
)) Hiç bir şey...
CParam parametre temel sınıfının birkaç alt öğesi vardır. Sonuç olarak, kontrol edilen element parametreleri için genel özellikler vardır ve spesifik olanlar vardır. Örneğin: bir düğme, yönetilen bir bool parametre türüne sahiptir ve bir açılır listenin bir "menü" türü vardır. Yani düğme 1/0 arasında geçiş yapar ve liste kutusu sınırlı bir seçim sunar. Örneğin, bir kaydırıcının bir "aralık" parametre türü vardır - yani bir aralık. Birkaç tür daha vardır ve hepsinin benzersiz özellikleri vardır.
Bu nedenle, parametrenin temel sınıfından miras alınan sınıflar da olmalıdır. "CBool", "CRange", "CMenu" gibi bir şey.
)) Hiç bir şey...
CParam parametre temel sınıfının birkaç alt öğesi vardır. Sonuç olarak, kontrol edilen element parametreleri için genel özellikler vardır ve spesifik olanlar vardır. Örneğin: bir düğme, yönetilen bir bool parametre türüne sahiptir ve bir açılır listenin bir "menü" türü vardır. Yani düğme 1/0 arasında geçiş yapar ve liste kutusu sınırlı bir seçim sunar. Örneğin, bir kaydırıcının bir "aralık" parametre türü vardır - yani bir aralık. Birkaç tür daha vardır ve hepsinin benzersiz özellikleri vardır.
Bu nedenle, parametrenin temel sınıfından miras alınan sınıflar da olmalıdır. "CBool", "CRange", "CMenu" gibi bir şey.
Bir dakika bekle. Şimdi biraz soyut olarak düşünmeye çalışalım.
Peter, sizin bakış açınıza göre Düğme, Metin etiketi, giriş alanı, görüntü alanı gibi kontroller arasında ortak olan nedir?
Bir dakika bekle. Şimdi biraz soyut olarak düşünmeye çalışalım.
Peter, sizin bakış açınıza göre Düğme, Metin etiketi, giriş alanı, görüntü alanı gibi kontroller arasında ortak olan nedir?
1. Koordinatlar, boyutlar.
2. Koordinat bağımlılıkları, boyutsal bağımlılıklar.
3. Kontrol işlevindeki toplam özellik sayısına bağlı olarak çok daha fazla şey. Çekirdekte 270 özelliğim var. Ortak çoğunluk. Ancak, birçok özelliği destekleyen gelişmiş bir işlevselliğe sahibim. Bu nedenle, bu kadar çok sayıda özellik. En basit özelliklerle başlamalıyız.
1. Koordinatlar.
2. Koordinat bağımlılıkları.
3. Kontrol işlevindeki toplam özellik sayısına bağlı olarak çok daha fazla şey. Çekirdekte 270 özelliğim var. Ortak çoğunluk. Ancak, birçok özelliği destekleyen gelişmiş bir işlevselliğe sahibim. Bu nedenle, bu kadar çok sayıda özellik. En basit özelliklerle başlamalıyız.
Evet, tabii ki en basit özelliklerle. Aynı Metin Etiketi hangi ilkel nesnelerden oluşabilir? Veya Button basit bir varyantta hangi ilkel nesnelerden oluşabilir?