MQL5 için dilekler - sayfa 28
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
belki de söylenmiştir...
1) şifreleme ile ve bilgisayar kimliğine (armandillo paketleyicisinin analogu) referansla bir seri numarası oluşturma yeteneği ile derleme yeteneği ekleyin,
tüm bunlar kaynak değil, çevirmenin iç yetenekleri düzeyinde yapılmalıdır.
2) terminalin çalışmasını diğer programlardan kontrol edebilmeniz, sunucuya bağlanabilmeniz / bağlantısını kesebilmeniz, sunucu ile bağlantıyı kontrol edebilmeniz, bir fiyat teklifi arşivi talep edebilmeniz, sipariş verebilmeniz için harici programlarla etkileşimli çalışma yeteneği ekleyin ... vb.
3) gelen kenelerden bağımsız olarak sipariş verme yeteneği
4) birkaç DC/hesap ile eşzamanlı çalışma desteği
5) hata ayıklama DLL'sini geri getirin
6) en azından yapılar için destek ekleyin, ancak genel olarak olasılıkları c ++ 'a daha yakın olacak şekilde genişletmek istenir.
Yardıma yürütülebilir bir geçiş olasılığını eklemek gerekir, cat. programı bir web sayfasına getirir (örneğin, istenen metni içeren bir pencere açar).
Kullanıcı anlaşılmaz bir şey yaptı - program ona şunu söylüyor: İşte durumla ilgili bir danışma, doğru okuyun ve daha fazla aptalca şeyler yapmayın.
sk,
TP ve SL sipariş penceresinde sadece mutlak değerlerde değil, aynı zamanda göreceli değerlerde ve son değerin otomatik olarak değiştirilmesi ile gereklidir. örneğin, TP=2 ve SL=10'a bir kez bahis yaparsınız ve daha sonra sadece satın alır veya satarsınız, yani sağlığınıza pip verirsiniz. çok uygun olacak. Aksi takdirde, bu rahatsızlıktan dolayı, geçenlerde al veya sat'a tıkladıktan sonra TP ve SL'yi verilen değerlerle ayarlaması için bir danışmanı kasten beceriksizdim.
Pek çok dilek! Zaten 28 sayfa!
Geliştiricilerden, halihazırda geliştirilmekte olan, hiçbir zaman uygulanmayacak ve olabilecek dileklerin neler olduğunu duymak istiyorum.
Ve başka bir şey istemeye değip değmeyeceği belli değil, geri bildirimi göremezsiniz.
Tabii ki, zamanlamasını da bilmek istedim. Yazılımların piyasaya sürülme zamanını tahmin etmenin bazen döviz kurlarının hareketini tahmin etmekten daha kolay olmadığını anlıyorum.
Eh, en azından bu biçimde: "MT5'in beta sürümü ..................'den daha erken piyasaya sürülmeyecek." Böyle bir cümle yazılabilir mi?
Ve başka bir şey istemeye değer mi, yoksa geri bildirim görünür mü belli değil.
Magic'i aktif bir sırayla yeniden atamakla ilgili miydi? Fikir basit: Çok dönemli ticaret ile, uzun bir trendle bir emri daha yüksek bir zaman dilimine aktarmak mümkün olacak.
Magic'i aktif bir sırayla yeniden atamakla ilgili miydi? Fikir basit: Çok dönemli ticaret ile, uzun bir trendle bir emri daha yüksek bir zaman dilimine aktarmak mümkün olacak.
Kısacası: 4 dönem için tek bir ticaret stratejisi kullanıyorum, yani. bir algoritmaya göre giriş / çıkış / takip ilkeleri (gösterge seti ve sinyal türü), ancak her dönem için göstergelerin parametreleri doğal olarak farklıdır (aslında bunlar bir grafikte 4 Uzman Danışmandır), bölünerek Büyü . Sonuç olarak, daha eski zaman dilimlerinde durum daha eski zaman dilimlerinde olmasına rağmen, daha düşük dönemlerde, piyasadaki durumun gerçekten hak ettiğinden çok daha erken pozisyon kapatma belirtileri olduğu ortaya çıktı (yani, yanlış yönde herhangi bir hapşırma kâr eksikliğine neden olur). çok kararlıdır. Oynaklığın göreliliği göstergeleri etkiler. Daha yüksek zaman dilimlerinde istikrarlı durumlarla, daha düşük zaman dilimlerinde açık pozisyonlar kapatılmamalı, ancak Magic'i değiştirerek onları daha yüksek bir zaman diliminin mantığına aktarın. Evet, aslında uygulama sadece zaman dilimleri için değil, başka bir işlem mantığına aktarmak içindir. Bana öyle geliyor ki DC için özel bir sorun olmayacak. bilet kalır, ancak faydalar biriktirilebilir.
Kısacası: 4 dönem için tek bir ticaret stratejisi kullanıyorum, yani. bir algoritmaya göre giriş / çıkış / takip ilkeleri (gösterge seti ve sinyal türü), ancak her dönem için göstergelerin parametreleri doğal olarak farklıdır (aslında bunlar bir grafikte 4 Uzman Danışmandır), bölünerek Büyü . Sonuç olarak, daha eski zaman dilimlerinde durum daha eski zaman dilimlerinde olmasına rağmen, daha düşük dönemlerde, piyasadaki durumun gerçekten hak ettiğinden çok daha erken pozisyon kapatma belirtileri olduğu ortaya çıktı (yani, yanlış yönde herhangi bir hapşırma kâr eksikliğine neden olur). çok kararlıdır. Oynaklığın göreliliği göstergeleri etkiler. Daha yüksek zaman dilimlerinde istikrarlı durumlarla, daha düşük zaman dilimlerinde açık pozisyonlar kapatılmamalı, ancak Magic'i değiştirerek onları daha yüksek bir zaman diliminin mantığına aktarın. Evet, aslında uygulama sadece zaman dilimleri için değil, başka bir işlem mantığına aktarmak içindir. Bana öyle geliyor ki DC için özel bir sorun olmayacak. bilet kalır, ancak faydalar biriktirilebilir.
Anlamı açıktır.
Ancak böyle bir fikir uğruna, terminal ile sunucu arasındaki iletişimin dilinde ve teknolojisinde değişiklik yapmaya gerek olmadığını düşünüyorum. Sonuçta, terminalin yan tarafındaki programda ihtiyacınız olan her şey dikkate alınabilir. Ayrıca, sihri değiştirme fikri, stratejinin ve kriterlerinin eksikliklerini açıkça ifade eder. Sihir (örneğinizden de anlaşılacağı gibi), ilke olarak, düzenin kapatılmasını gerektiren sarsılmaz bir kriter taşımaz ve taşıyamaz. veya açık Bir stratejinin sihire (bir düzene bağlı) dayanamayacağını ve olmaması gerektiğini anlamak kolaydır. Basitçe çünkü sihrin pazarla hiçbir ilgisi yok.
Bence bu, ticaretteki en önemli anlardan biridir. Sadece dilde bir sihirbaz belirdi, kolun altına düştü ve biz - hadi buna bağlanalım.. Aslında, durum her yeni tikte, tarih öncesi piyasa emri açılış fiyatlarının olmaması gibi, yeni bir tik olarak düşünülmelidir. ).
Ve sihir, biraz faydalı olmasına rağmen, benim görüşüme göre, muhasebe için çok uygun bir mekanizma değil .. kim bilir ne. Benim düşünceme göre, sipariş benzersiz bir şekilde tanımlanabilseydi (yeniden açılırken ve kısmen kapanırken), o zaman sihir anlamını tamamen kaybederdi.
Anlamı açıktır.....
Bazı argümanlar vermeye çalışacağım, sondan başlayacağım ...
Benim düşünceme göre, bir nesne için bir sipariş alırsak, o zaman şu anda sihir, programlama açısından, SL veya TP seviyesi gibi, bu nesnenin tam teşekküllü bir değişken özelliğidir. Belki yanılıyorum, ancak MQL'de şu anda terminalde yürütülen kodla ilgili olarak bir siparişi tüm olası yaşam aşamalarında (yeniden açarken ve kısmen kapatırken) benzersiz bir şekilde tanımlamak mümkün değildir ve sihir bu durumu telafi eder. daha büyük ölçüde. Sihir piyasaya bağlı olmamalıdır - sadece farklı bir kapsamı vardır ve anlamı dışında herhangi bir anlam yükü taşımaz.
Piyasadaki durumu tarih dışı olarak değerlendirmek durumunda size katılmama izin verin... Ama bu benim kendi görüşüm. Karlı bir siparişle, bir karar vermek için daha yüksek zaman dilimine bakmak veya küçük bir geri dönüşe oturmak ve daha yüksek zaman diliminde siparişle çalışmaya devam etmek veya sadece beklenti eksikliği nedeniyle kapatmak hala mantıklı.
Stratejinin uygulanabilirliğini ve eksikliklerini tartışmayacağım - tamamen katılıyorum ... Ama sadece bunun üzerinde çalışıyorum :-)
Sunucu ve terminal arasındaki alışverişin dilini ve protokolünü nasıl değiştireceğimi bilmiyorum... Şu anda, sihirli değer ataması zaten var ve sipariş verirken sunucu tarafından kabul ediliyor. Değişim protokolü formatı hakkında bilgim yok, ancak bunun belirli bir veri yapısının aktarım üzerinden paket aktarımı ve ardından tutarlılık doğrulaması olduğuna dair şüpheler var. OrderModify'a iletilen veri yapısına isteğe bağlı bir parametre daha eklemek bence zor değil. Geliştiricilerin atomik değişim protokolünün yolunu tuttuklarından ve bu nedenle kendilerini zorlu sürüm oluşturma desteği sürecine soktuklarından derinden şüpheliyim.
Genel olarak, planları sordum :-) Hayır, hayır.