Help for developers. - page 12
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
2. history by cup is, in my view, an unthinkable thing. I may be wrong, but the amount of memory required to record changes of all values in the beaker (which occur in milliseconds) is excessive. It is possible to record data over a small period of time by making a circular buffer inside and analyse the signatures of value changes. It is also possible to visualise the data in the form of curves on a graph, but only for a short period. This is not an easy task.
If you mean something else, please explain.
4. See point 2. Too much space is required. The file will grow by leaps and bounds. Reading it will slow down the entire program. Only a circular buffer with a small current period.
5. Visualization of data inside the EA or indicator is possible after building the above buffer.
2. No need to think - just write it down.
For example, 4 bytes time 4 bytes price 4 bytes value, depth 10(20), 10 times per second new data - 200mb day, 1gb week, 1tb disk 1000 weeks - 20 years (2 years with update 100 times per second), acceptable values for today. (about ring-buffer nonsense - "ring-buffer" as a theme promoting mql programming or an example for a computer science subject has a place (based on articles here), as a solution - very controversial)
4. "Record history" is not a single file, for example result files by an hour, and temporary files drop by a minute.
5. You do not need to build any buffers, you must 1) correctly for the file operations to record the history, 2) visualize 1-n bar (a minute) 3) visualize the history.
In other words, you have to take ready-made solutions, cut, add, modify and build them. Since the glass has appeared, and you have already done this (glass), you can use your hands, especially the hands of a professional.
1. input in English. "input".
"trail" is an abbreviation of the word "trailing" - that is, a trailing stop.
"hedge" means hedging. Read more about this concept in trading literature. 2.
2) TakeProfit Grade I explained above. Literally - "Takeprofit grid". I don't know exactly what it means. (see above).
Takeprofit hedge is the takeprofit of a hedging position.
3. "Close at stop" is a close at stop. "Closer" is simply a close-out.
2. You don't have to think - you just have to write it down.
For example, 4 bytes time 4 bytes price 4 bytes value, depth 10(20), 10 times per second new data - 200mb day, 1gb week, 1tb disk 1000 weeks - 20 years (2 years if updated 100 times per second), acceptable values for today. (about ring-buffer nonsense - "ring-buffer" as a theme promoting mql programming or an example for a computer science subject has a place (based on articles here), as a solution - very controversial)
4. "Record history" is not a single file, for example result files by an hour, and temporary files drop by a minute.
5. You do not need to build any buffers, you must 1) correctly for the file operations to record the history, 2) visualize 1-n bar (a minute) 3) visualize the history.
In other words, you have to take ready-made solutions, cut, add, modify and build them. If the glass is ready and you have already used it (the glass), you may use it, especially if you are a professional.
You know better than me what needs to be done. Do it. I only give my opinion and, if I can, help you find a solution.
For example, 4 bytes time 4 bytes price 4 bytes value, depth 10(20), 10 times per second new data - 200mb day, 1gb week, 1tb disk 1000 weeks - 20 years (2 years when updating 100 times per second), acceptable values for today.
"Recording history" is not a single file, e.g. result files for an hour, and temporary files for a minute.
Petr Doroshenko:
4. "Record history" is not a single file, e.g. result files by the hour, and temporary files drop by the minute.
5. You don't need to build any buffers, you need to 1) record history correctly by file operations, 2) visualize 1-n bar(minute) 3) visualize history.
In other words, you have to take ready-made solutions, cut, add, modify and build them. If the glass is there, and you already took care of it (the glass), the more so, it will be done by a professional.
1. What do you mean by"record history correctly by file operations"? Write a functionality that writes the glass history to a file?
2. What do you mean " visualize a 1-minute bar "? How do you visualize?
3. what do you mean by "visualize history"? To visualize the history of changes in the values of the Limit values in the cup by reading it from a file? In what form should we visualize it?
4. The method"take ready-made solutions, cut, add, change and sculpt" is never used. Nothing of any quality comes out of it.
My tumblr used "live" rather than recorded data, which it got from another platform. It didn't visualise or record anything.
Petr Doroshenko:
(about ring-buffer nonsense - "ring-buffer" as a topic popularizing mql programming or example for computer science subject has a place (based on articles here), as a solution - very controversial)
Believe me, in your case, a ring buffer is much easier to build and much more convenient to use for visualization.
Believe me, in your case, a ring buffer is much easier to build and much more convenient to use for visualisation.
1. What do you mean by"record history correctly by file operations"? Write a functionality to write the cup history to a file?
2. What does it mean " visualize 1-n bar(minute) "? How to visualize?
3. what do you mean by history visualization? Visualize the history of changes in the values of limits in the cup by reading it from a file? In what form should we visualize it?
4. The method"take ready-made solutions, cut, add, change and sculpt" is never used. Nothing of any quality comes out of it.
My tumblr used "live" rather than recorded data, which it got from another platform. It didn't visualise or record anything.
1. For example, snapshots go 4 times per second, take 10 times per second - 10 times per second pulling file operations is not quite right. Ok, let's call writing data to a file once per minute a function. Closest analogue is standard periodic converter and various implementations of Renka. You can write a screencast in a separate screen.
2. For example, you can read it in slow motion, or display all the snapshots in a minute, or draw it online immediately by the last bar as in basement rens.
3. You've already drawn something - any way you like. - This is not the first task, but the very last one, where for example to look at a pointer is a nice rather than a necessary feature.
4. Re-write Windows, following your logic, you should be able to do better.
If you need to visualize changes in a cup in 1 minute bar, you don't have to make such a complex plot with a gigantic file system and use gigabytes of memory. Make a ring buffer with current period of a minute and visualize data on the fly, without reference to the file. You won't be able to analyze data over a longer period of time anyway. It will be infinite curves in which you won't find any meaning. (imho).
Once again, the"ring buffer" topic covered here in articles and what one can want from it is practically of no interest (except for implementations of oppa), because copying an array back and forth to/from a temporary array with one element offset solves most (maybe even all) of the application tasks that the "ring buffer" topic entails. If anyone likes another ..... way, please do.
Under certain conditions a price chart makes no sense. For 10 years a stack with at least some volumes in mt4 didn't make sense, but it appeared with a dll application, a stack with volumes only in mt5 on the exchange.
In fact you need a few single minute bars in 10-12 hours . Obviously to look at these minute bars at the end of the day you need to record all the bars for the day. Obviously, in order to view a few bars at the end of the week, you need to record all the bars (daily intervals) for the week and at the end of the month you need to record all the bars for the month. Obviously, megabytes of data for further analysis should be stored on a non-volatile memory - in most cases this is a hard disk. Gigabytes of hard disk are not a sign of gigantism.
1. For example, snapshots go 4 times per second, take 10 times per second - 10 times per second pulling file operations is not quite right. Ok, let's call writing data to a file once a minute functional. Closest analogue is standard periodic converter and various implementations of Renka. You can write a screencast in a separate screen.
2. For example, you can read it in slow motion, or display all the snapshots in a minute, or draw it online immediately by the last bar as in basement rens.
3. You've already drawn something - any way you like. - This is not the first task, but the very last one, where for example to look at a pointer is a nice rather than a necessary feature.
4. Re-write Windows, following your logic, you should get a better quality.
Once again, the article about "ring buffer" and what you can expect from it is practically of no interest (except for implementations of oppa), because copying an array back and forth to/from a temporary array with one element offset solves most (maybe even all) of the application tasks assigned to the "ring buffer". If anyone likes another ..... way, please do.
Under certain conditions a price chart makes no sense. For 10 years a stack with at least some volumes in mt4 didn't make sense, but it appeared with a dll application, a stack with volumes only in mt5 on the exchange.
In fact you need a few single minute bars in 10-12 hours . Obviously to look at these minute bars at the end of the day you need to record all the bars for the day. Obviously, in order to view a few bars at the end of the week, you need to record all the bars (daily intervals) for the week and at the end of the month you need to record all the bars for the month. Obviously, megabytes of data for further analysis should be stored on a non-volatile memory - in most cases this is a hard disk. Gigabytes of hard disk have long been no sign of gigantism.
If you talk about writing a function that writes the data first in an array, and then dumping them into a file, then here you will not be difficult. On the visualization will have to work hard.
Implementation plan:
1. We need to write a function for writing the cup's data into the array.
2. Write function creating new file once in a minute, automatically name it and write data from array.
3. write functionality visualizing cup data from selected file.
The first two tasks are not difficult. The third is something to think about...
Petr Doroshenko:
In fact a few single minute bars per 10-12 hours are needed . Obviously, to look at these minute bars at the end of the day, it is necessary to record all the bars for the day.
Based on the current understanding of your task, I can suggest two options for visualising historical tumbler data:
1. A curved line of change in values of each cell of the tumbler per minute drawn using the CGrafic library. 20 cells is twenty lines. Draw the lines in different colours. Perhaps the curves can be drawn through an indicator, but I have no experience with indicators.
2. The best solution is to draw a custom glass and write a function that "rewinds" the data recorded in the file through its cells. The rewind speed should be adjustable by the user.
It is possible to combine both options. Make a tumbler with advanced capabilities, capable of loading the minute history from a file and rewind it at a desired speed. In parallel, the curves of change of values in the cells would be drawn in a separate window.
Based on the current understanding of your task, I can suggest two options for visualising historical tumbler data:
1. A curved line of change in values of each cell of the tumbler per minute drawn using the CGrafic library. 20 cells is twenty lines. Draw the lines in different colours. Perhaps the curves can be drawn through an indicator, but I have no experience with indicators.
2. The best solution is to draw a custom glass and write a function that "rewinds" the data recorded in the file through its cells. The rewind speed should be controlled by the user.
It is possible to combine both options. To make a tumbler with advanced capabilities capable to load the minute history from a file and rewind it at a desired speed. In parallel, a separate window would draw curves of changes in the cells.