MetaEditor yapı 1490 - sayfa 6

Yeni yorum
 
Andrey Dik :
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örüntülenir (ayrıca ne olduğunu da açıklar). Bu nedenle tutarsızlıklar.
 
Andrey Barinov :
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.

 
Andrey Dik :

Servis masası, düzelteceklerini, bugünün yapısında bir düzeltmenin mevcut olacağını söyledi.

1491 - düzeltilmedi.
 
fxsaber :
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.

 
Andrey Dik :

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.

bu konuda

DEAL_ENTRY_INOUT dahil olsa bile, siz ENUM_DEAL_PROPERTY_* genişletene kadar hiçbir faydası olmayacaktır.

 
fxsaber :
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).

 
Andrey Dik :

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.

 
fxsaber :

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.

 
Andrey Dik :

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.

Geliştiricilerin düşünmesine izin verin. En çok önerinizi beğendim. Ancak bunun kabul edilemez bir sanallaştırma gerektirdiğini anlıyorum.
 

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.

12345678
Yeni yorum