Benim yaklaşımım. Çekirdek - Motor. - sayfa 172
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
Peter, şikayet edecek bir şey arıyormuşsun gibi geliyor.
Cevap veriyorum: hayır, bir metin öğesiyle hiç çalışmadım ve çalışmayacağım. Ama eğer tek soru buysa, aynı tanımlar üzerinde zeka yapmak hiç de sorun değil.
ps Bu arada, senin için de işe yaramaz:
Basil, bu önemsiz bir şey değil. Karmaşık pencereler ve büyük tablolar oluştururken, kullanıcı manuel olarak kaydetmesi ve hatta hatırlaması veya formda araması gereken öğelerin adlarına takılıp kalacaktır.
ben bu çizgiye sahibim
bir sarıcıya dönüşür:
Adını hecelememe ya da hatırlamama gerek yok. İstenen öğeyi intellisens listesinde buluyorum.
Basil, bu önemsiz bir şey değil. Karmaşık pencereler ve büyük tablolar oluştururken, kullanıcı manuel olarak kaydetmesi ve hatta hatırlaması veya formda araması gereken öğelerin adlarına takılıp kalacaktır.
...
Metin parametreleri için zeka yapmanın asla bir sorun olmadığını tekrar edeceğim. Her şeyi bir kerede teklif etmemi ister misin? Bu olmaz.
Metin parametreleri için zeka yapmanın asla bir sorun olmadığını tekrar edeceğim . Her şeyi bir kerede teklif etmemi ister misin? Bu olmaz.
Evet, ancak bunun için keskin üzerinde tanımlı bir dosya yazdırmanız ve ardından MQL dosya sanal alanına aktarıp programa bağlanmanız gerekir. GUI'nin içeriğindeki her değişiklikte bunu yapmak özellikle güzel olacaktır.))
Dmitry, MVC diye bir mimari model var. Benim yaklaşımım tam olarak bununla ilgili. Bu nedenle eleştiri yaptığınızda öncelikle MVC'yi eleştirirsiniz ve size göre "jo ..." üzerinden yapılan Angular, ASP Net MVC, Ruby on Rails ve uzman dikkatinize layık olmayan diğer ürünler gibi çözümler. Bu nedenle, sizinle neden tartışmak ve kararımın geçerliliğini kanıtlamak istemediğimi açıklığa kavuşturmak gerektiğini düşünüyorum - bu sadece anlamsız.
Yani MVC farklıdır ...
Ek olarak, bu modelin burada uygulanamazlığını sadece teorik argümanlarla değil, tamamen pratik olarak haklı çıkarmak çok kolaydır, çünkü burada bir çiçek çayırında yürüyüşe çıkan bir gaz maskesi gibidir.
Kullanıcının, çağrısını programda onlarca yere yerleştirdikten sonra öğenin adını değiştirmeye karar verdiğini varsayalım. Tüm aramalarda değiştirmeli mi?
Programda var, gerekli değil. Bir öğe sarmalayıcı, adını yalnızca gevşek bir şekilde iletir. Örneğin "Set lot", " E_Trade_panel__Set_lot(); " olur ve ismi "SET LOT" olarak değiştirirsem yeni bir sarmalayıcı oluşturmam gerekmez.
Ve kararında Vasily, tüm aramalarda adı yeniden yazman gerekiyor.
Evet, ancak bunun için keskin üzerinde tanımlı bir dosya yazdırmanız ve ardından MQL dosya sanal alanına aktarıp programa bağlanmanız gerekir. GUI'nin içeriğindeki her değişiklikte bunu yapmak özellikle güzel olacaktır.))
Peter, C# ve Visual Studio'nun sağladığı tüm teknolojiler konusunda güncel değilsin. Özellikle, T4 ve montaj yönergelerinin yardımıyla, oluşturulan tanımların bir dosya sanal alanına aktarılması da dahil olmak üzere bu süreç tamamen otomatikleştirilebilir.
Hayır Peter, C# ve Visual Studio ile rekabet edemezsin. farklı ağırlık kategorileri.
Peter, C# ve Visual Studio'nun sağladığı tüm teknolojiler konusunda güncel değilsin. Özellikle, T4 ve montaj yönergelerinin yardımıyla, oluşturulan tanımların bir dosya sanal alanına aktarılması da dahil olmak üzere bu süreç tamamen otomatikleştirilebilir.
Hayır Peter, C# ve Visual Studio ile rekabet edemezsin. farklı ağırlık kategorileri.
Peki neden denemeyeyim? En azından yerel MQL ile yazılmış yardımcı programların satılabildiği gerçeğiyle zaten kazandım ve C# ile ne kadar uğraşırsanız uğraşın, bu avantajda beni geçemezsiniz.))
Karmaşık GUI programları yazmanın kolaylığına gelince, bunu zaten test ettim ve siz henüz denemediniz. Bu nedenle, şu anda benimle rekabet etmeye çalışan C# ile sizsiniz, tersi değil. :))
Karmaşık GUI programları yazmanın kolaylığına gelince, bunu zaten test ettim ve siz henüz denemediniz. Bu nedenle, şu anda benimle rekabet etmeye çalışan C# ile sizsiniz, tersi değil. :))
Peter, neyi test ettin? Yayınınız nerede? Hala kağıt üzerinde her şeye sahipsiniz.
Peki neden denemeyeyim? En azından yerel MQL ile yazılmış yardımcı programların satılabildiği gerçeğiyle zaten kazandım ve C# ile ne kadar uğraşırsanız uğraşın, bu avantajda beni geçemezsiniz.))
Peter, ticari bir Kyu olduğun ortaya çıktı!
Peter, C# ve Visual Studio'nun sağladığı tüm teknolojiler konusunda güncel değilsin. Özellikle, T4 ve montaj yönergelerinin yardımıyla, oluşturulan tanımların bir dosya sanal alanına aktarılması da dahil olmak üzere bu süreç tamamen otomatikleştirilebilir.
Hayır Peter, C# ve Visual Studio ile rekabet edemezsin. farklı ağırlık kategorileri.
Eh, gelişimi yanlış yöne çektin Vasily.
Burada bu bağdaştırıcıyı GitHub'da açık kaynak yaptınız. Ve C#'ın en geniş olasılıklarından bahsediyorsunuz, örneğin herhangi bir şeyi bir dosya sanal alanına transfer etme yeteneği gibi. Ve kimsenin bu adaptöre istediğini eklemeyeceğini ve kapalı bir viral sürüm dağıtmaya başlamayacağını mı düşünüyorsunuz? Ve onu alacak "dulavratotu" yok mu?