MetaTrader 4

[Endy]

OK, bod 1. vyrieseny (v Market Watch treba right-click a tam Show all).
Takze uz len bod 2. :)

Endy Napsal:
-------------------------------------------------------
> Mam otazku, ktora je asi viac vecou brokera, ale
> tiez ide o MT4.
> 1. Mam na dvoch roznych pocitacoch nainstalovane
> MT4 demo od MIGu. Na jednej instalacii mam ovela
> viac menovych parov k dispozicii na pozretie ako
> na druhej. Neviem si to vobec vysvetlit, pouzivam
> rovnake nastavenie demo serverov napr. Nic ine na
> skontrolovanie ma nenapada. Neviete niekto v com
> by mohol byt zadrhel ?
>
> 2. Neviete niekto pls o brokerovi, ktory by
> poskytoval cez MT4 data feed DJ / SP / ropa /
> zlato ?
>
> Vdaka.

[kofis]

Něco málo jsem našel k MT4, ale vypadá to spíše na reklamu IBFX :o) Chlapík údajně pro ně programoval.
Pro začínající, zajímavá šablona a přiložené indikátory, podle kterých si můžou zhotovit EA.
Jinak RocksMonitor pro konzervativnější obchodníky, kde vidíte jak jste na tom při otevření více pozic včetně svapů atd...
www.patricknouvion.com/index.php?id=104
Je tam něco i k COT indikátoru, neví náhodou někdo, jak funguje COT na Forexu.
Jirka

[PaJaSoft]

Endy: WHC, myslim, ze i North finance, dale pak Neuimex (ale nikoli do dema) a urcite jsou i dalsi... Ale POZOR, vse toto je CFD, pokud hledas prave Futures (rozdil si najdi sam), tak o zadnem nevim, ale treba 5 min TF delayed (15-30min) data ma na webu spousta serveru, staci pohledat.

Malcikk: no tak jsme se vratili do staroveku a Printu...:-) (drhne to, ale jde to)

[trigor]

PaJaSoft
omlouvám se, dlouho jsem nebyl na spojení, takže moje neodpověď nebyla otázka slušnosti, ale tech.problémů. Teď k věci, "copak tak unikatniho je v teto slozce noveho". Obávám se, že kdybych ti odpověděl podle pravdy, už by nikdy nikdo nereagoval na moje event. dotazy, jelikož jak známo s blbcem se nediskutuje.
Díky za pochopení Vlasta

[glader]

Snazim se rozchodit MT4 pres jeden proxy server. Vsechno slape normalne, ale pokud restartuji MT4, volba povolit proxy neni zatrzena a MT4 chce zalozit novy ucet. Nevite, jak na to?
Jak "ulozit" proxy?

[PaJaSoft]

Zdravim,

chci se zeptat, zda-li se nekdo potyka, pripadne rozumne resi, nasledujici problem:

- rekneme, ze mam system, ktery umistuje stopky na zacatku trading time (protoze drive v MT4 nelze) na BO level (nad High/Low predchozi session)
- MT4 neumoznuje zadat do fronty BUY/SELL STP pokud neni aktualne trading time (a vzhledem k pozicnimu zpusobu obchodovani nebudu u monitoru vysedavat 18 hodin denne, dle toho, kdy otvira ten ktery trh), resim to tedy jednoduchym EA, ktere jakmile dojde prvni tick (a zaroven je povolen trading - funkce _IsTradingAllowed ne nepodobna na Metaquotes.net techlibrary - casto, zejmena u CFD bezi datafeed, ale trading je omezen dle specifikace brokera) umistuje objednavku dle vyse uvedeneho schematu... - pokud je prvni tick v GAPu oproti predchazejicimu dni, nezada se STOP, ale LIMIT pending order
- pokud se vse povedlo, je nastaven "semafor" a o dalsi umisteni se system nepokusi (zabraneni duplicitnim objednavkam)
- dale soucasti definice inicializace EA je nastaveni commentu (extern string...)
- vse by krasne fungovalo nebyt toho, ze funkce OrderSend nekdy vrati chybovy kod (Timeout) a presto se po chvili order objevi jako aktivni... - dusledek je jasny - dve objednavky misto jedne.

