Çaydanlıktan gelen sorular - sayfa 12
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
LÜTFEN MOBİL TERMİNAL ÜZERİNDEN TALEP EDİNİZ.
ÖZEL GÖSTERGELER (STANDART OLMAYAN) VEYA mql4 VEYA mql5 ÜZERİNDEKİ DANIŞMANLAR İÇİN DESTEK NE ZAMAN VE OLACAK? ???
BU HANGİ PLATFORMLARDA (ÖRNEK ANDROID) UYGULANACAK?????????????????????? VE NE KADAR YAKINDA?????????????
Cevabınızı bekliyorum, DİKKATİNİZ İÇİN TEŞEKKÜRLER
Interesting :
Valla ben bu sonuca katılmıyorum. OCO == "biri diğerini iptal eder". Eh, MT5'te bir siparişin aslında diğerini iptal etmesi gibi bir şey yoktur . Bir yıldır pişman olduğum şey. ... SL ve TP gibi fırsatlar gerçekten açık bir pozisyonu kapatır, ancak bekleyen emirlerin "karşılıklı iptali" sorunuyla hiçbir ilgisi yoktur .
Sadece sahipler, ancak bunlar sunucuda uygulanan emirlerdir. Ve şimdiye kadar OCO şemasına gerçekten yazılanlar (ve henüz doğrudan terminalde ve sunucuda uygulanan "Yapılırsa" hayal edilemez).
Bir pozisyon açıp TP ve SL'yi MT5'e yerleştirerek, esasen bunun gibi bir şey biliyoruz (sadece burada sonuç bir pozisyon + karşılıklı olarak iptal edilen 2 emirdir).
Mesajınızdan sonra, SL ve TP'nin değiştirilebilirliğine yapılan referansları dikkate alarak durum hakkında biraz yorum yaptım. Burada şunu eklemek isterim.
OCO siparişlerinin yazarlarına 21. yüzyılda buluşlarının yalnızca SL ve TP seviyelerine uygulanacağı söylenseydi, beyin çocuklarının kapsamındaki böyle bir sınırlamaya çok şaşırırlardı :) ... Aslında, her şey ters döndü. Okunan materyaller ne olursa olsun, her zaman tek bir şeyden bahsediliyor: OCO siparişleri, türleri artık ENUM_ORDER_TYPE MQL5 numaralandırmasında yansıtılan karşılıklı olarak değiştirilebilir siparişlerdir. OCO siparişleri ile SL-TP seviyeleri arasındaki bağlantıdan hiç bahsetmedim. Onlar. yürütme mekanizması aynı olabilir, ancak OCO emirleri müşteri tarafından ENUM_ORDER_TYPE emirlerine göre verildi ve SL-TP seviyelerine göre değil (MQ versiyonuna göre).
Bu nedenle, bekleyen emirler hakkında yazdığımda, SL-TP seviyelerine göre "türev"* emirleri değil, ENUM_ORDER_TYPE numaralandırmasından gelen emirleri kastediyorum.
______________
* "türevler" - çünkü OCO siparişlerinin her biri kendi SL-TP seviyelerine sahip olabilir.
Beyler, anlayışın kökü platformun basitliğinde yatar. Kullanıcıların geri kalan yüzdesinin anlayabileceği komplikasyonları bilinçli olarak reddeden kullanıcıların %99'u için basitlik.
Kendinize "X milyon kullanıcıyı finans piyasalarına çekmek için ne yapılmalı?" sorusunu sorun. Yeterli bir deneyim seviyesiyle, cevap "basit bir sistem yapmak, karmaşıklığı ortadan kaldırmak ve tüccarları tek bir ekosistemde birleştirmeye" yakın olacaktır.
OCO sipariş ayarlarını yığmak yerine (panel gerçekten ortalama akıl için değil), entegre SL / TP ile çok basit ve anlaşılır bir sipariş yönetimi şeması önerdik. OCO siparişlerinin büyük çoğunluğu, mevcut pozisyonlar için yalnızca SL/TP'dir. SL/TP'yi içeriye sokarak ek siparişlerin sayısını en aza indirdik ve işlemlerin yönetimini büyük ölçüde basitleştirdik.
ps: sipariş sistemi sorunu kapanmıştır
ps: sipariş sistemi sorunu kapanmıştır
ps: sipariş sistemi sorunu kapanmıştır
Bireysel işlemler için (toplam pozisyon için değil) normal (güvenilir) SL / TP yapmanın mümkün olmaması üzücü.
Bu, aynı enstrüman/hesap üzerinde birden fazla stratejiyi (güvenilir şekilde) takas etme yeteneğini anında keser.
Hali hırsızı Devam etmemeyi öneriyorum, geliştiricilerin görüşlerini hatırlıyorum (bir araç = bir pozisyon = bir SL ve bir TP) ...
ORDER_MAGIC aslında ne tür (uzun veya uzun)?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Siparişi veren uzmanın tanımlayıcısı (her uzmanın kendi benzersiz numarasını belirlemesi amaçlanmıştır)
uzun
ORDER_MAGIC aslında ne tür (uzun veya uzun)?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Siparişi veren uzmanın tanımlayıcısı (her uzmanın kendi benzersiz numarasını belirlemesi amaçlanmıştır)
uzun
Bence sonuç, kodda belirtilen türe dönüştürülmelidir (belgelerde yazım hatası olabilir).
MqlTradeRequest'ten bahsetmişken, bu durumda büyük olasılıkla (ulong), ancak uzun süre yorum yapmadan çalışması mümkün olsa da.
Bence sonuç, kodda belirtilen türe dönüştürülmelidir (belgelerde yazım hatası olabilir).
MqlTradeRequest'ten bahsetmişken, bu durumda büyük olasılıkla (ulong), uzun süre yorum yapmadan çalışması mümkün olsa da.
Genel olarak, cevap konuya değil. Soru özeldi: "ORDER_MAGIC aslında hangi türe (uzun veya ulong) ait ?"
Gerçek olarak deneyelim:
1. Bu türlerin her ikisini de dönüştürme olmadan bildirebilirsiniz.
2. Magick'in yalnızca pozitif değerlerini kullanırsanız, değerini ulong olarak belirtmek daha karlı olur (çünkü 0 ile 18 446 744 073 709 551 615 arasında bir dizi olası değer vardır).
3. Öte yandan, standart kütüphanenin CExpert sınıfında, başlatma sırasında long değeri kullanılır (bu, negatif değerler belirtmenize izin verir, ancak olası değerler aralığını kaydırır). Bu nedenle, bu sınıfı başlatırken, sihirli değer zaten -9 223 372 036 854 775 808 ile 9 223 372 036 854 775 808 arasında olabilir.
Bu iddia doğrulanmalıdır .
4. Ama zaten CTrade sınıfında (aynı standart kitaplığın), sihir, istek yapısına dayanması gerektiği gibi, ulong değerine sahiptir.
Ön sonuçlar çıkaralım:
a) CExpert ve CTrade sınıflarında sihirle çalışmak, bir durumda long , diğerinde ulong belirtildiğinden tutarlı değildir;
b) Bu sınıflar farklı kişiler tarafından geliştirilmiştir veya CExpert'teki belirli işlevlerin parametrelerinin bileşimi ve yapısı, CTrade'in işlevselliği dikkate alınmadan atılmıştır (bu, doğada bile olamazdı).
c) Standart kitaplığın geliştirilmesi ve belgelenmesiyle ilgili uzmanların çalışmaları tam olarak koordine edilmemiştir (temelde temel konulara ilişkin oldukça iyi bir çalışma görünür olmasına rağmen).
d) Doğru anladıysam, bu iki sınıfın etkileşimi, magick değerini 0 ile 9 223 372 036 854 775 808 arasında bir aralıkla sınırlar. Bu iddia doğrulanmalıdır .
5. MqlTradeRequest yapısı, sihirle çalışmak için ulong tipine sahiptir. Buradaki her şey CTrade sınıfıyla tamamen tutarlıdır, bu nedenle yalnızca bu sınıfı kullanırsanız, olası sihirli değerler aralığını 0 ile 18 446 744 073 709 551 615 arasında belirtmek mantıklıdır. Bu iddia doğrulanmalıdır .
not
Genel olarak, tüm bunlar garip. öyle bir izlenim ki geliştiriciler, büyünün olası değerlerini 0 ila 9 223 372 036 854 775 808 aralığında kasıtlı olarak "sıkıştırdı".
Genel olarak, tüm bunlar garip. öyle bir izlenim ki geliştiriciler, büyünün olası değerlerini 0 ila 9 223 372 036 854 775 808 aralığında kasıtlı olarak "sıkıştırdı".
Aslında, sihir için 8 bayta kadar bilgi verilir, bu da istediğiniz gibi yorumlanabilir. En az tarihsaat, en az double, en az 4 kısa, en az 8 karakter, en az 64 bit bit bit.
Dördünde, 4 bayt sihir herhangi bir şeyi kodlamak için yeterliydi ve şimdi 8'e kadar. Bir arzu olurdu.