Discussion of article "Graphical Interfaces III: Simple and Multi-Functional Buttons (Chapter 1)"
Based on my personal experience, I can say that making windows "rubber" (i.e. dynamic) is not an easy task at all. If we talk about a simple form of a window, devoid of any objects, it is definitely easier to make it stretchable, but here you need a whole concept of interaction between the user and the window. A standard Windows window has at least 8 handles, the grasping of which allows you to conveniently change the size of the window in any direction.
From my experience I know how to implement it, and something similar has already been implemented in one of the controls planned for publication. An example will be in one of the next articles of this series.
Take for example the"Alert" window. It is not easy to implement such window behaviour.
What do you think is so difficult? This window has only a table with three columns and a "Close" button. When you resize the window horizontally, the width of the columns changes proportionally to the current window width. As for me, it is better to make the width of the columns fixed. And when the window width is changed, let a horizontal scroll bar appear. In any case, all this is within the class of a particular interface element and nothing prevents you from making such an element and just connect it to the library engine.
In the 18th article of the series, three classes of tables with horizontal and vertical scrollbars will be published. In the current implementation they are not "rubbery", but if you really need it, I will make such a feature in the second version of the library later.
Now let's go back to a normal window containing a large number of different kinds of objects. You realise that the objects are in various kinds of relationships with each other. This means that when you resize the window, their locations (or sizes) change differently. Some pictures, for example, move behind the pen, while others stay in place. Some input fields change their length, others on the contrary keep the same size. Therefore, to say that this task is one of the easiest to solve, I think a bit rash).
It is solved by adding methods to classes, with the help of which you can position elements and change their sizes relative to the size of the window. At the moment, all these are minor tasks that can be solved after the first version of the library is published.
I will give my opinion:
1. The interface standardises the forms of windows, objects, as well as their behaviour on various events (reactions to user actions).
There is a standard method of linking a graphical object with its parameter and with a function, one clear classification of windows, objects and events. This
standardisation is completely absent among panels.
2- The interface has an immeasurably large set of possibilities of user interaction with the application. It allows the user to easily change its appearance,
adopting the size or colour required of him. So to speak, it "adapts" to the user's requirements.
3. Thanks to its graphical advantages, the interface allows you to display in windows a much larger amount of information than that displayed by panels.
The first step on the way to the creation of an interface you have undoubtedly made. In your library you standardise the parameters of windows and controls, while leaving it to others to override specific properties within reasonable limits. The next step is to extend the possibilities of user interaction with the interface. And here there are a lot of problems (such as changing window sizes), without solving which your library risks to remain only a form of standardisation of panels for the new generation of developers. Well, and the last step on the way to the interface - creation of methods of interaction of windows with information processed by the application, but in much larger volume than it can be done by panels.
I will be glad to hear objections. :)
Реter Konow:
1. You see, the difficulty is not in copying a particular window and its behaviour, but in creating a system that manages windows in such a way that you can implement any type of links between objects and window handles.
2. This will give you very great opportunities, but once again, OOP will not allow you to implement it effectively.
3. You will have to write too much code.
4. I bet that when comparing my results with yours, the advantage will not be on your side).
1. I don't understand, what is your implementation we are talking about? You already have and will have more opportunities, as the rest of the articles in the series are published, to make a full-fledged comparison with your developments. And what should I compare it with? ))
2. OOP gives you the opportunity to manage all this effectively. Or express your thought in more detail why you think so. Preferably, on some concrete examples with brief code that shows this or that problem.
3. I'm not afraid of the complexity of this or that task and it doesn't matter how much code I need to write for it.
4. I don't understand what advantage are you talking about? I had no plans to get any advantage over you. ))
Retag Konow:
However, I want to raise a question about the difference that exists between the panels offered by many developers in the marketplace and the interface. Why despite their appearance similar to the classic interface (though not all of them), they are not perceived as a full-fledged interface? How do they differ from it? Why is the external similarity of windows and controls to those in the regular interface not enough? At what point can a panel be "recognised" as an interface?I will give my opinion:
...
You have undoubtedly made the first step on the way to creating an interface. In your library you standardise the parameters of windows and controls, while leaving the possibility for others to override specific properties within reasonable limits. The next step is to extend the possibilities of user interaction with the interface. And here there are a lot of tasks (like resizing windows), without which your library risks to remain only a form of standardisation of panels for the new generation of developers.
As for the first and second step, wait until all the articles in the series are published. At the moment, only 10 articles have been published. There will be >25 in total.
Retag Konow:
Well, the last step on the way to the interface is to create methods for windows to interact with the information processed by the application, but in a much larger volume than panels can realise.
If I understand you correctly, I already have such examples. This could include table classes for storing, retrieving and displaying large amounts of data.
Let's assume that you have created a window in which you have placed a table. It happened that the table was too big (let's say it is a table of statistical indicators of trade history). You put a vertical scroll bar in your window (or it appears automatically). But this is not enough. You want the user to be able to resize the window so that he can see only the part of the table he needs. If he uses scrolling, he will still see more than necessary. Conclusion - you need to resize the window. Adjust its field of view to the size of the important area.
About the advantage, it's just in jest. :D
Let me try to formulate the task of creating object and window mappings more clearly.
Let's assume that you have created a window in which you have placed a table. It happened that the table was too big (let's say it is a table of statistical indicators of trade history). You put a vertical scroll bar in your window (or it appears automatically). But this is not enough. You want the user to be able to resize the window so that he can see only the part of the table he needs. If he uses scrolling, he will still see more than necessary. Conclusion - you need to resize the window. Adjust its field of view to the size of the important area.
Now let's imagine that in addition to the table, the window contains various important static objects (such as the help icon, or the settings icon, or the window zoom buttons...). When you resize the window, (if you move the right handle of the window to make it smaller) these objects will have to be outside the window, unless of course they move in the right direction. However, if you move the left handle of the window, these objects remain stationary. You can say that you have bound certain objects to the right handle of the window, and they will only move with it.
However, some objects can be bound to several other objects at once and to all of them differently. For example, you are tired of calculating and prescribing coordinates for each object separately. You just want to snap it to another object that is already set, top, bottom, left or right. You create a binding of one object to another, and if the first object moves, the second one will move after it.
All of the above are fairly simple tasks. I don't see any problems with this. That is, it would be possible to add such features at any stage of project development.
Retag Konow:
Unfortunately it is pointless to show code pieces, as comments to them will exceed the size of this code several times. You are simply not familiar with my programming method and my code will not explain anything to you, but rather will lead you into a dead end. I can only say that everything I write about is implemented and works perfectly well. I will soon post more screenshots and videos.
So there will be no examples explaining why OOP limits your programming abilities? You can just draw a scheme that it is impossible to implement such a project using OOP, but it is possible using your methods. That will be enough.
And what should we do with your screenshots and videos? MQL capabilities allow you to implement graphical interfaces of any complexity. For examples of what a graphical interface can be, it is better to focus on graphical interfaces of operating systems. That is, something that is made with sufficient quality (errors and flaws occur in Windows as well) and can be tested by yourself, not just seen on video.
If your plan was to sell your library, then at least post your free DEMO-examples in the market so that we can test them and draw conclusions. And also write an article where we can understand how to use your library to create GUIs in our MQL applications. Just screenshots and videos are far from enough for evaluation. ;)
My screenshots and videos are just a proof of my words about solving the above-mentioned problem. I was going to provide them to you.
The truth is at the moment that my (not yours) articles are published with a detailed description of the library, which is in fact provided to the entire MQL-community free of charge. Unlike you, this is the proof in practice.
But you only want to show some pictures and videos, so you have started a conversation about nothing, while inventing some other argument. When you publish the code, then we will continue. In the meantime, I will continue working on the other articles of this series so that you can make a fuller comparison later on.
There are at least 15 more articles ahead. So you are too early to start comparing.
Note: I see the small size of the programme as an advantage.
Not funny. Probably as many features as code. If you could remove all comments or even obfuscate them, it would be even smaller.
The truth is at the moment that my (not yours) articles are published with detailed description of the library, which is in fact provided to the whole MQL community on a free of charge basis. Unlike you, this is the evidence in practice.
I didn't want to write anything... but
- Anatoly, it is somehow not very modest there about "truth" and "proof".
- Remember the dialogue: "... how hard it is to read your articles..." the author's reply: "and do you know how hard it is to write them?". Anatoly, thank you for your labour, but I have a question: for whom do you publish "gratuitously" articles? It is not interesting for advanced people, and for beginners it is incomprehensible. There is a lot of code in which you don't want to pick and systematise what you have written at all.
- Anatoly, your reader asks questions about your article and apparently you are not satisfied with it. And moreover, his opinion does not interest you at all and even irritates you. Then what makes you write articles?
- Authors need criticism in order to change for the better.
With all due respect to you, be closer to your readers and don't get excited at half a turn on the spot.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Graphical Interfaces III: Simple and Multi-Functional Buttons (Chapter 1) has been published:
Let us consider the button control. We will discuss examples of several classes for creating a simple button, buttons with extended functionality (icon button and split button) and interconnected buttons (button groups and radio button). Added to that, we will introduce some additions to existing classes for controls to broaden their capability.
Here, we are going to consider the button control.
Button is the simplest control in the graphical interface that a user can interact with. At the same time, there can be several implementation options. In this article, we are going to create three classes for creating buttons of different levels of complexity.
Adding to that, we will implement other three classes for creating groups of interconnected buttons.
We will also introduce additions for enriching functionality of the context menu with one more mode. The CWindow form class will receive one more field with a method which will allow to define exactly which control blocked the form at the moment of its activation. This will allow to create conditions when the form can be unblocked only by the control that blocked it.
After compiling the files and loading the test EA on to the chart, you should see the result as shown in the screenshot below:
Author: Anatoli Kazharski