Zreme s tim nejak souvisi i dalsi anomalie a sice, pokud otevru 2 grafy stejne komodity, na obou nastavuji 1min TF a umistim tuto EA, pak ve vyse uvedenem pripade se evidentne stane jeste horsi vec (overeno pruzkumem zurnalu) - na jednom grafu dojde k situaci uvedene vyse a na druhem grafu z nepochopitelnych pricin nedojde k odblokovani (bud nedochazi ticky (= neni volana funkce start() v EA) nebo _IsTradingAllowed vrati "no" po celou obchodni seanci - to jeste musim prozkoumat) a zadani objednavky vubec. Pokud si situace zavcasu vsimnu, ten graf, kde EA odvedla svoji praci a jiz je jen v pasivnim stavu, zavru, na druhem grafu zmacknu F7 a OK - v podstate se znovu provede inicializace EA, tak s dalsim tickem je vse OK zadano.

Vyse uvedena situace neni ojedinela, ale vyskytuje se v podstate kazdy den - predstavte si situaci, ze kazdy den po obchodovani resp. v nocni dobe, kdy je aktivita minimalni (pro trhy, ktere jednou +- 24 hodin) a neni na hranici BO zanalyzuji grafy, do obchodniho deniku zapisi stavy, ulozim otisky obrazovek grafu pro historicke opakovani/analyzu/zkoumani a provedu nastaveni jednotlivych EA na objednavky na dalsi den.

Take jsem jiz nahodne zaznamenal, ze pokud mam 2 EA, 2 grafy, ale jedne komodity (odlisene Comment stringem), ze pokud z nejakeho nahodneho duvodu _IsTradingAllowed neselze ani v jednom pripade (krasna race condition (RC)) z duvodu, ze v okamziku volani teto funkce se jeste ani jedno vlakno nedostalo k OrderSend, dokonce jsou oba OrderSend serializovany a skutecne provedeny i na serveru, ale OBE objednavky maji stejny Comment = DOJDE K POMICHANI A MODIFIKACI objednavky - to je vec, ktera by se obchodnimu software rozhodne stat nemela!

Jsem z toho docela zoufaly, samozrejme, ze mohu EA rozsirit o dalsi funkcionalitu v tom smyslu, ze kdyz se objednavka ulozi na server, EA se neprepne do pasivniho rezimu, ale pro jistotu pruchodem vsech objednavek si zkontroluje, zda-li si server mysli to, co po jednotlivych EA chci, ale jednak je to znacne nebezpecne - dalsi tick muze tyto prikazy aktivovat a pak je kontrola zbytecna (je-li komodita obchodovana s nenulovym spreadem, je vysledkem logicky ztrata), jednak by k teto situaci vubec nemelo dojit!

Puvodne jsem se domnival, ze je to problem konkretniho brokera (v tomto pripade WHC), ale zkusil jsem to i jinde (treba Forex - IBFX) a dochazi obcas k podobnym situacim - uz drive jsem si toho vsiml a spise jsem to prikladal lidskemu omylu a nevenoval tomu valnou pozornost, ted pri pozicnim obchodovani je to vice nez markantni.

Nejake napady jak z toho ven?

[DarkMan]

PajaSoft:
Sloziteji to neslo popsat :))
Pokud jsem vse pochopil spravne (nemas cas to moc louskat jdu na poradu) chces aby jsi nejak inteligentne rozlisoval objednavky pro jednotlive TF a systemy. Commnet string rozhodne nedoporucuji pouzivat uz jen z toho duvodu ze kdyz zavres napr pulku pozice Commnet string se zmeni automaticky ....

