OrderSend() Soruları - sayfa 6

 
maryan.dirtyn :

bütün kafasını kırdı .. durmadı ve bu kadar .. ve bir sürü hata. uzmandan geriye kalan bu ve sonra işe yaramıyor

bunu yaparsanız, hata olmaz, ancak kaybı durdurma hala ayarlanmamıştır.

burada cevaplandı
 
Yedelkin :

Görünüşe göre, önceki sorunu oldukça anlaşılır bir şekilde açıklamadı. Tekrar deneyeceğim.

ENUM_ORDER_TYPE_FILLING numaralandırmasının değerler listesinin açıklaması geçen yıl içinde en az üç kez değişti. Önceki açıklama şöyle görünüyordu:

ENUM_ORDER_TYPE_FILLING

tanımlayıcı

Tanım

ORDER_FILLING_FOK

İşlem, yalnızca belirtilen hacimde ve siparişte belirtilene eşit veya daha iyi bir fiyattan yapılabilir. Şu anda piyasada emir sembolü için yeterli teklif yoksa emir gerçekleşmez. Bu doldurma türü, SYMBOL_TRADE_EXECUTION_INSTANT yürütme modunda kullanılır. veya SYMBOL_TRADE_EXECUTION_REQUEST .

ORDER_FILLING_IOC

Piyasada bulunan maksimum hacimde, siparişte belirtilen limitler dahilinde ve belirtilene eşit veya daha iyi bir fiyatla işlem yapma sözleşmesi. Aynı zamanda, eksik hacim için ek siparişler verilmez. Bu tür doldurma yalnızca SYMBOL_TRADE_EXECUTION_MARKET yürütme modlarında kullanılabilir. ve SYMBOL_TRADE_EXECUTION_EXCHANGE ticaret sunucusundaki sembol ayarlarına bağlı olarak.

ORDER_FILLING_RETURN

Piyasada bulunan maksimum hacimde, siparişte belirtilen limitler dahilinde ve belirtilene eşit veya daha iyi bir fiyatla işlem yapma sözleşmesi. Bu durumda eksik miktar için bu siparişte belirtilen fiyattan ek sipariş verilecektir. Bu doldurma türü yalnızca bekleyen siparişler için kullanılır ( TRADE_ACTION_PENDING ).

Görüldüğü gibi ORDER_FILLING_RETURN ile bekleyen emirler arasında birebir bir yazışma vardı, yani: ORDER_FILLING_RETURN sadece bekleyen emirlere uygulanabiliyordu ve tüm bekleyen emirlerin type_filling alanı sadece ORDER_FILLING_RETURN değeri ile doldurulabiliyordu.

Piyasa emirleri için ( action== TRADE_ACTION_DEAL ), sunucu tarafında ayarlanan yürütme modlarına bağlı olarak type_filling alanının doldurulması gerekiyordu.

Böylece belirli bir paradigma oluştu: bekleyen bir emir varsa, o zaman ORDER_FILLING_RETURN; bir piyasa emri ise, ORDER_FILLING_FOK veya ORDER_FILLING_IOC (moda bağlı olarak).

Şimdi her şey tersine döndü, yani:

ENUM_ORDER_TYPE_FILLING

tanımlayıcı

Tanım

ORDER_FILLING_FOK

Bu yürütme politikası, siparişin yalnızca belirtilen hacimde yürütülebileceği anlamına gelir. Şu anda piyasada yeterli miktarda finansal araç yoksa emir gerçekleşmez. Gerekli hacim, şu anda piyasada mevcut olan çeşitli tekliflerden oluşabilir.

ORDER_FILLING_IOC

Piyasada bulunan maksimum hacim üzerinden, siparişte belirtilen limitler dahilinde işlem yapma anlaşması anlamına gelir. Tam olarak gerçekleştirilememesi durumunda, mevcut miktar için emir gerçekleştirilir ve gerçekleşmeyen emir hacmi iptal edilir.

ORDER_FILLING_RETURN

Bu mod yalnızca ORDER_TYPE_BUY_LIMIT ve ORDER_TYPE_SELL_LIMIT siparişler için kullanılır. Kısmi işlem yapılması durumunda kalan hacim ile limit emri iptal edilmez, işlemeye devam eder.

ORDER_TYPE_BUY_STOP_LIMIT ve ORDER_TYPE_SELL_STOP_LIMIT emirleri için, aktivasyon üzerine, ORDER_FILLING_RETURN yürütme tipine sahip ilgili limit emri ORDER_TYPE_BUY_LIMIT/ORDER_TYPE_SELL_LIMIT oluşturulacaktır.

ORDER_FILLING_FOK ve ORDER_FILLING_IOC'yi yalnızca piyasa emirleriyle kullanma kısıtlaması ortadan kalktı. ORDER_FILLING_FOK ve ORDER_FILLING_IOC'nin sunucu üzerinde ayarlanan yürütme moduna bağlı olarak piyasa emirleri ile kullanımına ilişkin kısıtlama da ortadan kalktı. ORDER_FILLING_RETURN'in yalnızca limitli ve stop_limitli emirlerle kullanımına ilişkin bir kısıtlama vardı.

