MetaEditor yapı 1490 - sayfa 6
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
https://www.mql5.com/en/forum/162399/page3#comment_3894115
Bir süredir, bir pozisyon tersine çevrildiğinde, Pozisyon Kimliği DEĞİŞİYOR. Bu yardımda gösterilmiştir. Bu nedenle tutarsızlıklar.
Sorun bu değil.
Servis masası, düzelteceklerini, bugünün yapısında bir düzeltmenin mevcut olacağını söyledi.
Servis masası, düzelteceklerini, bugünün yapısında bir düzeltmenin mevcut olacağını söyledi.
1491 - düzeltilmedi.
Ne yazık ki hayır.
Bu arada, mevcut pozisyon muhasebesi sisteminde, pozisyonun bir öncekini kapatan kısmının ve yeni pozisyonun kalan kısmının nasıl bölüneceği hiç belli değil (şimdi böyle bir bölünme yok). Sorun ilk bakışta göründüğünden daha derin gibi görünüyor.
Ne yazık ki hayır.
Bu arada, mevcut pozisyon muhasebesi sisteminde, pozisyonun bir öncekini kapatan kısmının ve yeni pozisyonun kalan kısmının nasıl bölüneceği hiç belli değil (şimdi böyle bir bölünme yok). Sorun ilk bakışta göründüğünden daha derin gibi görünüyor.
DEAL_ENTRY_INOUT dahil olsa bile, siz ENUM_DEAL_PROPERTY_* genişletene kadar hiçbir faydası olmayacaktır.
bu konuda
Benim düşünceme göre, tam tersine, numaralandırmayı genişletmek değil, azaltmak gerekiyor. Yani DEAL_ENTRY_INOUT hiçbir şey yapmayan ekstra bir varlıktır.
İşte şimdi nasıl göründüğüne bir örnek
İÇİNDE; +1.0; kimlik 0
İÇİNDE; +0.2; kimlik 0
GİRİŞ/ÇIKIŞ; -2.0; ID 1 // yeni bir ID ile yeni bir pozisyon ortaya çıktı, ancak pozisyonda işlem yok, tüm işlemler önceki pozisyondan, yani komisyonlar ve takaslar 0.0
İÇİNDE; +0.2; ID 1 // listede ilk anlaşma göründü ve listedeki tek anlaşma
bu nedenle, hacmin bir kısmı yeni bir pozisyona taşınmadı ve hiçbir yerde görüntülenmiyor, bu nedenle pozisyon kimliği 1'deki hacmin bu kısmı için takaslar ve komisyonlar dikkate alınmayacak (mavi ve yeşil karşılık gelen işlem listeleri)
Şimdi, gördüğüm kadarıyla, mantıksal ve tarihsel olarak nasıl olması gerektiği (MQ'nun hangi kararı vereceği ancak tahmin edilebilir):
İÇİNDE; +1.0; kimlik 0
İÇİNDE; +0.2; kimlik 0
DIŞARI; -1.2; ID 0 // pozisyonu kapatmak için kullanılan işlem hacminin bir parçası
İÇİNDE; -0.8; ID 1 // yeni bir ID ile yeni bir pozisyon ortaya çıktı, bakiye olarak bir anlaşma var, anlaşma listede ve ilk sırada
İÇİNDE; +0.2; ID 1 // listedeki ikinci anlaşma
Böylece GİRİŞ/ÇIKIŞ anlaşma tipine hiç ihtiyaç duyulmaz. Bu yöntemle her şey doğru bir şekilde dikkate alınır ve pozisyonlardaki işlem listeleri eksiksizdir, ilgili işlemler için komisyon ve takas değerlerini yeterli şekilde almak mümkündür. Ve hangi işlemlerin (bir kısım kapandı ve diğeri yeni bir pozisyon açmak için) bir emrin parçası olduğunu belirlemek gerekirse, bunu belirlemek çok kolaydır - OUT ve IN işlemleri aynı zamana sahiptir (içinde vurgulanmıştır). gözü pek).
Benim düşünceme göre, tam tersine, numaralandırmayı genişletmek değil, azaltmak gerekiyor. Yani DEAL_ENTRY_INOUT hiçbir şey yapmayan ekstra bir varlıktır.
Anlaşma, hiçbir şekilde platforma bağlı olmayan bir yürütme varlığıdır. Ve ENTRY bayrakları bir MQ kavramıdır.
Piyasada bir işlem varsa, uygun olsa bile iki olarak temsil edilemez.
MQ toplantıya gitti ve sanallaştırma ekledi - Hedge modu. Değişim için basit sanallaştırma yapmak bile kötü bir karardır.
Ancak işlemin özelliklerinin genişletilmesi, olası koltuk değneği olmadan kolaylık sağlar.
Anlaşma, hiçbir şekilde platforma bağlı olmayan bir yürütme varlığıdır. Ve ENTRY bayrakları bir MQ kavramıdır.
Piyasada bir işlem varsa, uygun olsa bile iki olarak sunulamaz.
MQ toplantıya gitti ve sanallaştırma ekledi - Hedge modu. Değişim için basit sanallaştırma yapmak bile kötü bir karardır.
Ancak işlemin özelliklerinin genişletilmesi, olası koltuk değneği olmadan kolaylık sağlar.
Neyse ben sadece fikrimi belirttim.
Ve hangi genişleme günü kurtarabilirdi? Yine de, işlemin hangi bölümünün eski pozisyonla ve hangisinin yenisiyle ilgili olduğunu bir şekilde belirlemeniz gerekir.
Ve hangi genişleme günü kurtarabilirdi? Yine de, işlemin hangi bölümünün eski pozisyonla ve hangisinin yenisiyle ilgili olduğunu bir şekilde belirlemeniz gerekir.
1491 - Alpari-MT5-Demo. Aynı yerin ekran görüntüleri.
terminal
Gerçek kene test cihazı
Mumlar uyuşmuyor - test cihazında kabarıklar. Ayrıca, test cihazının ve terminalin geçmiş zamanı bir saat farklıdır.
Terminaldeki CopyTicks, test cihazında olduğu gibi bir saatlik fark için verileri döndürür. Bu nedenle, keneler çubuklara tam olarak karşılık gelmez.
Peki, tam bir kendini gözden düşürme söz konusu olduğunda, bir testçi olan MT5'e nasıl güvenilir? Geliştiricilerin neden test cihazında çalışacak ve tam olarak neyin işe yaradığını tam olarak bilecek referans testi Uzman Danışmanları yok? Tam bir karmaşa.