Takze doporucuji nasledujici postup:
Pouzivat magic number pri vystaveni objednavek a urcit u nej nejakou nezavislou skladbu napr
napr magic number bude formatu XXXYYZZQQ kde
XXX - je verze systemu
yy - verze EA
ZZ - zvolene timeframe
QQ - dalsi volne pouziti

a nasledne vzdy na zacatku fce start prochazet vsechny otevrene objednavky a zkontrolovat pocet otevrenych objednavek pro aktualni par, TF, a buhvi co jeste, pokud se takova objednavka nenachazi trpeve pak ji vystavim.....

Pote se nikdy nemuze stat ze vystavis vic jak jednu objednavku ja to tak resim a jeste se mi to nikdy nestalo....

Mira

[PaJaSoft]

DarkMan: ne, problem s identifikaci objednavek nemam... - prosim, precti si to poradne - ten popis je prave tak slozity, ze k problemu dochazi jen pri konkretnich Race conditions - 2 grafy, 2 (stejne) EA, jeden typ objednavky ve stejnem ticku - dochazi k mrseni objednavek na serveru - objednavas (system si zaregistruje) neco jineho, nez cos pres OrderSend zadal - a to je teda radny pruser!

Problem (druhy) je v kratkosti v tom, ze ackoli funkce OrderSend vrati chybu, presto se objednavka do systemu zapise... (po nejake dobe a zpravidla pozdeji nez novejsi po chybe zadavana OBJ) - napadlo mne pamatovat si GetTick() a do magic numberu pouzivat toto... (ja comment string vetsinou jako rozslisovaci znak pro EA nepouzivam, ale z "konzole" magic nezadas a modifikovat nelze)

System je to porad jeden, ale vystupni strategie je ruzna (proto 2 objednavky a nikoli jedna s 2* konktrakty a zaviranim casti) a je treba se v objednavkach vyznat - treba kvuli trailing S/L (ktere je v obou pripadech jine). System je vesmes napolo diskrecni (takze nic pro automatizovany beh), EA v tomto pripade vyuziji jen pro umisteni objednavek ASAP (coz je rychlejsi nez z konzole, navic bych u toho musel sedet).

[DarkMan]

PajaSoft:
Promin za pozdni reakci ....
Pravda ma minula odpoved byla totalne mimo prace kvapna malo platna....
To je zajimavy problem, no nevim jak to mas cele napsany tak napisu jen to co me napada a mozna to tam tak mas, ale rozhodne to neni reseni toho problemu, ale ja jsem se s nim popravde nikdy jeste nesetkal (ze by mi EA vystavila vic objednavek nez mela) a to obchoduji skoro vse vyhradne pres EA

1) EA bych neprepinal do pasivniho rezimu (pokud to teda znamena ze nastavi orders a pote nic vic neresi) proc by nemohla nad sebou delat dalsi kontrolni operace, pokud vystaveno vic entry tak jedno smaz atp...
2) Pokud to chces presto mit v pasivnim rezimu tak bych ho nastavoval az dalsim tickem kde nejdriv projdes aktualni objednavky a pokud mas vse vystaveno nastavis na pasivitu

Toto "OrderSend nekdy vrati chybovy kod (Timeout) " jsi myslel ze po zavolani OrderSend vrati funkce GetLastError() timeout? Pokud ano, kontroloval jsi co vraci OrderSend() pokud vrati -1 je tada dost divne ze nakonec se objednavka ukaze to je potom zasadni bug

Mira

[PaJaSoft]

DarkMan:

V kratkosti jsi uhodil hlavicku na hrebicka - ano OrderSend vrati -1, GetLastError rekne timeout (vrati ERR_TRADE_TIMEOUT) a presto je objednavka nakonec aktivni - kruci!

Vyjimam autenticky kus ze zurnalu a expert window dnesniho dne - jedna se o CFD Palladium, ale to neni podstatne, projevuje se to nahodne v ruznych instrumentech.

