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
Standart kitaplık , kontrollerin form üzerinde oluşturulduğu anlamına gelir. Sadece hiç çalışmıyor gibi görünüyorlar. En azından eskiden böyleydi.
Grafik arayüzlerle ilgili bir dizi makaleden Kazharsky'nin en son sürümlerini denemek gerekecek. Ne kadar hızlı çalışıyor. Ve sonra yavrularını düzeltmek için geliştiricilere bir kez daha yazın.
herkes aynı daire içinde yürür! ))) - MQL'nin olanaklarını incelemeye başladığım grafik arayüzler hakkındaki bu makale dizisindendi .... - deneyim başarısız oldu, makalelerden bazı örnekler artık derlenmiyor, yazar iletişime geçiyor , ama kütüphanenin hacmi çok büyük, ben bu kütüphaneyi kullanmadım, mümkün olsa da
IMHO, ya bir hafta içinde C# çalışın - internette birçok örnek var ve VS'deki form tasarımcısı Delphi'dekiyle aynı (Delphi'de daha önce yazdım) ya da hala SB kullanıyor - en azından geliştiricilerden destek var
herkes aynı daire içinde yürür! ))) - MQL'nin olanaklarını incelemeye başladığım grafik arayüzler hakkındaki bu makale dizisindendi .... - deneyim başarısız oldu, makalelerden bazı örnekler artık derlenmiyor, yazar iletişime geçiyor , ama kütüphanenin hacmi çok büyük, ben bu kütüphaneyi kullanmadım, mümkün olsa da
IMHO, ya bir hafta içinde C# çalışın - internette birçok örnek var ve VS'deki form tasarımcısı Delphi'dekiyle aynı (Delphi'de daha önce yazdım) ya da hala SB kullanıyor - en azından geliştiricilerden destek var
Bu kütüphanenin çoktan tamamlandığını duymak üzücü. Bir buçuk yıl önce denedim, panelin görüntüsünü beğendim. Hatta MT4 altında düzelttim ve denedim (Tuval'daki farklılıklar nedeniyle, bir şeyler de hemen derlenmedi), ama sonra evet, onu görevime taşımanın karmaşıklığı nedeniyle SB'yi aldım. GUI'lere daha sonra geri döneceğimi düşündüm.
C#'da bir haftada zar zor ustalaşabiliyorum. Ancak, özellikle .NET kitaplıkları için zaten yerel destek bulunduğundan, kendinize bu hedefi belirlemeniz gerekir. Böylece, özel göreviniz için nasıl kullanılabileceğini önerdiniz.
Ve ikinci durumda,
nedense senin seçeneğinle işe yaramadı, belki yine batırdım)) ,
ama sonunda istediğim ortaya çıktı - verileri ara işaretçiler olmadan doğrudan listeye kaydetmek istiyorum, bellek sızıntısı olmadan bu şekilde çalışır:
bu benim fikrimin sadece başlangıcı
CData sınıfı alan şablonunu kullanarak bir dosyaya nasıl yazacağımı bulana kadar uygulamak için şablonumdaki bir ikili dosyaya yazmak ve okumak istiyorum (bir metin dosyasına da yazabilseniz de - önemli değil) - ancak Gerçekten istiyorum! ;)
CData sınıfı alan şablonunu kullanarak bir dosyaya nasıl yazacağımı bulana kadar uygulamak için şablonumdaki bir ikili dosyaya yazmak ve okumak istiyorum (bir metin dosyasına da yazabilseniz de - önemli değil) - ancak Gerçekten istiyorum! ;)
CList ve CObject ile hiç çalışmadım, ancak kaynaklar basit (bu arada, bir nedenden dolayı const değiştiricisi olmayan sanal bir Save yöntemi var), bu yüzden hemen çalıştı.
PS Böyle yazmak daha kolay
O zaman yapıcı/yıkıcı gerekli değildir. yeni/sil gerçekten yararlı olduğu yerde kullanmak hala mantıklı. Aksi takdirde, yukarıdaki DOSYA ile aynı şeyi yapabilirsiniz.
CList ve CObject ile hiç çalışmadım, ancak kaynaklar basit, bu yüzden hemen işe yaradı.
Ö! çok hızlı yanıt aldı! - TEŞEKKÜR EDERİM! - gece yapılacak bir şey.
Ayrıca CList ve CObject kaynaklarını da okudum, herhangi bir sorun görmüyorum ancak testlerin yapılması gerekiyor.
Not: burada, genel olarak, almak istediğim şey ... peki, evrensel bir liste gibi görünüyor:
1. Oluşturulduktan hemen sonra yapı sınıfları ekleyebileceğiniz (uygulandı - örnek verilerimi kontrol ettim.AddValue(new CData(i,i*2.0)) - OK)
2. İçinde bir dosyaya yazıp "DB" dosyasından okuyabileceğiniz (Şablon kurucusu bunu görünce yazmaya başladım)
1 ve 2 numaralı dosyaya yazmadan/okumadan çalışıyoruz diskten CDataBase oluştururken veritabanını okuyoruz, yıkıcı çağırırken diske yazarken
....
not:
Peki, tüm bunlar neden? - Danışmanları standart şemaya göre yazıyorum - sihir ve sihirle bir sipariş arayarak emirlerle tüm manipülasyonlar, eğer TS "101 göstergeye" göre değilse, ancak daha karmaşıksa, genellikle 2 sihir yeterlidir, ANCAK 80 bekleyen siparişi takip eden TS (10 sipariş ızgarası, ızgaralar yeniden açıldı ve ... dürüst olmak gerekirse, saçma bir TS, ancak bununla ikinci kez karşılaştım), sonra çeşitli hileler başlıyor - 80 için 80 sipariş çalıştırıyorum üretilen sihirler))) - Çıktım ama tüm bunlardan hoşlanmıyorum
bu yüzden sonunda, siparişler hakkında (evet, herhangi bir şey) veri yazabileceğiniz küçük bir veritabanı yapmak istiyorum ve asıl şey veritabanının kendisine hiç dikkat etmemek - dizi öğelerine erişim, bir dosyaya okuma ve yazma danışmanı başlatırken veya kapatırken
böyle bir şey)))
PS Böyle yazmak daha kolay
O zaman yapıcı/yıkıcı gerekli değildir. yeni/sil gerçekten yararlı olduğu yerde kullanmak hala mantıklı. Aksi takdirde, yukarıdaki DOSYA ile aynı şeyi yapabilirsiniz.
Teşekkürler, ama yine de bunun hakkında düşünmeniz gerekiyor ... veya daha doğrusu, gelecekte düşünmemek için yapmak istiyorsunuz))) - OnInit()'te bir veritabanı oluşturdular, dosyayı okudu, DeInit()'te veritabanını öldürdüler, dosyayı yazdı ve DeInit()'de silmeyi kaçırdıysanız, o zaman terminalin kendisi bunu günlüğe kaydeder... bence bu, veritabanıyla çalışırken hataları ortadan kaldırır. ..genel olarak yaparsam ne kadar uygun olduğu görülecektir.
zorlaştırmıyorsa, neden burada "::" kullanıyorsunuz https://www.mql5.com/en/docs/basis/operations/other
zorlaştırmıyorsa neden burada "::" kullanıyoruz
Aksi takdirde, ebeveyn sınıflarında aynı isimde bir yöntem olmadığını kontrol etmem gerekecek. Ve olmasa bile, biri onu eklerse kod çalışmaya devam eder.
Aynı nedenden dolayı, bunu her zaman belirsizlik ve okunabilirlik için kullanırım.
ZY Ancak bazı nadir durumlarda :: ve bu esneklikten mahrumdur. Yöntem gövdesini sınıfın içine ve ne zaman - dışarıda yazmanın daha iyi olduğu konusunda benzer incelikler vardır. Bütün bunlarla karşılaştığımı hatırlıyorum ama örnek vermeyeceğim.
Aksi takdirde, ebeveyn sınıflarında aynı isimde bir yöntem olmadığını kontrol etmem gerekecek. Ve olmasa bile, biri onu eklerse kod çalışmaya devam eder.
Aynı nedenle, bunu her zaman belirsizlik ve okunabilirlik için kullanırım.Evet gerçekten pratik ve bug görünümünü ortadan kaldırıyor, hizmete alacağım
Teşekkür ederim!
4. m_fsave dosyasına yazma bayrağı etkinse, AddValue() yöntemini her çağırdığımızda dosyaya yazarız
CList kayıt formatına bakın. Onu görmezden geliyorsun.