Geçersiz istek - daha yeni başladı ve anlayamıyorum... - sayfa 8

[---]

papaklass :

Bana göre tam olarak öyle, sadece işlevler aracılığıyla uygulanır.

anladım. kodunuzda, MK'de olduğu gibi - OrderCheck ve OrderSend arasında, kullanıcı tarafından bir hata işleme katmanı vardır.

[Renat Fatkhullin]

papaklass :

Bana göre tam olarak öyle, sadece işlevler aracılığıyla uygulanır.

OrderCheck, OrderSend içinde örtük ve zorunlu olarak kontrol edilir.

Yani sipariş yanlış doldurulursa, yanıt sunucuya gönderilmeden hemen geri dönecektir.

[Renat Fatkhullin]

papaklass :

Bakalım kılavuz bu konuda ne diyor:

İlk seçim: işlevin, çeklerle ilgili bir kelime değil, ticaret işlemlerini gerçekleştirmeye yönelik olduğunu görüyoruz.

Çekler var diyorsam doğrudur.

Tek bir uygulama bile terminali sıkı kontroller olmadan terk etmez.

İkinci seçim: Kontrollerin sunucu üzerinde yapıldığını görüyoruz ve isteği sunucuya göndermeden önce kontrol etmek için geliştiriciler OrderCheck() işlevini kullanmanızı tavsiye ediyor. Ve yine, OrderSend() fonksiyonunun herhangi bir kontrol gerçekleştirdiğine dair bir kelime yok.

Özellikle tüccarların siparişin doğru bir şekilde doldurulup doldurulmadığını önceden öğrenme ve uygun önlemleri alma fırsatına sahip olmalarını öneririz.

Kim ister - önceden kontrol edebilir. İstemiyorsanız, yine de onun için kontrol edeceğiz ve benzer cevaplar vereceğiz.

Talebi göndermeden önce kontrolden bahsedildiği tek yer "Yapıların temel kontrolünün başarılı olması durumunda (kontrol işaretçileri) ...". Ancak hata istek yapısının işaretçilerini kontrol etmek ve alan değerlerini kontrol etmek aynı şey değildir. Ve geliştiricilerin OrderCheck() işlevini kullanma önerisi, OrderSend()'in sunucuya bir istek göndermeden önce gerçek hata denetimi gerçekleştirmediğinin dolaylı kanıtıdır. Aksi takdirde, neden "tereyağı yağı": önce OrderSend() kontrolleri ve ardından aynı kontrolün OrderCheck() kullanılarak tekrar yapılması gerekiyor?

Bu nedenle, kesin cevap, kontrolün yalnızca sunucuda gerçekleştirildiği dizinden gelir!

Sunucuya yapılan hatalı veya aşırı istek akışını kimse kaçırmaz.

Bunu anlamak için temel mantık yeterlidir. Belgeleri genişletelim.

[[Silindi]]

sergeev :

sende yok tüm hatalar iş mantığı tarafından ele alınır.

Sahibim. İş mantığı, iş mantığıyla ilgili olayları (örneğin, sipariş verme hatası) işler, ancak geri kalan her şey (örneğin, sunucu yanıt gecikmesi), kesinlikle herhangi bir Uzman Danışmanın uygulanabileceği evrensel bir şablon tarafından işlenir. .

Ancak MT5, dönüş kodları + eşzamansızlık işleme açısından çok daha zordur.

Bahsettiğimiz şey bu, daha önce de benzer şekilde yazdığım gibi ve bu konuda sıfır bilgi var. Ve MK yıllardır mümkün olan her şekilde kendisini onun hükmünden ayırmaya çalışıyor. Bunun hakkında yazdım - bir ürün, bir tahliyeye yol açan anların olduğu bayiler için faydalıdır, yani. MQ için bu, satışları artıran bir faktördür. Ne yazık ki, yoldaşların değil rakiplerin (biz ve MQ) olduğu bir pazardayız.

Bir paketleyiciden imkansızı istiyorsun. Standart kitaplık iş mantığı değildir. Bu, terminalin işlevleri "üzerinde" bir sarıcıdır. Şeker dolgusu üzerine sarıcı.

O zaman böyle bir yapısal tasarımda çok az anlam var.

Ancak kefil siz olduğunuz için ambalaj hiçbir şeyi garanti edemez. iş mantığınız. dolgu. :)