Zurnal:

01:33:57 '61723': pending order buy stop 1.00 PA at 357.8000 sl: 349.5000 tp: 0.0000
01:33:57 '61723': request was accepted by server
01:33:57 '61723': request in process
01:33:57 '61723': order was opened : #263708 buy stop 1.00 PA at 357.8000 sl: 349.5000 tp: 0.0000
01:37:16 '61723': order buy stop 1.00 PA opening at 357.8000 sl: 349.5000 tp: 0.0000 failed [Trade timeout]
01:37:16 Expert stdlib PA,M1: loaded successfully
01:37:17 '61723': pending order buy stop 1.00 PA at 357.8000 sl: 349.5000 tp: 0.0000
01:37:17 '61723': request was accepted by server
01:37:17 '61723': request in process
01:37:17 '61723': order was opened : #263711 buy stop 1.00 PA at 357.8000 sl: 349.5000 tp: 0.0000
03:25:52 '61723': pending order buy stop 1.00 PA at 357.8000 sl: 349.5000 tp: 0.0000
03:25:52 '61723': request was accepted by server
03:25:52 '61723': request in process
03:25:52 '61723': order was opened : #263989 buy stop 1.00 PA at 357.8000 sl: 349.5000 tp: 0.0000
07:43:41 '61723': delete pending order #263708 buy stop 1.00 PA at 357.8000 sl: 349.5000 tp: 0.0000
07:43:41 '61723': request was accepted by server
07:43:41 '61723': request in process
07:43:41 '61723': pending order #263708 was deleted

Expert window:

01:33:56 paja PA,M1: loaded successfully
01:33:56 paja PA,M1: loaded successfully
01:33:56 paja PA,M1: Trade context is busy!
01:33:56 paja PA,M1: Wait limit exceeded! Aborting...
01:37:16 stdlib PA,M1: loaded successfully
01:37:16 paja PA,M1: OrderSend(PA,4,1.00000000,357.80000000,0,349.50000000,0.00000000,Pozicne - trend,0,2007.04.05 23:59,16711680) returns error: trade timeout
01:37:16 paja PA,M1: open #263711 buy stop 1.00 PA at 357.8000 sl: 349.5000 ok
03:25:52 paja PA,M1: open #263989 buy stop 1.00 PA at 357.8000 sl: 349.5000 ok


Komentuji:

V 1:33:56 dosel prvni tick po otevreni marketu. V 1:33:57 (po vytvoreni instance, MT4 bohuzel provadi instancovani EA az po obdrzeni ticku... grrr) se tedy jaly 2 (stejne) EA (2 okna s grafem stejne komodity, stejne TF..) provest objednavku - samozrejme, ze ta prvni vyhrala a druha "odesla" na "Trade context is busy!" & "Wait limit exceeded! Aborting..." (v ramci jednoho volani start()). JENZE tento request blokoval az do 1:37:16 obchodni kanal (kontext) a neslo provadet jne operace... budiz... Volani OrderSend s uvedenymi parametry (viz vypis Expert window v 1:37:16) vratilo 01, GetLastError vratilo ERR_TRADE_TIMEOUT. Vzhledem k tomu, ze v 1:37:16 (tesne po timeoutu) dorazil dalsi tick, tak ta EA, ktera koncila v timeoutu byla stale ve funkci start(), tudiz dalsi tick "preskocila" a ke slovu se dostala druha EA (do te doby blokovana na _IsTradingAllowed - vracelo false - trading context byl obsazen). Ta jiz v "1:37:16 a kousek", resp. 1:37:17 mela volny trading context a mohla umistit objednavku s cislem ticketu 263711 a pak se prepnout do pasivniho stavu (*). Dalsi tick dorazil v 3:25:52 a ta EA, ktera puvodne skoncila na timeoutu (a tedy predpokladala, ze OrderSend selhalo, tudiz jala se znovu opakovat pozadavek) nebyla jeste v pasivnim stavu a tak umistila svoji objednavku s cislem 263989. Rano jsem dosel k terminalu a vidim, ze mam misto zadanych 2 objednavek 3 a tudiz jsem v 7:43:41 jednu z nich (nastesti jeste nebyla STOPka aktivovana) smazal.

