Çaydanlıktan gelen sorular - sayfa 176

[Yedelkin]

Karlson :

3B. Yarım satış - OUT açarak kısmen kapatmak.

Kötü :/ Tarihte OUT özelliği ile birkaç işlem olabileceği ve pozisyonun var olmaya devam edeceği ortaya çıktı.

[Anatoli Kazharski]

Yedelkin :
kötü :/

Neden kötü? Seni doğru anladıysam çok basit. ÇIKIŞ ve bir konum varsa, hacimde bir azalma oldu. OUT yoksa ve pozisyon yoksa pozisyon tamamen kapatılmıştır.

[Yedelkin]

tol64 :
Neden kötü? Seni doğru anladıysam çok basit. ÇIKIŞ ve konum varsa, hacimde bir azalma olmuştur. OUT yoksa ve pozisyon yoksa pozisyon tamamen kapatılmıştır.

Bu kötü, bu yüzden. " ÇIKIŞ ve pozisyon varsa, hacimde bir azalma oldu. Bir ÇIKIŞ ve bir pozisyon varsa, o zaman pozisyon tamamen kapandı " yaklaşımınız bana hantal görünen bir özelliğe sahip: ayrıca her seferinde terminaldeki veri tabanındaki konumla ilgili bilgilerin kullanılabilirliğini kontrol edin.

Hepimiz çok iyi biliyoruz ki, terminal veri tabanındaki bilgiler, gerçek durumla ilgili olarak biraz gecikiyor. Bu nedenle, çek " OUT ve bir pozisyon var " türünden bir sonuç verdiğinde durumlar ekarte edilmez, ancak gerçekte bu işlem pozisyonu tamamen kapattı. Onlar. basitçe yanlış bilgi alabilir ve buna dayanarak hatalı adımlar atabilirsiniz. ..Ya da ek kontroller, gecikmeler bulmanız gerekecek - kim ne kadar içindeyse.

Ama bu çanlar ve ıslıklar olmadan da yapabilirsiniz. Özellikle, bir pozisyonun varlığını kontrol etmeden. Bunu yapmak için, bir pozisyonun kapanması ile DEAL_ENTRY_OUT özelliği (yazışma - şimdi Dizin'de sunulduğu gibi) arasında bire bir yazışma bırakmak ve pozisyon hacmindeki azalmayı ayrı olarak seçmek yeterlidir. işlemin mülkiyeti. O zaman geçmişte DEAL_ENTRY_OUT özelliğiyle ( HistorySelectByPosition ) yalnızca bir anlaşma bulmak ve pozisyonun azaltılmadığını, kapatıldığını ve hiçbir koşulda geri alınamayacağını kesin olarak bilmek yeterli olacaktır.

[Anatoli Kazharski]

Yedelkin :

Bu kötü, bu yüzden. " ÇIKIŞ ve pozisyon varsa, hacimde bir azalma oldu. Bir ÇIKIŞ ve bir pozisyon varsa, o zaman pozisyon tamamen kapandı " yaklaşımınız bana hantal görünen bir özelliğe sahip: ayrıca her seferinde terminaldeki veri tabanındaki konumla ilgili bilgilerin kullanılabilirliğini kontrol edin.

Hepimiz çok iyi biliyoruz ki, terminal veri tabanındaki bilgiler, gerçek durumla ilgili olarak biraz gecikiyor. Bu nedenle, çek " OUT ve bir pozisyon var " türünden bir sonuç verdiğinde durumlar ekarte edilmez, ancak gerçekte bu işlem pozisyonu tamamen kapattı. Onlar. basitçe yanlış bilgi alabilir ve buna dayanarak hatalı adımlar atabilirsiniz. ..Ya da ek kontroller, gecikmeler bulmanız gerekecek - kim ne kadar içindeyse.

Ama bu çanlar ve ıslıklar olmadan da yapabilirsiniz. Özellikle, bir pozisyonun varlığını kontrol etmeden. Bunu yapmak için, bir pozisyonun kapanması ile DEAL_ENTRY_OUT özelliği (yazışma - şimdi Dizin'de sunulduğu gibi) arasında bire bir yazışma bırakmak ve pozisyon hacmindeki azalmayı ayrı olarak seçmek yeterlidir. işlemin mülkiyeti. O zaman geçmişte DEAL_ENTRY_OUT özelliğiyle ( HistorySelectByPosition ) yalnızca bir anlaşma bulmak ve pozisyonun azaltılmadığını, kapatıldığını ve hiçbir koşulda geri alınamayacağını kesin olarak bilmek yeterli olacaktır.

OnTrade'de () sunucudan bir yanıt alırız. Yani, OnTrade'de () olayı kontrol edersek, o zaman bir pozisyon olup olmadığını zaten kesin olarak bileceğiz. DEAL_ENTRY_ FULL OUT (tam kapanma) veya DEAL_ENTRY_ PART OUT (kısmi kapanma) gibi normal seçenekler yapmak mümkün olsa da, her şey mükemmel bir şekilde zarif. )))