Yazdır işlevi gibi, boş disk alanını garanti edemez. Ve günlük hataları. Bunu yapmak için, diğer işlevlerin hata işlemesini kullanmanız gerekir ve bunlar durumlara özeldir.

Doğru paketleyici bile her şeyi garanti edemez, ancak birçok ilgili işlev bunu garanti edebilir.

-Alexey- , belirli eksikliklerden bahsedelim ve düzeltmek istediğiniz belirli eksiklikleri dile getireceksiniz.

Zaten belirli hakkında tekrar tekrar yazdı. MQ hazır bir çözüm sağlayamıyorsa, en azından hataların ele alınması ve kodların döndürülmesi için bir kılavuz yapmalarına izin verin. Mümkün olan her şekilde kilidi açıldı. Dördünün belgelerinde, bu kısmen mevcuttu (örneğin, böyle bir durumda 30 saniye bekleyin), kısmen kullanıcılar belgelenmemiş durumların işlenmesini deneyimlerinden belirledi. 5 için bir şey yok. Ve eğer öyleyse, kimse kullanmayacak.

Eh, MQ bu şekilde cevap verirse, çünkü yeni oluşturulan ticaret altyapısı temelde buna izin vermiyor, o zaman ne diyebilirim - bu, inanılmaz bir yığın başka pervaz olduğu göz önüne alındığında, tüm MT5 projesinin tam bir başarısızlığıdır.

İsterseniz, her bir iade kodunu inceleyebilir ve olası ana durumlara bakabilirsiniz.

Bunu sizin gibi MQL5 konusunda deneyimli bir kişiyle yapmayı çok isterim, zaman ve gerekliliğin müsait olmasını bekleyelim. Tanrıya şükür, birçok planda çok daha uygun olan 4 tane daha var.

[---]

-Alexey- :

hazır bir çözüm, en azından hataları ve dönüş kodlarını ele almak için bir kılavuz

hangi kod işleme sorunlarına neden olur?

kod	tanımlayıcı	Tanım
10004	TİCARET_RETCODE_REQUOTE	yeniden alıntı yap
10006	TİCARET_RETCODE_REJECT	Talep reddedildi
10007	TRADE_RETCODE_CANCEL	Tacir tarafından iptal edilen talep
10008	TRADE_RETCODE_PLACED	sipariş verildi
10009	TRADE_RETCODE_DONE	Başvuru tamamlandı
10010	TRADE_RETCODE_DONE_PARTIAL	Başvuru kısmen tamamlandı
10011	TİCARET_RETCODE_ERROR	İstek işleme hatası
10012	TRADE_RETCODE_TIMEOUT	Zaman aşımı nedeniyle istek iptal edildi
10013	TRADE_RETCODE_INVALID	Geçersiz istek
10014	TRADE_RETCODE_INVALID_VOLUME	İstekte yanlış hacim
10015	TRADE_RETCODE_INVALID_PRICE	Talepte yanlış fiyat
10016	TRADE_RETCODE_INVALID_STOPS	İstekte yanlış duraklar
10017	TRADE_RETCODE_TRADE_DISABLED	ticaret yasak
10018	TRADE_RETCODE_MARKET_CLOSED	piyasa kapalı
10019	TRADE_RETCODE_NO_MONEY	İsteği yerine getirmek için yeterli para yok
10020	TRADE_RETCODE_PRICE_CHANGED	Fiyatlar değişti
10021	TRADE_RETCODE_PRICE_OFF	İsteği işlemek için teklif yok
10022	TRADE_RETCODE_INVALID_EXPIRATION	İstekte geçersiz sipariş son kullanma tarihi
10023	TRADE_RETCODE_ORDER_CHANGED	Sipariş durumu değişti
10024	TRADE_RETCODE_TOO_MANY_REQUESTS	Çok sık istekler
10025	TRADE_RETCODE_NO_CHANGES	İstekte değişiklik yok
10026	TRADE_RETCODE_SERVER_DISABLES_AT	Otomatik ticaret sunucu tarafından yasaklanmıştır
10027	TRADE_RETCODE_CLIENT_DISABLES_AT	Otomatik ticaret, müşteri terminali tarafından yasaklanmıştır
10028	TRADE_RETCODE_LOCKED	İstek işlenmek üzere engellendi
10029	TİCARET_RETCODE_FROZEN	Sipariş veya pozisyon donduruldu
10030	TRADE_RETCODE_INVALID_FILL	Bakiyeye göre desteklenmeyen bir emir yürütme türü belirtildi
10031	TRADE_RETCODE_CONNECTION	Ticaret sunucusuna bağlantı yok
10032	TRADE_RETCODE_ONLY_REAL	İşleme yalnızca gerçek hesaplar için izin verilir
10033	TRADE_RETCODE_LIMIT_ORDERS	Bekleyen emir sayısı sınırına ulaşıldı
10034	TRADE_RETCODE_LIMIT_VOLUME	Bu sembol için emir ve pozisyon hacmi sınırına ulaşıldı