Nejvetsi tragedie je, ze dle zurnalu byla objednavka otevrena (nevim, zda-li tato hlaska znamena taktez ACK ze serveru) okamzite "01:33:57 '61723': order was opened : #263708 buy stop 1.00 PA at 357.8000 sl: 349.5000 tp: 0.0000", ale az za 3 minuty byl uvolnen trading context s timeoutem v OrderSend().

(*) prepnuti do pasivniho stavu je trivialne reseno via statickou globalni promennou, kterou v init() nastavim na false a po korektnim provedeni objednavky nastavim na true. Pri kazdem volani start() testuji, tuto hodnotu a pokud byla jiz radna objednavka provedena, okamzite koncim zpracovani.

Nize uvadim sniplety kodu, ktery to cele pacha, snad nepotrebuje blizsi komentar (byt je pry muj programatorsky rukopis velmi hutny - to jeste nic neni (jako napr. v Jave) - prece jen MT4 byte_op prekladac ma v syntaxi rezervy:-)):

bool traded = false;

int init() {
traded = false;
return(0);
}

int start() {
// tradeOP je pouze rozhodovani mezi BUY/SELL STP a LIMIT dle aktialniho ticku BID/ASK
int tradeOP;
int ticket = -1;

if(!traded) {
if(_IsTradeAllowed(0)) {

int retry = 0;

while(retry if(_IsTradeAllowed(maxWait)) {
ticket = makeOrderSend(Symbol(), tradeOP, lots, price, slippage,
SL, TP, comment, magic, StrToTime(expiration), Blue, maxWait);

if(ticket != -1) {
traded = true;
break;
} // ticket != -1
retry++;
} // _IsTradeAllowed
RefreshRates();
} // while
} // _IsTradeAllowed
} // !traded
return(0);
}

bool _IsTradeAllowed(int maxWaitTime = 0) {
bool retVal = false;

if(!IsTradeAllowed()) {
int startTime = GetTickCount();
Print("Trade context is busy!");

while(true) {
if(IsStopped()) {
Print("EA was stopped!");
break;
} // IsStopped
if((GetTickCount() - startTime) > (maxWaitTime * 1000)) {
Print("Wait limit exceeded! Aborting...");
break;
} // GetTickCount
if(IsTradeAllowed()) {
Print("Trade context is free!");
retVal = true;
break;
} // IsTradeAllowed
Sleep(100);
} // while
} // IsTradeAllowed
else {
retVal = true;
} // else IsTradeAllowed

return(retVal);
}

int makeOrderSend(string symbol, int trade_op, double lots, double price,
int slip, double sl, double tp, string comment, int magic, datetime exp,
color clr, int maxWaitTime = 0) {

int ticket = -1;

lots = normalizeLots(symbol, lots);
price = NormalizeDouble(price, MarketInfo(symbol, MODE_DIGITS));
sl = NormalizeDouble(sl, MarketInfo(symbol, MODE_DIGITS));
tp = NormalizeDouble(tp, MarketInfo(symbol, MODE_DIGITS));

if(_IsTradeAllowed(maxWaitTime)) {
ticket = OrderSend(symbol, trade_op, lots, price, slip, sl, tp, comment, magic, exp, clr);

if(ticket == -1) {
printError("OrderSend("+symbol+","+trade_op+","+lots+","+price+","+slip+","+sl+","+tp+","
+comment+","+magic+","+TimeToStr(exp)+","+clr+")");
} // ticket
} // _IsTradeAllowed
else {
Print("makeOrderSend(...): Waiting time exceeded maxWaitTime!)");
} // else _IsTradeAllowed
return(ticket);
}

