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
Good afternoon, the MT5 log shows this message: 2020.05.21 05:49:44.364 Virtual Hosting failed to get list of virtual hosts (www.mql5.com:443 send request failed [12002])
Can you people please tell me what it means and what to do about it?
Thank you!
My debugger refuses to work in one of my projects. Moreover, its behaviour is difficult to predict. Sometimes it just refuses to enter breakpoints. It also refuses to enter some functions. At first I thought the reason was updates (maybe something went wrong with debugging). But in other simpler programs everything seems to work. I haven't checked it much, though, because I'm working on my main project. It is quite complex and includes 15 modules only of my own design (I have not counted the number of standard modules). The main module contains up to 2000 lines. I thought maybe it's all about the complexity of the project... Also, in some places I use macros for repetitive code snippets. Also I use standard UI elements, such as CAppDialog, CCheckGroup, CComboBox, CButton etc. that I rewrote to the functionality of my program. Maybe debugging doesn't work because of them... For example, the CCheckGroup::itemCheckState(const string item) method I specifically wrote doesn't debug. The method finds item of check box and checks whether it's selected (its State):
This is what kind of UI I ended up with:
Some of the UI elements are temporarily classified. And here is a branch where I described how I overrode Show() and Hide() methods of CAppDialog element:https://www.mql5.com/ru/forum/338301 The compiler complained at that moment and a critical error occurred.
In the end the project compiles normally, the compiler doesn't generate any errors. But debugging fails and just doesn't show execution of some code fragments, functions, methods and so on.
As far as I understand, there may be several reasons for that.
Build and system info:
https://www.mql5.com/ru/forum/1111/page2746#comment_16481481
In CCheckGroup::itemCheckState method (into which the debugger can't get) I put something like this:
And got the following message:
2020.05.21 13:20:44.229 CCheckGroup::itemCheckState item: 39 state: 32
https://www.mql5.com/ru/forum/1111/page2746#comment_16481481
Without the debugger working properly, the project may be delayed for a long time. I would like the Developers to pay attention to this bug most likely related to the debugger.
It's a lot of text, I haven't read all of it.
But if something works in debug version and doesn't work in release, or vice versa, check if all variables and fields, especially in class/structure, were initialized.
#define GETCURRENTTICK GetCurrentTick1(Tick)#define GETCURRENTTICK GetCurrentTick2(Tick, !i)#define GETCURRENTTICK GetCurrentTick3(Tick)On the subject of SymbolInfo functions being free.
perhaps the method is inline, then it's not the debugger's problem, but the debug compiler's
Exactly, the project turned out to be overflowing with macros, both mine and those from standard modules. Maybe that's why the debugger doesn't always manage to match commands in *.ex5 debug file with lines in *.mq5 source file and other modules...
The SymbolInfo functions are free.
so it's the cost of the function itself, not the cost of passing the string by value, not by reference!
Your version with the cache is quite a solution, if the execution of this function takes a significant percentage of the time of execution of the EA (which I don't really believe)
Exactly, the project turned out to be overflowing with macros, both mine and those from standard modules. Maybe that's why the debugger doesn't always manage to match commands in *.ex5 debug file with lines in *.mq5 source file and other modules...
is the cost of the function itself, not the cost of passing the string by value, not by reference!
That's what I was initially led to.
Forum on trading, automated trading systems and strategy testing
Errors, bugs, questions
fxsaber, 2020.05.20 13:24
It's better to have
In the optimizer these functions are called tens of billions of times.
Moreover, your variant with the cache is quite a solution, if the execution of this function takes a significant percentage of the runtime of an EA (which I don't really believe)
At a certain stage, not only the relative part of time taken becomes important, but the absolute part as well.