Güncelleme: 2012.11.14

[[Silindi]]

Örneğin 10004. Ne yapılacağı nerede yazıyor? Ve dördüncü belgelerde en azından bir şey vardı:

Можно без задержки обновить данные при помощи функции RefreshRates и повторить попытку. Если ошибка не исчезает, необходимо прекратить все попытки торговых операций и изменить логику программы.

[A100]

sergeev :

hangi kod işleme sorunlarına neden olur?

10006 (hangi nedenle reddedildi, diğer kodlarda belirtilmeyen başka hangi nedenler olabilir?)

10011, 10013, 10028

[[Silindi]]

A100 :

10006 (hangi nedenle reddedildi, diğer kodlarda belirtilmeyen başka hangi nedenler olabilir?)

10011, 10013, 10028

soruyu destekliyorum. MQ, sizden nazik bir rica. Lütfen bu 4 kod hakkında mümkün olduğunca ayrıntılı yorum yapın.

[combat.trader]

Meslektaşlar, zaten gerçeği aramaktan bıktı. Konu benim ihtiyacım olana benziyor, bu yüzden buraya yazıyorum, yardım istiyorum!

Anında yürütme ile bir emir veririm, her tıkta kilitlenirken, fiyatı kontrol ederim ve mümkünse onu izlerim. Ama nedense her zaman 10013 hatası dönüyor.Olası tüm forumlara baktım ve ilk sıradaki hemen hemen tüm satırları ekledim (açıklama bu tür bir eylem için yalnızca bir sembol, eylem ve sl ve tp'nin yeterli olduğunu söylese de) . Hiçbir şey yardımcı olmaz! İşte kod.

 // проверяем условие на открытую сделку
if (f_IsDealOpened()> 0 )
{  
   // здесь надо написать условия для коррекции ордеров
 MqlTradeRequest chrequest={ 0 };
     if ( 1 ) //(is_Str2)
   {
     PositionSelect ( NULL );
     if ( PositionGetInteger ( POSITION_TYPE )== 0 )
    {
        chrequest.symbol= PositionGetSymbol ( 0 );
        chrequest.order= PositionGetInteger ( POSITION_IDENTIFIER );
        chrequest.volume= PositionGetDouble ( POSITION_VOLUME );
        chrequest.action= TRADE_ACTION_SLTP ;
        chrequest.sl = latest_price.bid - TrailingStop;
        chrequest.tp = PositionGetDouble ( POSITION_TP );

     }
     else
     {
        chrequest.symbol= PositionGetSymbol ( 0 );
        chrequest.order= PositionGetInteger ( POSITION_IDENTIFIER );
        chrequest.volume= PositionGetDouble ( POSITION_VOLUME );
        chrequest.action= TRADE_ACTION_SLTP ;
        chrequest.sl = latest_price.ask + TrailingStop;
        chrequest.tp = PositionGetDouble ( POSITION_TP );
         Alert ( PositionSelect ( NULL ));
     
     }    
    }
     MqlTradeResult chresult;
     if ( OrderSend (chrequest,chresult)== 0 ) 
         {
             Alert ( "Ошибка расчета функции OrderSend!" );
             return ;
         }    
         // анализируем код возврата торгового сервера
         if (mresult.retcode== 10009 || mresult.retcode== 10008 ) //запрос выполнен или ордер успешно помещен
           {
             Alert ( "Ордер по изменению SL успешно помещен, тикет ордера #: " ,mresult.order, "!!" );
            open_order_ticket = mresult.order;
            open_order_price = mresult.price;
             return ;
           }
         else
           {
             Alert ( "Запрос на измнение ордера не выполнен - код ошибки: " , GetLastError ());
             return ;
           }
   
   
   return ;
}