My approach. The core is the engine. - page 50
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
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, one can do that too. The only question I have is for whom? Peter says that "it will create a layer of such users". Well, well... We'll see.
A good memory is certainly good :) But the memory has this property that with age, it gets worse or become selective. What you remember very well and what you think is insignificant immediately slips your mind. :)
You have a strange competitive spirit :)
Just for the sake of interest, would you be able to 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.
Good, powerful GUI. I can reproduce 85% of its mechanics with the constructor. I also have drag&drop, dynamic windows. The rest is the task of the program (flickering numbers in cells, called functions).
As for instruction windows - that's also reproducible. In short, in my version, the appearance will be slightly different, but the functionality will be almost the same.
But, the scale and numbers are not implemented in my version. And there is no scaling.
However, unlike this GUI, my graphics will be more beautiful. Gradients, icons, nice frames, shadows... The elements are all drawn.
But, for a modern marketplace - your product is very powerful. Probably one of the most powerful.
And the fact that not many people bought it - you can thank the tester grails. They have rendered all products meaningless except for themselves.
and why this new style?
You wrote that per 30-100 orders come across one order for the development panel, more often does not happen, less often happens
if you want to freelance, goto https://www.mql5.com/ru/search#!keyword=%D0%BF%D0%D0%B0%D0%BD%D0%B5%D0BB%D1%8C&module=mql5_module_jobs
that's all the demand, and notice that panels are required for trading, and no one is interested in analytics and calendars in a panel
ZS: Have you heard the joke about elusive Joe? With all due respect, but your GUI is good, but very few people are interested, less effort can get any result with a dll, make a panel which in your opinion users need and in Market, a month will be statistics ...
PS: never had any desire to deal with C# .Net, but since the developers have made support, I had to spend an hour to find a simple c compiler with a form designer - SharpDevelop (14 Mb) and googling how to run a form from .dll, everything works and everything "spins", the code itself, which prescribed the hands literally - 3 lines!!!
MQL developers made it easy to work with .dll in C#, you just put a ready-made dll in the Libraries folder and write in the first lines of the Expert Advisor the name .dll - that's all ;)
You just don't want to understand. What difference does it make? Your variant is not for the masses.
People are looking for profit. In this search they are stuck on one and the same tester-grails. That is, programs that promise enrichment based on tester readings. That's it. It's a dead end from here.
Will it last forever? Will they always trust the tester? Will they never be disappointed looking at tens of thousands of "dead" robots?
I propose a way out of the impasse. Semi-automated programs where the user will be responsible for their own actions.
You think no one wants this? You are mistaken.
Peter, that's the thing - there's nothing to use. Any window is either just a decoration or a point of dialogue. The point of dialog implies the need for this dialog.
Imagine that you are a trader and the program asks you something. It needs to know it from you. What it can ask you, and you can answer this question with a button or a form? I am seriously interested in your opinion on this - answer me if you do not mind.
And the second situation: you consider it necessary to intervene in the work of the program - what button / form will allow you to do it efficiently?
I absolutely agree with you that automation of an activity is the task of those who automate it, but you pretend to be a creator of tools to develop a man-machine interface in this area. An interface of buttons and forms, or a normal GUI that allows full work with all the graphical objects of MT; an interface of objects, or interrupts too?
You claim to create a standard; I, by automating something, claim that any, or almost any, graphical operation I generate will be accepted by your interface. Otherwise we don't need each other.
Any window can have several possible functions:
Any window can have several possible functions:
That is the reason and the answer!
A good memory is certainly a good thing :) But memory tends to deteriorate or become selective with age. What you remember very well and what you think is insignificant immediately slips your mind. :)
That's your memory (and mine too).
Peter has a different memory and it gets better with age, like a good wine. Peter always remembers everything he's written, and how and why, and what he was thinking about. So he really doesn't need OOP.
I envy Peter's memory.
I can reproduce 85% of its mechanics with a constructor.
I have my doubts :) If only windows, buttons, controls ... But that's the least there is.
Your interface won't even be able to process the tumblr traffic, and you still need to render some indicators.
Oh, and this is the first version of gui library, with minimal use of kanvas, everything is implemented on kanvas now, except text input.
People are looking for profit. In this search, they are fixated on the same tester grails. That is, programs that promise enrichment based on tester readings. That's it. It's a dead end from here.
Will it last forever? Will they always trust the tester? Will they never be disappointed looking at tens of thousands of "dead" robots?
Why would it be "dead"?
ANY robot has earning periods. ANY ONE. Even the lamest of my League MUs have short earning spans. So there's no way to call them "dead".
It's like with clothes. Of course, shorts, flip-flops and a panama suit for life somewhere in Arkhangelsk. But you won't claim they're "dead clothes". Moreover, on some days you can wear them even in Arkhangelsk.
And vice versa - on the coast of the Black Sea tulup and fur boots look silly in summer. Although, sometimes they are very necessary even on the Black Sea shore.
The same is in the case of trading robots: every market has its own trading robot. And the trader's task is to select the robot that suits the market. This is why you cannot say that "people will be disappointed", just as no one is disappointed in shorts or panama pants and no one is disappointed in a raincoat. You just have to wear the former when it's hot and the latter when it's cold.
The tester is not a hindrance or a panacea. It tells you what the market has been lately, and allows you to pick up a TS that matches it. But, this does not mean that the market will not change in the next few days, and the TS will not no longer fit it. However, a robot that has made a profit on history is preferable to a robot that has lost on history.
Manual trading can only be consistently profitable if one has a lot of experience. Just to understand when and what technique to use. Do you think many people have it?
I have my doubts :) If only windows, buttons, controls ... But that's the least there is.
Your interface won't even be able to process the glass traffic, and you still need to render some indicators.
Yes, and this is the first version of gui library, with minimal use of kanvas, everything is already implemented on kanvas now, except text input.
The builder is designed for generic solutions. Your program is customized for specific tasks.
You can make and run a tumbler on the constructor and it will work. But drawing of all sorts of indicators is not included into the tasks of the constructor so far.
This can be done by the user in his/her program.
And what about the fact that it won't pull the traffic of the glass:
Click on the picture to see the gif. As you can see, the redrawing speed of the table elements is fast enough to pull the traffic of the tumbler (there are even more cells).
And as for not pulling the traffic of the tumblr:
Click on the picture to see the gif. As you can see, the rendering speed of the table elements is fast enough to pull the traffic of the cup (there are even more cells).
I wasn't talking about the rendering speed, I was talking about the traffic(exchange) between your gui and the user program.
Of course, any program is tailored for a specific task, but using, for example, standard library, you can add an animated object in the window, and in your gui no, you have to ask for it :(