Servicedesk. Complaints, suggestions.
It was said "let's take this discussion to the forum".
What are you going to discuss on the forum, my boorishness or the problem of memory cleaning?
You were told "let's bring this discussion to the forum".
What are you going to discuss on the forum, my rudeness or the memory cleaning problem?
So I put the discussion on the forum. Let's make it compatible.
On the subject of rudeness. It's not always nice to talk to Searcydesk. Arguments above.
About the function. I have given evidence that the function is not working correctly. You offered me "crutches". If you can't work correctly except without crutches, add a description of these crutches to the documentation so that no questions arise in the future.
I ask programmers to share their opinions. Are you satisfied with the behavior of the SeriesInfoInteger() function? Are you satisfied with the language documentation?
I raised the problem with the data in the indicators a long time ago!
https://www.mql5.com/ru/forum/42180
I have been assured that the problem has been solved.
They even wrote about it in the abstract of release 1200
17:Terminal: Fixed an error that led to unloading of historical data as unused, despite regular data accesses from MQL5 programs.
So the problem has not been solved?
- www.mql5.com
I raised the problem with the data in the indicators a long time ago!
https://www.mql5.com/ru/forum/42180
I have been assured that the problem has been solved.
They even wrote about it in the abstract of release 1200
Terminal: Fixed an error, which led to unloading of historical data as unused, despite regular data accesses from MQL5 programs.
So the problem wasn't solved?
I meant MT4 in this case. But for MT5 the issue is also relevant.
I haven't upgraded to 1200 yet, can't check if it's fixed yet.
But there was such a bug in MT5
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Good afternoon. Today once again I encountered the fact that Service Desk is not always willing not only to hear about the problem, but doesn't even want to listen to it. Let's begin.
A few days ago I wrote another request to servicedesk. The gist of the request is the following (for MT4):
Индикатор находится на ТФ, старше М1. Пытаюсь получить данные через функцию SeriesInfoInteger() с ТФ М1. Функция возвращает нули для свойств SERIES_BARS_COUNT, SERIES_FIRSTDATE, SERIES_SERVER_FIRSTDATE после того, как на М1 образовался новый бар. До того, как образовался новый бар - данные возвращаются корректные. После - нули.
The second problem, of a similar type. The indicator is on TF MN1. I am trying to receive data via the function SeriesInfoInteger() from the TF M5. For some time the function returns correct values, and then it just stops doing that and starts returning zeros, although NO NEW BAR HAS BEEN OPENED ON M5!
In both cases, after returning to the TF from which I am trying to get data and switching back to a higher TF, the data are correct for a while, but then - zeros.
The indicator is in the application.
I need the above properties of the SeriesInfoInteger() function to check/load the available history for the TF other than that of the indicator.
None of the programmers will like the ambiguity of the following type: at first there is data, then there is no data and it can't be obtained. Moreover, the user(s), for whom the program is written, will not like it. You can see from the message that I've provided the program to test this error. Further even a log has been provided:
The data is simply dropped and can only be retrieved further by changing the TF to the one for which the data request is made.
And this is the response I get from the SR.
Status:OpenClosed
You can see from the message that Service Desk (or some of their employees) don't care at all what users write about errors. I am prompted to access the data more frequently than once every 10 seconds!? The log shows that the data is requested much more often, on every tick. I'm sure this log has not even been read. But I have been suggested to access them "more often" or to access the data from the EA. Genius. Oh, and the application was immediately closed, like I got help.
Moving on. Here's my response:
Have you identified the error?
And Service Desk answer:
Open the required chart, then its data will always be in memory until you close it
Since build 900 we have implemented aggressive memory freeing. If there is a memory issue, everything that can be freed is freed.
I need these properties in order to select the appropriate smallest TF that has enough data. I, on the other hand, am offered to open every chart. And it doesn't matter how many instruments I analyze at the same time, open all possible charts and you will be happy.
About aggressive release and memory problems. The terminal does not have memory problems. There are no errors in the terminal logs. From this we may judge that I was just informed about a situation when memory might be freed. But it's obviously not my case. Another fact is that Service Desk doesn't want to look into the problem and just wants to get rid of it.
Next.
Don't you think it's better to refine the aggressive memory release rather than flesh out the graphs? And what memory problems are you talking about? And yes, please release, but make it possible to retrieve them further without crutches!
Have you tried to run the indicator from the application? Do you understand that the data comes from someone else's TF, comes, comes, and bam - just stop doing it!? Is this normal behaviour?
Here's a snippet from the documentation:
For Expert Advisors and custom indicators, it's better to use the event-based processing model. If onTick() or OnCalculate() events do not get all the necessary data, you should exit the event handler, expecting that the data will be available the next time the handler is called.
The indicator I cited uses exactly this model. If no data is received, data is expected to arrive on the next tick. But the data doesn't come anymore! Not at all! This is a documentation contradiction!
In mql5 everything works as it should be, why cannot be organized in mql4 in the same way?
And the answer:
No. It doesn't.
Regarding the documentation - here is a straightforward conclusion: if you constantly need data of some symbol-period, then ensure constant presence of this data in OnInit. For example with simple iTime(needed_symbol,needed_period) query. And keep this iTime on every tick.
You are burdening your terminal with memory yourself. So reduce the number of bars on the chart to the necessary limit. To back up critical data, open the chart with the right symbol-period.
If you are not satisfied with the current state of things, let's discuss it on the forum. It is useless to discuss it here.
The MT5 has a completely different model of using historical data
In order:
No. It doesn't seem to be.
Just boorish. No explanation, no comment.
Regarding the documentation - the conclusion here is straightforward: if you need some symbol-period data all the time, then make sure that this data is always present in OnInit. For example with simple iTime(needed_symbol,needed_period) query. And keep iTime on every tick.
First common sense crutch . Straightforward inference!? Where is this conclusion!? Do you really think that everyone who writes in mql has drawn this conclusion for himself!? Do not speculate for people. Conclusions are drawn from what is written. For comparison. In documentation to mql5, in section "Organization of access to data" there is an example of how the access to data must be organized. Everything works perfectly. Here you must guess that if the SeriesInfoInteger() function returns 0, you must call the iTime() function for the needed symbol/period. Why is it not written about it? Why cannot we simply improve the SeriesInfoInteger() function without these crutches? Or at least clarify it in the documentation? Dear developers, if you want to have fewer questions, write in documentation once in detail how and what. People can read!
You are burdening your terminal with memory yourself.
I wonder what you wanted to tell me! The terminal can consume memory, but to overload the terminal with memory is something new to me.
So reduce the number of bars on the chart to the necessary limit. To back up critical data, open the chart with the right symbol-period.
How many bars do you think I was testing the indicator in the application? You don't seem to care, because you didn't even ask. It's a number of 5000. It's the minimum possible. And again the suggestion to open the chart. I got it, thank you. Add this to the documentation (if necessary).
And final.
If you are unhappy with the current state of affairs, let's take this discussion to the forum. It is useless to discuss it here.
MT5 has a completely different model of using historical data
Yes, I am not happy with the current state of affairs. Users find errors (I still consider behavior of the SeriesInfoInteger() function an error) in your program. They do it for free. And it's not that you don't want to fix them, you even don't want to listen to them and look at the data given by users. And it's not the first time, when facts are accepted with a vengeance, and you don't care about errors. I hope the developers will listen and there will be positive changes in the future. Your current attitude will depopularize the attitude towards you and your product.
Thank you all for reading.
If anyone would like to test this feature, the indicator is in the appendix.