My approach. The core is the engine. - page 122
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 will.
It'll be ready the day after tomorrow.
That's great. I'll be waiting.
I read and read this topic... I wondered where Peter's target audience was. Who will he sell his GUI to? The question is not idle ...
I just realized - those who manually trade by the methods of Gann. That's where precision in geometric proportions and beauty is really needed.
So, buyers are likely to be found - but, Gann's methods are not so simple that they can be graphically displayed so easily :))
Great. I'll be waiting.
I got held up. Today - tomorrow, the table will be ready.
(A dynamic table has many interesting possibilities. It took time to implement them).
Finally, the dynamic table is done. I have to say that it was not easy. It turns out that there are a lot of nuances.
Also, this table is "conditionally" dynamic. That is, the maximum number of rows is predetermined. It was not possible to make "absolutely" dynamic yet.
This table has 20 possible rows. So, it can display 20 open positions. We could make more, but it's just a demonstration for now.
Click to view.
//---------------------------------------------
Here are the connection files (put in the inline), the engine(in the indicators folder), and the test.advisor (in the experts folder):
Also, I don't know how to check if an order is closed or still open (I forgot). Because of this I have not been able to close a row automatically when a stop or a take order is triggered.
Who knows, please advise.
1. an automatically configurable panel would be ideal.
3. sketched my vision roughly
4. a simple button will do the job.
Tomorrow I will give you the final view of the panel with a din table of orders.
Immediately afterwards I will implement interaction with the panel in the tester.
Great. I'll be waiting.
The dynamic table base is ready. Now you can develop it.
You could try putting other elements in the rows. Entry fields, pop-up lists...
I haven't tried it yet, but in theory it should work.
Finally, the dynamic table is done. I have to say that it was not easy. It turns out that there are a lot of nuances.
Also, this table is "conditionally" dynamic. That is, the maximum number of rows is predetermined. It was not possible to make "absolutely" dynamic yet.
This table has 20 possible rows. So, it can display 20 open positions. We could make more, but it's just a demonstration for now.
Click to view.
//---------------------------------------------
Here are the connection files (put in the inline), the engine(in the indicators folder), and the test.EA (in the experts folder):
The next task is to redo the communication between the EA and the engine. Instead of EventChartCustom(), the connection will be partially implemented through description of МТ objects, and partially, through resources.
The thing is, I've noticed while creating the animation that data transfer through the resource puts a lot of load on the processor. That is, it is not only slower, but also more resource-consuming method.
It has its advantages, - simplicity and convenience. Also, this method is suitable for transferring large amounts of data. But, when implementing communication through resources, in the process of testing, the processor will be loaded even more. After all, the tester itself loads the processor up to 40%. And this will be added to the load from constant saving and reading of the resource.
I think that when passing information through the description of MT-objects there will be no additional load on the processor. Although, this is just a guess.
In general, the resources will be used when passing arrays of data to be processed by the engine (data for graphics, animation), and МТ objects will carry the values of parameters in their descriptions.
ZS. It's possible that the processor is being overloaded by redrawing, though. That is, drawing inside an array of pixels. In other words, constant initialization of the array with values occurring at a high (16ms) timer frequency.