Wishes for MQL5 - page 28
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
maybe this has already been said....
1) add the ability to compile when encrypted and with the ability to generate a serial number linked to a computer ID (analogous to armandillo packer),
all this should be done internally within translator and not from source
2) Add possibility of interactive work with external programs what would allow to manage terminal from other programs, connect/disconnect to server, check connection to server, ask for quotes archive, place order... etc.
3) possibility to place orders regardless of incoming ticks
4) Support of simultaneous work with several DTs/accounts
5) Revive the DLL debugging
6) At least add support for structures, in general it would be desirable to widen possibilities, so that they become more similar to c++
You need to add an executable link to the help that the program provides (for example, to open a window with the desired text) and to the web page.
If the user does something incomprehensible, the program tells him: here's a consultation on the situation, read it properly and don't do anything stupid again.
SK,
For example, you should set TP=2 and SL=10 once and then only buy or sell, i.e. pipsing will be very convenient. Because of this inconvenience, I have recently made an Expert Advisor especially to set TP and SL with the specified values after I click Buy or Sell.
So many wishes for everything! 28 pages already!
I would like to hear from the developers which wishes are already in development, which will never be implemented and which may be.
Otherwise it is not clear whether we should wish for something else, we do not see any feedback.
Of course, we also want to know the timing. I understand that predicting terms of software launch is sometimes no easier than predicting the movement of currency rates.
At least in this form: "The beta-version of MT5 will be released not earlier than at .............". Is it possible to write such a phrase?
Otherwise, it is unclear whether there is anything else to be wished for, no feedback is visible.
Has there been any talk about reassigning Magic in an active order? The idea is simple: in multi-period trading, it would be possible to pass the order to a higher timeframe when there is a long trend.
Has there been any talk about reassigning Magic in an active order? The idea is simple: in multi-period trading it will be possible to pass the order to a higher timeframe when there is a long trend.
In brief: I use the same trading strategy for 4 periods, i.e. entry/exit/trailing principles using one algorithm (a set of indicators and types of signals), but parameters of indicators are different for each period (actually they are 4 EAs on one chart), division by Magic. The result is as follows: at lower timeframes there are all indications to close positions much earlier than the market situation really deserves (i.e. any swing to the wrong side results in taking a profit), though at higher timeframes the situation is very stable. It affects the relative volatility on the indicators. I think the idea is clear - if stable situations occur on senior timeframes, open positions on junior ones should not be closed, but by changing Magic they should be passed on to the logic of senior timeframes. The application is actually used not only for timeframes, but for transferring to other processing logic. It seems to me that there won't be any problems for the brokerage company, because the ticket remains, and the profit can be found.
In brief: I use a single trading strategy for 4 periods, i.e. entry/exit/trailing principles using the same algorithm (a set of indicators and types of signals), but parameters of indicators are different for each period (actually they are 4 Expert Advisors on one chart), division by Magic. The result is as follows: at lower timeframes there are all indications to close positions much earlier than the market situation really deserves (i.e. any swing to the wrong side results in taking a profit), though at higher timeframes the situation is very stable. Affects the relative volatility on the indicators. I think the idea is clear - if stable situations occur on senior timeframes, open positions on junior ones should not be closed, but by changing Magic they should be passed on to the logic of senior timeframes. The application is actually used not only for timeframes, but for transferring to other processing logic. It seems to me that there won't be a problem for DC, because the ticket stays, and we may get some profit.
The meaning is clear.
But I don't think there is any need to change the language and the technology of communication between the terminal and the server for the sake of this idea. After all, everything you need can be accounted for in the program on the terminal side. Moreover, the very idea of changing the majic eloquently demonstrates the underdevelopment of the strategy, its criteria. Magic (as your example clearly shows) does not and cannot bear a fixed criterion to close or open an order. Simply because a majik is not related to the market in any way.
In my opinion, this is one of the key points in trading. We just happened to have a magik in our hands, and we tied to it. In fact, we should consider the situation on every new tick as a new one without any pre-history (history of events on the game account, including time and price of opening market orders).
And magic is, although partly useful, but in my opinion, not a very convenient mechanism to keep track of... who knows what. I believe that if an order could be uniquely identified (on reopening and partial closing), the magic mark would become meaningless at all.
The point is clear.....
I'll try to make some arguments, I'll start from the end...
In my opinion, if we accept the order as an object, then the magic at the moment is a fully variable property of this object from the point of view of programming, as well as the SL or TP levels. I may be wrong but at present it is impossible to clearly identify an order in MQL in relation to a code executed in the terminal at all possible stages of its life (during reopening and partial closing) and the magic to a great extent compensates for this situation. Magic should not be attached to the market - it simply has another application and has no sense except for its meaning.
I do not agree with you in your position on viewing the market situation as a historyless one... But this is my own opinion. If the order is profitable we should look at the higher timeframe to make a decision and either wait for a small pullback and continue working with the order at a higher timeframe or just close it as it will not pay off.
I'm not going to argue about the soundness and poorness of the strategy - I totally agree... But I am working on it :-)
Change the language and protocol of exchange between the server and the terminal, well, I don't know ... At the moment the majic value is already there and is accepted by the server when placing an order. I don't know about the format of the exchange protocol, but I suspect that it is batch transmission of some data structure via transport with subsequent consistency verification. I think it's not too difficult to add one more optional parameter to data structure transmitted by OrderModify. I deeply doubt, that developers took a path of atomic exchange protocol and thus bogged themselves in heavy process of versioning support.
But in general I just asked about plans :-) No so no.