void printError(string strErr) {
Print(strErr, " returns error: ", ErrorDescription(GetLastError()));
}

// ErrorDescription je z stdlib.mqh

[PaJaSoft]

Aby to nebylo tak dlouhe, tak dalsi poznamky uvadim v prispevku rekneme "navrhy na reseni problemu" - workarounds.

V tomto konkretnim pripade nijak dale nevyuziji MagicNumber, muze se proto zneuzit na to, ze pri uplne prvnim volani OrderSend po vyvoreni instance EA si zapamatuji nahodne numero - treba hodnotu z GetTickCount() a po libovolnem selhani OrderSend (magic = GetTickCount) budu pri dalsim ticku prochazet cely seznam objednavek (v tu chvili jich muze byt par desitek, delat to v kazdem volani start() je dost procesorove narocne) a hledat objednavku s timto Magicem.

Otazka zni - jak dlouho mam hledat? Kdy mohu prohlasit, ze objednavka skutecne nebyla na serveru registrovana (10, 20, 30 minut?) a mam (mohu) tedy vytvorit dalsi? Ta "nahle nalezivsi" objednavka se (alespon jsem si toho jednou vsiml) totiz dlouho nebyla videt okne "Trade" a pod zasazenymi objednavkami, ale objevila se tam po nejakem case (asi tak 5-10 minutach).

Navic tento workaround jak uz jsem poznamenal zere desne CPU a navic problem resi dost nedokonale - v prubehu te doby muze dojit k zasazeni STOPky a pak uz to neni pending order, ktery lze menit, mazat atd., ale regulerni vstup do pozice a v spreadovych systemech automaticky ztrata minimalne o velikosti spreadu (coz u nekterych CFD je i nekolik stovek $).

Rozumne reseni z toho IMHO neni.

Stejna situace se mi stala odpoledne u IBFX dema na USDJPY - rychly pohyb v 14:00 GMT - Opet OrderSend vratilo -1 (tentokrat na vide Busy trading context), takze jsem volal opakovane OrderSend a za 2 minuty koukam jak puk, ze mam zase objednavky UPLNE jinak nez co bylo volano (a neni to bohuzel zdaleka poprve, podobna situace se stane i pro ruzne pary, pokud je rychlejsi pohyb a je volano vice OrderSend ( v ruznych EA) v ramci jedne instalace MT4)... Tady dokonce se s necim (EA je starsiho data) jako IsTradingAllowed vubec neparam, po prichodu ticku, spocitam co potrebuji a natvrdo volam OrderSend - bud se povede (a umisti objednavku za Market (last BID/ASK), ale s 0 deviaci) a dalsim tickem jsem pasivni nebo nepovede a s dalsim tickem opet vse spocitam a zavolam opet OrderSend.

Zurnal vypada nasledovne:

