
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 sent the logs the day before yesterday. I'll get back to you... somehow I missed it... because you wrote that you reproduced the error.
The logs are in, thank you. We looked at them. And the question wasn't about the logs, it was about the file.
They did reproduce the error, but not immediately. Apparently they didn't fix everything - you have to reproduce it further, but it's not reproducing.
The question is not about the logs, it's about the file.
The error was indeed reproduced, but not immediately. Apparently, they didn't fix everything - you have to keep reproducing, but it's not reproducing.
replied
I had a quick update to 567 and didn't notice any problems. Flight's fine. :)
tol64:
Have you got everything in place so far? )))
So far so good too, I just want to make sure it's a native build and not a foundling. )))
joo: Всё на месте.
alexvd: Don't worry, the build is native. You can check the file signatures.For the list of timeframes, to get their names, there is EnumToString() - it returns the name of timeframe as a string. Is it possible to get as a string the names of built-in object visibility constants of OBJ_PERIOD_M5 type?
No, this is actually a macro (#define), no such functionality is planned for macros.
Is there any relationship between the list structure of timeframes and object visibility flags (because even the length of lists is different: 22 vs 23)? In general, I'm asking in order to efficiently and compactly assign visibility of objects on timeframes in a cycle with given boundaries, rather than to list and summarize flags manually. What logic to use if an arbitrary timeframe is taken at random, a graphical object is built on it and it needs to be allowed to be visible on all timeframes not older than the current one (i.e. the one it was built on)? The algorithm should be universal, not for one particular case. The index correlation is already screwed, there is not even an index match. Parsing strings of names and comparing is again a failure because of impossibility to handle string in case of visibility constants. So far, a complicated, vague and very crooked implementation comes to mind.