Discussion of article "Graphical Interfaces XI: Refactoring the Library code (build 14.1)" - page 3
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
There is nothing else from you but blathering. )
Everything that has been done is certainly not because you said so. All this was planned from the beginning and published strictly in a certain sequence. But you can of course think otherwise and continue to be, as you say, in "the chaos of a desperate search for a new version of yourself". I don't mind. )
I also said that technological growth is conditioned not only by extending and adding functionality but also by compressing and universalising code. Combining disparate functions into blocks. This is exactly what you have demonstrated in the article.
You have repeatedly merged several classes into one and compressed the code. At the same time, the classes have become more universal in the sense that one class contains several similar elements and their selection is performed by the mode. This is compression and universalisation.
Again, I was right.
So where was I wrong?
Of course, you didn't do everything because of what I said. I know that. But I was right in what I said.
Remember the only way to get rid of a troll? That's right, don't feed it.
Remember the only way to get rid of a troll? That's right, don't feed it.
I'll give you some explanations. For dessert. )
...
Of course you didn't do everything because of what I said. I know that. Except that I was right in what I was saying....
Who cares if you're right or wrong? ) Regardless of what others tell you, you are still what you think you are. )
You have said things that are self-evident and it was pointed out to you from the beginning. But besides that you also broadcast a lot of nonsense. For example, that it is impossible to implement such a scheme efficiently with the help of OOP. Though how could you make such conclusions if you don't even know OOP?
Have you noticed that the general scheme remains the same as before refactoring? And there was no difficulty in such a transition. The main time was spent just to go through several dozens of files and tests.
In the current implementation the transition to the third stage would be even easier. The difficulty is precisely not that. If I were doing such an implementation, I would draw everything from start to finish on a single object, not as demonstrated by some forum members, when some objects sometimes (for the time of use) appear on top of the main GUI. From the point of view of personal development as a programmer, I am no longer interested in such half-measures. It is not far from what is done now in the version presented in the article. And users of MQL-applications will not see any difference at all.
In my current version all elements are drawn on separate objects and there is only one exception - objects-graphics(OBJ_CHART). It would be interesting to realise such an element in a drawn form in such quality and with such capabilities, but at the moment it just doesn't make sense. There are things that are much more interesting to me in the MQ services presented by MQ developers on this site. Literally two or three more articles on "GUIs" in the near future, and then updates, if any, will be very rare. Mostly it will be a deep optimisation of the library, where resource consumption will be kept to as low as possible.
Some explanations I'll give you. For dessert. )
1. Who cares whether you are right or wrong? ) Regardless of what others tell you, you will still be to yourself what you think you are. )
2. You said self-evident things and it was pointed out to you from the beginning. But besides that you also broadcast a lot of nonsense.
3.For example, that it is impossible to implement such a scheme efficiently with the help of OOP. How could you make such conclusions if you don't even know OOP?
4.Have you noticed that the general scheme remains the same as before refactoring? And there was no difficulty in such a transition. The main time was spent just to go through several dozens of files and tests.
5. In the current implementation, the transition to the third stage would be even easier. The difficulty is precisely not that. If I did such an implementation, I would draw everything from start to finish on one object, not as it was demonstrated by some forum members, when some objects sometimes (for the time of use) appear on top of the main GUI. From the point of view of personal development as a programmer, I am no longer interested in such half-measures. It is not far from what is done now in the version presented in the article. And users of MQL-applications will not see any difference at all.
In my current version all elements are drawn on separate objects and there is only one exception - objects-graphics(OBJ_CHART). It would be interesting to realise such an element in a drawn form in such quality and with such capabilities, but at the moment it just doesn't make sense. There are things that are much more interesting to me in the MQ services presented by MQ developers on this site. Literally two or three more articles on "GUIs" in the near future, and then updates, if any, will be very rare. Mostly it will be deep optimisation of the library, when resource consumption will be kept to the lowest possible minimum.
1. Not really. If I am wrong and there is convincing evidence for it - then I admit it and change my point of view.
2. Often these obvious things are not obvious at all. A developer's ability to think abstractly and understand the development process on a large scale is a plus. I didn't find this understanding from you, that's why I was talking about it. I am interested in the philosophical background of the action, not just digging into details and routine. Getting to the core and seeing the essence. Knowing the script and the logic of the process is valuable to some people. )
3. It is difficult to say how effective the implemented scheme is now. It is relative. However, there are parameters by which you can determine the effectiveness of the implementation. I think they can be found. In this case, one could compare the efficiency of implementation of the same mechanisms, but made by a different technology. Then we can draw a conclusion about the effectiveness. If you want, we can try to find out. I still think this implementation is not effective enough. Alas, there are reasons.
4. Not exactly the same scheme. You've made changes to the base classes. In the "core" of the library. What you said in the article. Outwardly, the scheme is similar, but you have switched to a different technology of creating elements.
5. By the way, I never said that I want to make a fully drawn GUI on a single bitmap. I consider that idea to be a bad idea. It's obviously not the best solution from many points of view. So for me, - it's not a "half-measure", but a choice towards a more practical option.
I'll add: You can do everything on one bitmap as follows: All drawn elements are arrays with image pixels. Once they are created, you create one bitmap and a large image array and shove the contents of each element into it sequentially. As a result, you have a bitmap with a complete image of the entire contents of the window. I am one step away from this. I think you can do it too.
...
That's when we can conclude the effectiveness. If you want, we can try to find out. I still don't think this implementation is effective enough. Alas, there are reasons.
...
...
I should add: You can do everything on one bitmap as follows: All drawn elements are arrays with image pixels. Once they are created, you create one bitmap and a large image array and shove the contents of each element into it sequentially. As a result, you have a bitmap with a complete image of the entire contents of the window.
...
No comment, Captain Obvious. )
You should first publish effectively. Because no one has ever held the object of your "efficiency" in their hands except you. Probably because of the fact that it is so effective that it is scary to show it. )
No comment, Captain Obvious. )
So let's compare efficiencies, shall we? I made a direct suggestion.
I don't mind. Compare. )
Ok.
1. First we will define the criteria for evaluating the effectiveness of the technology used.
2. Then we will define criteria for evaluating the effectiveness of the implemented mechanisms.
3. We will choose the same mechanisms made by me and you and conduct tests with them.
After that, we will come to an unambiguous conclusion.
Do you agree with the plan?
...
First we
...
Not us, you. I have something to do (read more carefully). I have no desire to waste time. )
That's a shame.
It's a pity that the fighting spirit is resting somewhere now...).