16:00:00 '1398535': order sell 0.01 USDJPYm opening at 118.5200 sl: 118.8700 tp: 118.3200 failed [Trade context is busy]
16:00:00 TradeDispatcher: trade context is busy
16:00:00 '1398535': order sell 0.01 USDJPYm opening at 118.5200 sl: 118.8700 tp: 118.3200 failed [Trade context is busy]
16:00:00 TradeDispatcher: trade context is busy
16:00:00 '1398535': order sell 0.01 USDJPYm opening at 118.5200 sl: 118.8700 tp: 118.3200 failed [Trade context is busy]
16:00:00 TradeDispatcher: trade context is busy
16:00:00 '1398535': order sell 0.01 USDJPYm opening at 118.5200 sl: 118.8700 tp: 118.3200 failed [Trade context is busy]
16:00:00 TradeDispatcher: trade context is busy
16:00:00 '1398535': order sell 0.01 USDJPYm opening at 118.5200 sl: 118.8700 tp: 118.3200 failed [Trade context is busy]
16:00:00 TradeDispatcher: trade context is busy
16:00:01 '1398535': instant order sell 0.10 USDJPYm at 118.5200 sl: 118.8700 tp: 118.3200
16:00:01 '1398535': request was accepted by server
16:00:01 '1398535': request in process
16:00:01 '1398535': order was opened : #30555814 sell 0.10 USDJPYm at 118.5200 sl: 118.8700 tp: 118.3200
16:00:03 Mail: 'Signal EMA Difference on EURUSDm at 2007.04.05 14:00 occured' has been sent
16:00:03 Mail: 'Signal EMA Difference on GBPUSDm at 2007.04.05 14:00 occured' has been sent
16:00:03 '1398535': instant order sell 0.01 USDJPYm at 118.5100 sl: 118.8600 tp: 118.3100
16:00:04 '1398535': request was accepted by server
16:00:04 '1398535': request in process
16:00:04 '1398535': order was opened : #30555886 sell 0.01 USDJPYm at 118.5100 sl: 118.8600 tp: 118.3100
16:01:04 '1398535': modify order #30555886 sell 0.01 USDJPYm at 118.5100 sl: 118.8600 tp: 118.3100 -> sl: 118.8600 tp: 0.0000
16:01:07 '1398535': request was accepted by server
16:01:07 '1398535': request in process
16:01:07 '1398535': order #30555886 sell 0.01 USDJPYm at 118.5100 was modified -> sl: 118.8600 tp: 0.0000
16:02:14 '1398535': close order #30555819 sell 0.10 USDJPYm at 118.5200 sl: 118.8700 tp: 118.3200 at price 118.6000
16:02:15 '1398535': request was accepted by server
16:02:15 '1398535': request in process
16:02:15 '1398535': order #30555819 sell 0.10 USDJPYm at 118.5200 sl: 118.8700 tp: 118.3200 closed at price 118.6000


Coz by bylo uplne super, kdyby vysledkem [bold]NEBYL[/bold] stav, ze v realu system eviduje objednavky 3 (!!!) s cisly 30555814, 30555886 a 30555819 (!!!), kterou v 16:02:15 rucne zaviram se ztratou 8 pips. Tato (zavirana) objednavka NENI ani v zurnalu a evidentne "nastala" (vznikla na serveru) nekdy po evidenci prvni objednavky - 30555814, protoze ma o 5 pozic vyssi seriove cislo.

Jak rikam, problemy nejsou zavisle na brokerovi, MT4 (v pripade WHC build 202, u IBFX 203 - the latest), jeho instalaci (IBFX demo je provozovano na WinXP SP2 + all WindowsUpdates; WHC mam doma na WinXP SP1 + nektere updates; ruzni ISP). Jevi se mi to jako dost zavazne Race conditions v ramci jedne instalace MT4 - verim tomu (a vse tomu nasvedcuje, vcetne jinych experimentu - sice na demu, ale "ala real"), ze pokud bych mel 2 instalace MT4 vedle sebe (jako ze jich mam jeste vic:-)) a v kazde by probehlo jedno volani OrderSend, tak v podstate zadny problem VUBEC nevznikne...