Bu arada her seferinde "hantal kontrollere" girmemek için ayrı işlevler yapabilirsiniz.

[Yedelkin]

tol64 :

DEAL_ENTRY_ FULL OUT (tam kapanma) veya DEAL_ENTRY_ PART OUT (kısmi kapanma) gibi normal seçenekler yapmak mümkün olsa da, her şey mükemmel bir şekilde zarif. )))

Bahsettiğim şey bu.. Aynı OnTrade'de, önerilen çözümün (FULLOUT / PARTOUT) arka planına karşı hala hantal görünen ek kontroller yapmanıza bile gerek kalmayacak.

[Anatoli Kazharski]

Yedelkin :
Bahsettiğim şey bu.. Aynı OnTrade'de, önerilen çözümün (FULLOUT / PARTOUT) arka planına karşı hala hantal görünen ek kontroller yapmanıza bile gerek kalmayacak.

Hizmet Masasında bir teklif olarak göndermeyi deneyin. Bir gün düşünülebilir ve uygulanabilir.

[Yedelkin]

tol64 :
Hizmet Masasında bir teklif olarak göndermeyi deneyin. Bir gün düşünülebilir ve uygulanabilir.

Evet, zaten yaptım :) Dil hatası olarak.. Vay be, bir saat yazdım.

[Anatoli Kazharski]

Yedelkin :
Evet, zaten yaptım :) Dil hatası olarak.. Vay be, bir saat yazdım.

Yine de hata denilemez. Ama şimdi gönderdikten sonra ne yapabilirsiniz? ))

[Yedelkin]

tol64 :
Yine de hata denilemez. Ama şimdi gönderdikten sonra ne yapabilirsiniz? ))

Eh, burada değerlendirme kategorileri biraz devreye giriyor :) Hatalar kategorisine atamayı haklı çıkarmaya çalıştım :)

[Валерий]

Yedelkin :

Evet, her dönem belirli bir değere karşılık gelir. Birkaç yıl önce forumda birisi yazmıştı. Aşağıdakine benzer bir satır çalıştırarak kendi başınıza öğrenebilirsiniz:

Komut dosyası, ondalık sistemdeki tüm dönemler için ENUM_TIMEFRAMES değerlerini yazdıracaktır :

 void OnStart ()
  {
//---
   for ( int i=( int ) PERIOD_CURRENT ;i<=( int ) PERIOD_MN1 ;i++)
     {
       ResetLastError ();
       string period= EnumToString (( ENUM_TIMEFRAMES )i);
       if ( GetLastError ())
         continue ;
       Print ( EnumToString (( ENUM_TIMEFRAMES )i)+ "=" + IntegerToString (i));
     }
  }
//+------------------------------------------------------------------+