Errors, bugs, questions - page 2450
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
However, we will check it out, of course. So, I'm not sure if you're still developing this project.
The development of this project still has a huge potential, especially in terms of improvement of the language using your own resources, because many things in MQL have not been implemented yet and many things work badly (bugs) and the developers, as I understand it, have no plans to improve anything in the language itself.
To process macros I have to implement additional layer somewhere near the beginning of the whole chain - describe macros grammar, parse them in source andinterpret (get result source/value for each macro). This is complicated, and the application is only required for some MQL programmers, so there is no development.
As for using hash to identify changes in products, I don't think this is a solution (or I have no idea what use-case we're talking about). Usually you need a year or two after generation of some ex-file to understand what version a particular embedded module was and its source. To do this you probably need to link the build process with version control systems. Hashing is not an option.
Help me out with OnTradeTransaction(). Is the behaviour described below normal? I checked it in the tester - it is so :( And on a "live" account?
OnTick() has a loop that closes positions in order.
The OnTradeTrancaction() calculates the number of open positions.
The Expert Advisor does it this way: it closes the loop to the end first, then it goes to OnTradeTransaction and performs calculations in the same order.
In other words, it doesn't
а
i.e. it works sequentially instead of in parallel.
If the above described is normal, it turns out that OnTradeTransaction() can be safely used only in Expert Advisors that open/close only one order. If there is a grid or a multisymbol grid (or a multisymbol grid, which is where it is found :) ) - the algorithm breaks down.
Quote from documentation
One trade request sent manually from the terminal or via the OrderSend()/OrderSendAsync() functions can generate several consecutive trade transactions on the trade server. Moreover, the order of arrival of these transactions to the terminal isnot guaranteed, so we cannot build our trading algorithm on waiting for the arrival of one trade transaction after another.
Consequently, everything will be calculated, but not in the sequence expected.
Can you explain why you decided to count the number of positions in OnTradeTrancaction()? If the calculation is not organized correctly, then we cannot rule out that there will be unnecessary operations. After all, if you close several positions in the loop, there is no need to recalculate all of them after closing each position. It is enough to count them once after the loop is finished. Or, arrange in OnTradeTrancaction() in such a way that the quantity increases by 1 when the IN type is set, and decreases when the OUT type is set. And even in this case, if the position is not closed completely, it must be taken into account.
Can you explain why you decided to count the number of positions in OnTradeTrancaction()?
If you count on every tick - it is resource-intensive, especially noticeable in the strategy tester. Wouldn't it be more correct to count only at the Trade event, i.e. when something in the list of open positions actually changes? With OnTradeTransaction(), it is easier to control user intervention in the EA. (There are some precedents :)
In this robot I was testing the possibility to close the grid by the scheme: Loss + profit > X , then close both of them (usually on different symbols). But a failure occurs, because even though they are closed, the tester is not aware of it, and proceeds to the next iteration, mistakenly "pairing" the existing ones with those already closed. I.e. I had to add a recalculation after each closure.
I have recalculation with a reset counter and over all open ones first, not +1 / -1
Quote from documentation
I agree, it was too risky to use OnTradeTransaction() initially. Actually, I'd probably refuse it in cases where requests are not asynchronous - only problems from it.
For a multisymbol grid, asynchrony is good. That's why I would choose the second option.
Already thinking in that direction ;)
***
In this robot I tested the possibility of closing grids according to the scheme: loss + profit > X , then close both (usually on different symbols).
***
If you know that you want to close exactly these two positions, it is better to memorize the tickets to these positions, and close them until you close them (ATTENTION: no while and Sleep - give orders to close, exit OnTick, check if there are more positions with these tickets - if so, try to close them again and exit OnTick).
If you know that you need to close exactly these two positions, it is better to remember these positions' tickers and close them until you close them (NOTE: no while and Sleep - give orders to close, exit OnTick, check if there are more positions with these tickers - if there are, then try to close again and exit OnTick).
This is a valuable idea. Maybe the OnTick() forms an array with the ticket and tries to close it once, and OnTimer() checks if there are more of them and closes, if there are.
There may be several minutes between ticks, so let's pass the task to the timerValuable idea. Maybe so?: OnTick() generates an array with tickets and tries to close once, while OnTimer() checks if they are still present and closes if they are.
Between ticks there may be several minutes, so let's pass the task to a timerI would abandon ALL while, Sleep and OnTimer for the task of closing positions. I would do the following: fire orders to close - exit OnTick, on the next tick I would check if the positions with needed tickets are still alive - again fire orders to close, and so on through the loop via entry/exit to OnTick.
The logic is as follows: closing of a position is the first priority, so the closing loop is at the very beginning of OnTick. And the formation of a close ticket array can be located anywhere onTick - even at the very end.
***
There may be several minutes between ticks, so let's pass the task to the timerSo, there is nothing we can do - we just have to wait for a new tick.
OnTick() generates an array with tickets and tries to close them once, and OnTimer() checks if they are still present and closes if they are.
Another option (for the real world - this is the best) is to run the EA in a virtual environment (there is a perfect execution), and in the real world only synchronization with the virtual one.
So there's nothing you can do - just wait for the next tick.
If, for example, there is a network failure, then waiting for the next tick is a missed opportunity to close.
If, for example, there is a network failure, then waiting for the next tick is missing an opportunity to close.
Network failure == disconnection? If there is no internet, then nothing can be closed or opened - what kind of missed opportunity is that?
In general, if the trading system is very sensitive to every sneeze (a connection failure or something) - then screw such a trading system.