Ja se nesnazim lamat komunikacni protokol MetaTraderu, ja chci obchodovat a chci, aby obchodni platforma pouze radne registrovala me pozadavky (volani OrderSend), objednavky nemodifikovala, nevymyslela si atd... Pokud se bude stejna situace vyskytovat i na live money, tak teda se mam na co tesit. Korelaci s buildem MT4, brokerem apod. nevidim zadnou, jevi se mi to jako neprijemna vlastnost obchodni platformy jako takove...:-( (a to je teda (po)radny pruser!)

[DarkMan]

PajaSoft:
Kdysi jsem psal strategii kde bylo nutne zajistit 100% vystaveni objednavek, klasicke pyramidovani objednavek kdyby to slo nahodou proti tobe.....

Resil jsem to takto
if(IsTradeAllowed){
while(OrderSend(.....) Sleep(100);
RefreshRates();
}
}

cili pokud OrderSend selze nedopustim aby ea dojela na konec start() a stale opakuji opakuji posilani objednavky dokud mi to nevrati ticket, no a jelikoz rikas ze MT vystavi objednavku na server ale klientovy vrati -1 tak bych to zkusil nasledovne

if(IsTradeAllowed){
while(OrderSend(.....) if(iGetNumOfOrder()>0){
traded = true; //pasivita
break; //konec while
}
Sleep(100);
RefreshRates();
}
}

int iGetNumOfOrder(bool BUY=true){
//napsano jen pro long smer
int iProdano, iKoupeno;
for (int x=0;x OrderSelect(x,SELECT_BY_POS,MODE_TRADES);
if(OrderSymbol()==Symbol() && OrderCommnet()==TVUJ_Koment && OrderMagicNumber()==TVUJ_Magic){
if(OrderType()==OP_BUY || OrderType()==OP_BUYSTOP || OrderType()==OP_BUYLIMIT) iKoupeno++;
}
}

if(BUY) return(iKoupeno);
}


Cili pokud OrderSend selze checknu jestli na server neni vystavena objednavka pokud ano koncim pokud ne opakuji vystaveni.... Toto dle me musi fungovat, kdyz je to jednou registrovane na server jako vystavena objednavka tak mi pruchod vsech objednavek musi vratit ze tam je.... Sice toto reseni bude chvilkove trosku narocnejsi pro PC ale to snad zkousnes

btw: toto jsem nikdy nezaregistroval a znam dost MT programatoru co obchoduji pres EA a nevim ze by nekdo neco podobneho zjistil sam mam jeden ucet u ibfx a tam se tak nedeje a ty rikas ze jo divne :S

Mira

[PaJaSoft]

[ital]Cili pokud OrderSend selze checknu jestli na server neni vystavena objednavka pokud ano koncim pokud ne opakuji vystaveni.... Toto dle me musi fungovat, kdyz je to jednou registrovane na server jako vystavena objednavka tak mi pruchod vsech objednavek musi vratit ze tam je.... Sice toto reseni bude chvilkove trosku narocnejsi pro PC ale to snad zkousnes [/ital]

Jo toto zrejme bude jedina mozna cesta - nejlepe zkombinovana pres Magic via GetTickCount(). Jako neprijemny vedlejsi efekt je, ze behem 3 minut, nez OrderSend vrati -1 a ERR_TRADE_TIMEOUT uplynou dle empirickeho zjisteni alespon 3 minuty a pak uz bude cena zpravidla naprosto nekde jinde, ale to uz je riziko obchodovani.

Co se tyce vyskytu, ja bych rekl, ze to zacalo delat pred asi tak 2-3 mesici (tedy od nejakeho ledna, unora, ale pouze pri nekolikanasobnem volani OrderSend a vyrazne rychlych pohybech), loni se stejnymi EA jsem na nic takoveho ani jedinkrat nenarazil, docela bych si tipnul, ze to souvisi s updaty BackOffice MT4 trading platformy... zato posledni mesic je to skoro pravidlem a od doby, co umistuji objednavky na BO High/Low predchoziho dne pro pozicni obchody (cca 2 tydny zpet u WHC) je to na dennim poradku.

[PaJaSoft]

Tak nevim jak Vam, ale novy preddefinovany seznam trailing S/L mi vubec nevyhovuje. (build 203) Jaky byl duvod zmeny?

[naposledy]

Ahojtě,
Potřeboval bych poradit s částí skriptu do EA která by dělala to, že by blokovala otevření nové pozice "x" svící po uzavření předchozího obchodu. Můžete mi pls někdo poradit příp. nasměrovat na EA ze kterého by se to dalo "vykrást" :-)
Jsem programátorský poleno, ale přesto se pokouším vytvořit nějaký svůj EA a tohle by mi fakt pomohlo.