Bu nedenle soru şudur: ORDER_FILLING_FOK ve ORDER_FILLING_IOC modlarını limit ve stop_limit emirleri dahil tüm emirlere (hem piyasa hem de bekleyen) uygulamak kabul edilebilir mi? Değişiklikleri anlayan var mı?

Evet, bu soru kafa karıştırıcı.

ENUM_SYMBOL_TRADE_EXECUTION ve ENUM_ORDER_TYPE_FILLING arasında tam bir yazışma varsa, ikincisi açıkça gereksizdir, gerekli bilgiyi sembol tipine göre terminal ile değiştirmek mümkün olacaktır.

Dolayısıyla yazışma ahlakı yoktur ve büyük olasılıkla aynı ENUM_SYMBOL_TRADE_EXECUTION değeri ile farklı ENUM_ORDER_TYPE_FILLING değerlerine izin verilir . Burada MQ, olası seçenekler tablosunu açıklayacaktır, ancak büyük olasılıkla bu veriler, işlem yapan sunucunun ayarlarına bağlıdır.

Ve dolayısıyla ikinci ahlaki, hala ihtiyaç duyulan şey:

ancak istenen sipariş türü (hemen veya beklemede) için geçerli seçeneklerin bir listesini ( ENUM_ORDER_TYPE_FILLING ) döndürecek bir işleve ihtiyacımız var .

Çok fazla seçenek yok, bu yüzden "|" üzerinden int'ye geçebilirsiniz.

Eğer yanılıyorsam, bu sorunun tadına varmak için bana sihirli bir pendel verin, nerede sigara içilir.



 

Bu sorunu çözmek için standart kitaplığa girdim (alışkanlıktan, bir şey net değilse, başkalarının nasıl yaptığını görün).

Orada, genel olarak, bu soru hiç işlenmez, rahat kalıtım için bir işlev verdiler ve CTrade sınıfının kendisinde SetTypeFilling() kullanılmaz, type_filling alanı, ORDER_FILLING_FOK'a karşılık gelen varsayılan sıfıra başlatılır. numaralandırma.

Ve bu kadar, daha fazla hareket yok. Ve düşündüm ki, bu alan arayüzde olmadığı için sınıfın doldurulması otomatiktir.

Tehdit genel olarak cevap bekliyoruz nasıl tırmıklanır :)
 
Şimdiye kadar bir çıkış yolu görüyorum: İstediğiniz cevabı alana kadar sunucuyu çekiçlemek.
 
her.human :
Şimdiye kadar bir çıkış yolu görüyorum: İstediğiniz cevabı alana kadar sunucuyu çekiçlemek.

Gece seyir halindeyken memnun, midede kolik için güldü.

Çinliler Pentagon'un merkezi sunucusunu hacklediler.

Her Çinli şifreyi bir kez denedi.

Her saniye "Mao Tse Tung" yazıyordu.

5*10^7 denemesinde, sunucu parolanın "Mao Tse Tung" olduğunu kabul etti.

 
her.human :
Şimdiye kadar bir çıkış yolu görüyorum: İstediğiniz cevabı alana kadar sunucuyu çekiçlemek.

aptal çıkış

DT'lerle bir başlangıç için konuşacaksınız. hangi yürütme türlerini desteklediklerini ve hangi üst alıntı listesi türlerinin yürütme türlerine karşılık geldiğini öğrenin.

Meta alıntıların icat edildiği gerçeğinden beri - 3 çeşit doldurma ve 3 çeşit zaman - bu, gerçek bir komisyoncuda siparişleri doldururken gerçekliğin bir yansıması oldukları anlamına gelmez.

 
sergeev :

aptal çıkış

DT'lerle bir başlangıç için konuşacaksınız. hangi yürütme türlerini desteklediklerini ve hangi üst alıntı listesi türlerinin yürütme türlerine karşılık geldiğini öğrenin.

Meta alıntıların icat edildiği gerçeğinden beri - 3 çeşit doldurma ve 3 çeşit zaman - bu, gerçek bir komisyoncuda siparişleri doldururken gerçekliğin bir yansıması oldukları anlamına gelmez.

Burada hemen hemen aynıyım, hepsi sunucunun ayarlarına bağlı,

ancak her DC'yi çalmak da sorunludur,

peki, bir programcı kapıyı çalacak, peki, diğeri,

ancak her şeyi atlamak ve kodunuza anahtar işlemleri yazmak aşırıya kaçar.

PS, herhangi bir işlem için normal kodun birleşik bir şekilde yazıldığını kabul eder,

istisnalar mümkündür, ancak ilk olarak, istisnalar yalnızca kuralları onaylar ve ikincisi, istisnalar varsa, istisnalar yazmanız gerekir.

