Errors, bugs, questions - page 223
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
I agree, but you need to somehow disable the automatic update so that the terminal doesn't update all the time
This is exactly what MQ won't do, I propose that the automatic update is automatically delayed until the next (after the one that was rolled back) build. And keep the last "good" build in the backup, and skip the one that was rolled back.
Improve the auto-update system a bit and everyone will be happy.
This is exactly what MQ won't do, I propose that the automatic update is automatically delayed until the next (after the one that was rolled back) build. And keep the last "good" build in a backup, and skip the one that was rolled back.
Improve the auto-update system a bit and everyone will be happy.
Updates are done not only because the build is improving but also because old bugs are being fixed.
You propose a new build with bugs to roll back to an old one with more bugs?
PS If MQ will accept the rollback system (which I seriously doubt), then at least the division of builds into improved (introducing new functionality) and patched (catching bugs) should be done. Then, and only then, will it be possible to roll back the unfinished bug to the last fixed bug.
Updates are done not only because the build is being improved but also because old bugs are being fixed.
Are you suggesting that a new build which has bugs should be rolled back to an old one which has even more bugs?
PS If MQ will accept the rollback system (which I highly doubt), at least the builds should be divided into finalized (introducing new functionality) and released (catching bugs). Then, and only then, will it be possible to roll back the unfinished bug to the last fixed bug.
Urain:
Are you suggesting to roll back the new build with errors to the old one with even more errors?
No :) I propose a different scenario (for me it is relevant at least 2nd time, as I'm doing MQ5).
I propose to roll back the build 362, which has several important features not working, to the previous one, which may have had minor minor bugs, but MY Expert worked. Roll back until the next build where these fatal bugs are already fixed.
I emphasize that the rollback is my personal decision. Not everyone is affected by this error (not everyone uses these functions, not everyone uses MQ5, etc.)
Regarding the separation of builds - no need to complicate it. The build in MY personal backup will always lie the previous one, skipping the ones I rolled back from. The logic is simple and uncomplicated. And no one but the user will have to decide which builds are good.
IMHO the main reason why MQ didn't want previous builds available is to drop users out of the beta testers circle. In the case of rollback only until the next build is available, it won't be relevant. And the complication of implementation here is negligible.
Otherwise, development work for developers (i.e. for us who are affected by these fatal bugs) will slow down for several days (while 6 days have passed since build 362 was released). Although, for simplicity, we can be bored with it.MT4 has a panel...
Control of trade operations from the keyboard... but only if ForegroundWindow is ::MetaTrader and the chart with the bot is the first in z-order...
on MT5 - only processing
[CODE]
void OnChartEvent(const int id, // Event ID
const long& lparam, // Parameter of type long event
const double& dparam, // Parameter of type double event
const string& sparam // Parameter of type string events
){
if(lparam=='A')OpenOrder(0,MB,1);//fill the trade form
...
if(lparam=='X')CloseOrder(;)
}
[/CODE]
When TradeIsDisabled signal appears in MT4, Five starts filling a trade form (the one by F9)... in the ACTIVE Editor of MT5(!?!)... MT5 - build 3-62... Before that, it was fine... 2-29 MT4...
How come?
when explicitly converting data of type double to datetime, is there a loss of precision?
Time_Max_Candle[CandleNumber]=(double)TimeCurrent();
ObjectCreate(0, "Line_Trend_Down_"OBJ_TRENDBYANGLE,0,Time_Red_0,Red_Line_0,(datetime)Time_Max_Candle[CandleNumber],Green_Line);
when explicitly converting data of type double to datetime, is there a loss of precision?
Time_Max_Candle[CandleNumber]=(double)TimeCurrent();
ObjectCreate(0, "Line_Trend_Down_"OBJ_TRENDBYANGLE,0,Time_Red_0,Red_Line_0,(datetime)Time_Max_Candle[CandleNumber],Green_Line);
Good afternoon everyone!
MQL5 experts, could you please advise how to pass an array of pointers into a function?
For example, array gSymbols:CSymbolInfo *gSymbols[] .
1. Let MT5 try to connect to agents once every 10 minutes in infinite number of times. Then we get 6 attempts per hour (evenly spaced in time).
2. In MT5, in sector Agents (where folders Local, Remote, Package are located) add an option of creating your own folders for making the lists of remote agents. It is already becoming inconvenient to manage so many agents in one folder.
3. In connection with bug (sometimes some agents give processing results with 0 trades, maybe something else will pop up), add a check after some number of passes, let's say 100, on correctness of agent's result (can be with some margin of error, let's say 5%) with local agent. If agent gives wrong result, have MT5 perform remote restart and erase all previous results from this agent, and after 10 unsuccessful restarts (i.e. wrong results will still happen), disconnect from it.
I posted the pictures in Testing on remote agents in MetaTrader 5
seen - read - thought - done - done - made a fool of yourself... //underline...
welcome...