Errors, bugs, questions - page 906
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
Once you become a programmer, you need to understand that it is you who starts consuming resources with your requests. Calling expensive functions by no means means means that you can disconnect from the question of "how resources are actually handled".
The best way is to post the full code here in the forum and the problem area will be detected immediately. If you can't do it here, you can do it in service Desk (code will be deleted after checks).
ps: we never have issues when the OS gives out that there isn't enough memory and we never blame Microsoft for that.
All the same, I'll write what I abstained from before.
Yes, I'm aware that there are corporations interested in forcing product sales and increasing profits by any means necessary. There are cartel conspiracies, for example. And Microsoft, which is believed to be notorious for cyclic program bumping to slow down its long-suffering OS (which may well be true), is almost constantly in a state of collusion with hardware giants that also dream to wring their hands by hurrying to sell their expensive new hardware to Windows consumer to replace the old and perfectly usable one that has yet to live on Unix-platforms or an old Windows.
The MQ has never gave me a feeling that they want to bind me with an iron needle and leave me without underwear. Both MT4 and MT5 have always delivered decent responsiveness and usability over the years, especially when compared to those relatively new-fangled, ubiquitous, unwieldy .NET Framework applications. So there's nothing wrong with that, which is what I'd like to see in the future. It's important to have comprehensive information about new builds and accompanying information about changed minimum requirements etc., so that we know what to prepare for mentally, intellectually and financially.
And on a side note, regarding accusations from dependent developers towards primary developers: Microsoft doesn't force anyone to upgrade without alternative. You can't turn off auto-updates for some reason. So.
I will still write what I refrained from writing earlier.
You would not have spent more than 5 minutes on creating a service-desk application. And perhaps you would have received a definite answer the very next day.
But you prefer to discuss with Renat a conspiracy of Microsoft against users.
Don't tell after that that you really have a problem ;)
after a quiet update to the latest build, deleted agents started to fall off:
Someone is sending the wrong data. Before that, agents were quietly crashing (you just didn't notice it) because of division by 0. This division by zero should not exist in principle, so we didn't have a corresponding check. This someone may not be an intruder, so we are waiting for a request from him in the service desk. We have not been able to reproduce this error ourselves.
UPD
I suddenly saw the log line
This shows that your agent was indeed used as a remote agent. So you know the source of the problem. I'd like to talk to servicedesk
What is the
2012.12.19 21:33:50 Core 01 2004.04.02 20:15:00 Access violation write to 0x0000000000000009
Showed during strategy backtest.
What is the
2012.12.19 21:33:50 Core 01 2004.04.02 20:15:00 Access violation write to 0x0000000000000009
Showed during strategy backtest.
Error in sending a message to servicedesk
Renat, well, I still have problems with the 32-bit version, but for the first time I had a chance to test the code on the x64 version of MT5. And this is what I found out...
There were no those errors that the 32-bit version of the terminal produced, but there were problems with incomplete initial (i.e. before I manually switched to other timeframes) drawing of graphical layouts and occasional shifting of binding points of some objects from extrema along with shifting of graphical series of an auxiliary indicator. Until the last moment I was preparing a flaming speech for ServiceDesk, but after a dozen or so launches of the terminal (even including several complete computer reboots) everything miraculously stabilized. I don't know and can't even guess the logic of it all, but my impression is that during those dozens of restarts the terminal seemed to "speed up" and finally "adapted" to the OS and/or the indicator to the terminal. Yes, it sounds mystical, but logically it should not be so: the only "adjustment" - is the full loading of history, caching of used timeframes, fine manual tuning of terminal options and... That seems to be all. But all this was done at the first start, while the subsequent runs of the terminal did not differ from the second one in its state (last history downloading and addition of news flags to the chart are irrelevant, so we do not take them into account).
I'm still a bit confused, I guess the kinks will show themselves semi-unexpectedly and then I'll deal with them, but it's not yet soon, meanwhile - planned code optimization. If it will be interesting to test the code purely for yourself - let me know before I disappear again.
Look in the history catalogue and see hundreds of megabytes of historical data.
By "miraculously stabilised" do you mean that the whole story pumped up? So that's to be expected - history is pumped up by necessity and it can take time.
Look in the history catalogue and see hundreds of megabytes of historical data.
The opposite is true. Under the personal visual control all the history is downloaded at the first start, at the end of the download it is checked with the Home key with going to the beginning of 1994 on M1. Then I manually bypass the timeframes I frequently use, as well as those relevant to the multitemporal indicator, wait for their formation and reload the terminal. That is all.
All subsequent small downloads of new history data do not have any principal effect, i.e. theoretically, the terminal can be considered "stabilized" after the full loading of history at the end of the first run or, for reliability, at the very beginning of the second run, when it is guaranteed that non-M1 generated timeframes have settled on HDD. But this is theoretical. For some reason, everything settled down (I'm talking about the proper work of the indicator) at about the tenth restart, although, I emphasize, the main story was already loaded at the first one, and the subsequent ones should not be able to make the weather in principle... I would even say on the contrary: the bigger the story gets from run to run, the greater the risk that the indicator will fail to swallow it at some particular run and fails, but in fact it was the other way round: the further it went, the better it worked).
So perhaps there are some hidden and unobvious to the user processes of the terminal or MT5 + OS combination, which optimize the application in the operating environment not immediately, but after some n-tweaking. I do not modify my own source code for a long time, concerning its compilation - only at first launch of newly installed MT5 (which build is always the same in this study). There were no tweaks after the first run. This whole mysterious situation reminded me of the"Start" menu in Windows, where frequently called applications became available first in time (the OS collected statistics, but it took time and a certain amount of calls to the same programs). Or defragmenting disk files optimizes disk access and makes applications run faster, all of which is the same thing.
I'm not inclined to believe that you implemented something similar in MT5, otherwise you either reported it yourself, or you would have been caught asking about it on the forum long ago. So it's all just an unconfirmed hypothesis based on experience.