İşte böyle bir totoloji.

 
Urain :

Burada hemen hemen aynıyım, hepsi sunucunun ayarlarına bağlı,

ancak her DC'yi çalmak da sorunludur,

peki, bir programcı birini, diğerini çalacak,

ancak her şeyi atlamak ve kodunuza anahtar işlemleri yazmak aşırıya kaçar.

PS, herhangi bir işlem için normal kodun birleşik bir şekilde yazıldığını kabul eder,

istisnalar mümkündür, ancak ilk olarak, istisnalar yalnızca kuralları onaylar ve ikincisi, istisnalar varsa, istisnalar yazmanız gerekir. İşte böyle bir totoloji.

burada neler olduğunu anlayın.

yürütme türleri ve yürütme süreleri ile karışık metakotalar. gerçek hayatta IOC ve FOK emirlerinin yürütme süresini ifade etmesi bakımından standart değildirler.

eskiden emir yürütme türü yeterli bir addı - AON. ancak daha sonra kaldırıldı.

DC'nin çalıştığı ve siparişleri doldurduğu FIX spesifikasyonuna bakın

FIX 4.4 : TimeInForce < 59 > field

Type: char

Used In
Description

Specifies how long the order remains in effect. Absence of this field is interpreted as DAY. NOTE not applicable to CIV Orders.

Valid values:
0 = Day (or session)
1 = Good Till Cancel ( GTC )
2 = At the Opening (OPG)
3 = Immediate or Cancel ( IOC )
4 = Fill or Kill ( FOK )
5 = Good Till Crossing (GTX)
6 = Good Till Date
7 = At the Close

Metakota alan türleri vurguladım. ancak burada görebileceğiniz gibi - hepsi TimeInForce <59> etiketinin aynı grubuna girer

Ve lütfen bana söyleyin - piyasaya emir gönderen bir komisyoncu, bir MT siparişinde sağlanan IOC türünü ve GTD süresini nasıl idare edebilir? Sonuçta, bir alanı var, iki farklı alanı değil.

Bu nedenle, her komisyoncu kendisi için düşünecektir - dolgu ile ne yapacağını ve ne tür kullanacağını. Ve siparişin nasıl geri çekileceği.


Burada kurtarmaya gelen tek şey, bir piyasa ile bekleyen bir emir arasında bir fark olmasıdır. Yani, bazı yürütme türleri yalnızca gecikmeler içindir, diğerleri ise pazar içindir. Genel olarak buraya bakmak ve iletişim kurmak gerekiyor.


Ve All-Or-Nothing denilen şey tamamen farklı bir ExecInst <18> etiketinde bulunur, bu etiket MT sırasında hiçbir şekilde iletilmez. FOK tipi için dolaylı olarak (muhtemelen) varsayılmıştır.

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
sergeev :
...

Alex bu konuyu kontrol altına al lütfen. Maalesef bu konularda yüzerim.

SD'de önerilerde bulunun, onlarla sohbet edin.

Konuya biraz düzen getirmeniz gerekiyor.

Ve sonra, ne de olsa, şimdi profesyonel programlama için tamamen kullanılamaz.

 
Urain :

Alex bu konuyu kontrol altına al lütfen. Maalesef bu konularda yüzerim.
SD'de önerilerde bulunun, onlarla sohbet edin.
Konuya biraz düzen getirmeniz gerekiyor.
Ve sonuçta, artık profesyonel programlama için tamamen kullanılamaz.

Ha. ya aptalım ya da kayaklar gitmez.

Her ay metakotaların yeni bir borsaya veya pazara bağlandığını kendiniz görebilirsiniz. Buna göre, bu amaçlar için köprüler yaparlar.
Buradan, bu durumda programcılarının MT ve FIX'e sorunsuz bir şekilde (veya bunlardan birinin yeteneklerinin sınırlandırılmasıyla biraz gerginlikle) katıldığı sonucuna varıyorum.
Yani FOK ve GTC zaman türlerini birleştirmeyi başarıyorlar. Bu, iş devam ettiği için öngörülebilir gelecekte hiçbir şeyi değiştirmelerinin olası olmadığı anlamına gelir.
Aynı zamanda (anladığım kadarıyla), değişim için MT'den gelen köprü yalnızca iki tür ayarlayabilir - AON veya Kısmi. Ve MT Return'de icat edildi - muhtemelen Kısmi'ye gidiyor.

Genel olarak, FIX komisyoncusu ile MT sunucusu arasındaki etkileşim sorunları, MT'den sağlayıcılarına köprüler kuran komisyoncu progerlerinin beceri ve anlayış düzleminde yatmaktadır. Ve metakotaların hiçbir şeyi değiştireceğini düşünmüyorum, çünkü kendileri platformu uzun süredir aktif olarak pazarlara tanıtıyorlar, bu da MT sunucusunun iç yapısının gerçeklikle oldukça tutarlı olduğu anlamına geliyor.