My approach. The core is the engine. - page 49

 
Алексей Тарабанов:

On Istok?

No. A numbered institute, I can't remember the number now.

And even then I wouldn't say :-)

 
:)
 
Реter Konow:

For the sake of interest, can you make up and show here the code you need to write to replicate my window and we'll compare with my version.

You have a strange competitive spirit :)

Just for the sake of interest, can you use your gui to create an analogue of such a program:


The program was written in two months in 2013, with another parallel project still in progress.

The program was last compiled in 2014, so some mishaps are possible :)

It is better to run the program on exchange-traded instruments.

Clarification for moderators: This program is not on the market.

Files:
IShift.ex5  3312 kb
 
Yury Kulikov:

The programme was written in two months in 2013, with another parallel project still in progress.

Clarification for the moderators: this programme is not on the market.

is of high quality and has a decent look! I especially like that there is a manual - this is also a work in progress

but then again, you have to do this either professionally or not at all, i.e. having written such code, you need to keep writing and selling it in the Marketplace, otherwise the workload is very high.

How big is the demand for such programs? - Are there at least 5 pieces sold per month?

 
Igor Makanu:

How big is the demand for such programmes? - Do they sell at least 5 a month?

Only 8 have been purchased in probably three years.

 
Yury Kulikov:

Only 8 pieces were bought, probably in 3 years.

sadly....

that's what all this discussion is about, for me as someone interested in markets, it's enough to connect the .dll in 3 clicks and then in the form designer, I can do all the gimmicks, i.e. the standard MT tool is enough for me and everything that I find labor intensive I will do on third-party software

If you are a developer, you need to put in the Market not a "coloring book with calendars", but a fully functional product that can generate profit or be an effective analytical tool - as an example@Yury Kulikov

Has anyone figured out what@Peter Konow wants to monetize?

 
Why don't you do the same using OOP. I don't understand why you don't use its possibilities and don't even try to grasp the OOP principles. The profession of an IT specialist in itself presupposes that this very specialist is constantly engaged in self-education. Since technologies don't stand still new programming languages appear and PC capacities are growing. In general, progress does not stand still. But you with your programming style are stuck at the level of 2000 and you suggest that other programmers return to the level of those ragged years. I've said it many times and I'll repeat it once again. Try to do all this using RPF.
 

What Peter has in mind is certainly a good thing. But to make such an engine, you need some smart human resources.

And there won't be much demand, because in MQL to create panels, I personally know 3 ways: simple MQL objects, standard objects and Canvas.

And for simple users you don't need huge panels, with numerous parameters and possibilities. And here's what's needed:





P.S. This robot is not yet for sale in the market, but as soon as it comes out, I will remove the video.

 
Алексей Тарабанов:

This is where I disagree. Semi-automated trading implies semi-automated trading, not the ability to click on a "buy-sell" button, or any other button.

To my great regret, the author stubbornly gives me a mechanism for generating these buttons - and that's all.

Well, where is the interactivity of an EA when one of its major levels has suddenly moved to a new home location, where it was moved by a user (he's in charge); where is the tracking of new (or - just, main) trend lines, which the EA has not created before?

In semi-automated trading, part of the work is done by the Expert Advisor (this work is always routine), the other part is done by the trader (generates information on the basis of the insight - not to be confused with the insider). After that, the Expert Advisor picks up the result of the interactive process of joint activity and brings it to its completion, remaining constantly ready for repeated intervention of the trader and repeated correction of its actions.

Do we draw the bullets, or automate the activity?

Peter seems to suggest exactly the GUI library for such a semi-automatic Expert Advisor.

That is, the semi-automatic is you write it yourself. And Peter's library - just help you easier (is it easier?) to display the user controls.

I've already said many times - for the target audience the library is good enough. But the problem is in extreme narrowness of this very target audience. All criticism of Peter here is from people who are not part of the target audience - they are all programmers who, even if they have "semi-automatic" (in fact, automata with a little manual addition) - they do not require much control, and these people prefer to write programs for themselves. Peter needs people who can program, but prefer manual trading - that is, manual entry, manual stops setting and transferring, manual closing. Expert Advisors only provide information in a handy form.

I have not found any such people among critics yet, and I am sure there are very few of them.

Peter claims that "he will create a layer of these people" - I highly doubt it. Teach a programmer to trade manually and then prove to him that manual trading on a semi-automatic machine is better ? Unrealistic. But, let's see, maybe I'm wrong.

 
Vitalii Ananev:
Why don't you, Peter, do the same using OOP. I don't understand why you don't use its features and don't even try to get into OOP principles. The profession of an IT specialist implies that this very specialist is constantly engaged in self-education. Since technologies don't stand still new programming languages appear and PC capacities are growing. In general, progress does not stand still. But you with your programming style are stuck at the level of 2000 and you suggest that other programmers return to the level of those ragged years. I've said it many times and I'll repeat it once again. Try to do it all using RPF.

Vitaly, the problem is that Peter is a titan of memorisation. He does not forget where and what indexes he has, what they mean, what connections they have and where.

With such an awesome memory OOP-enhancements are just unnecessary gestures, and some performance degradation. What for?

OOP is for those who won't remember in a week why they can change the variable in a given place and not in the neighboring one. They are the ones who need encapsulation, public, protected and preverted class sections, virtual interfaces, polymorphism... And when you have everything in memory, like a computer, it's much easier to access each object directly, without any OOP enhancements.

Suggest to Peter a class of smartpointers, that take into account the number of references when passing objects, and then, when no one refers to them, delete them! Peter will be surprised, he remembers well when each object is created, how many users it has, how long it should exist, and when it should be deleted. What's the point of using them ?


No, you can do it that way too. The only question I have is for WHOM ? Peter claims that "it will create a layer of such users". Well, well... We'll see.

Reason: