Discussion of article "Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)" - page 2
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
Great. If possible, more pictures with examples of graphical interfaces. In general, the topic is very necessary: long time ago it was necessary to start documenting the standard library.
Perhaps I misunderstood the question before.
By using classes from the standard library I meant only classes of this kind:
That is, those classes with which you can create primitive objects, get and change their properties.
But (let me clarify) I do not use from the standard library the part that is offered for creating graphical interfaces. This is a completely separate project.
P.S. There will be a lot of pictures and examples (maximum detail).
I may have misunderstood the question before this.
By using classes from the standard library I meant only classes of this kind:
That is, those classes with which you can create primitive objects, get and change their properties.
But (let me clarify) I do not use from the standard library the part that is offered for creating graphical interfaces. This is a completely separate project.
P.S. There will be a lot of pictures and examples (maximum detail).
Ah, now I see.
And why did you decide not to base your project on the GUI library from MQ? Maybe it would be easier to expand and deepen it?
By the way, I have my own GUI library, it would be interesting to compare concepts.
Ah, I see.
Why did you decide not to base your project on the GUI library from MQ? Maybe it would be easier to expand and deepen it?
By the way, I have my own GUI library, it would be interesting to compare concepts.
I outlined my thoughts on this at the very beginning of this article. To summarise, to get it right (in my opinion) you should have started the project from scratch.
I think that the first 14 articles of this series will already allow you to make a proper comparison of concepts. There are a lot of nuances here, without the realisation of which it was impossible to achieve high quality.
Interesting and useful project conceived! I will look forward to the publication of your articles!
Regards...
Good afternoon!
I have a twofold feeling when familiarising myself with the created library. On the one hand I am amazed by the flexibility and flexibility of the library. The work done is huge, for which of course you can say a big THANK YOU!
On the other hand, the implementation of some points is puzzling, as it increases the labour intensity of creating new forms.
For example, let's consider the function to move the form on the graph.
In the function it is necessary to enumerate all created form objects. Why? Because all the created elements are placed in the container (array) of the form itself. Why do you need to enumerate all the created elements in the function? Why can't you just loop around the container and change the coordinates of all the elements?
The same applies to other methods. For example, in the Hide() function all elements are hidden by looping through the form elements, and in the Delete() function all elements are listed discretely. Unclear.
This leads to the fact that when adding new elements to the form, you have to remember all the STANDARD functions where you need to specify each new element. This is very NOT convenient. All the same applies to the focus on an element. If an element is in focus, then its display should be changed according to the algorithm WHEN it is created, e.g. for picture-based buttons the pictures "BmpFileOn" and "BmpFileOff" are specified. There you could also set other properties for the focus: frame colour, background colour, text colour, text size and so on. And in this case, there is no need to write it in the focus definition function, you just need to traverse the array of elements and set their properties according to the "in focus"/"out of focus" properties.
Collapsing...
Initially, the library is designed in such a way that the form is collapsed under the header (up). At the same time, the header remains where the form is. I'm trying to implement the standard behaviour of the created form, i.e. when the window is minimized, the window is minimized downwards and only the header remains (at the bottom). Moreover, I am trying to implement two modes of the form: "standard", "minimised", and of course minimised.
Already at the stage of creating my buttons I faced all of the above problems. And the development has just started....
I also believe that it would be more universal to create not one container (array) for storing created elements and operations on them, but a hierarchy of containers. That is, a single container is created for the whole form, which allows you to perform common actions on the form: moving, deleting, hiding and so on. This container should include two other containers: the container of header elements, the container of form elements itself. A third container is also possible: the basement container, if there is one. In turn, the container of the form itself may contain containers of blocks for placing elements on the form. In such an implementation, say, minimising the form down should result in deleting the elements of the form container itself and moving the elements of the header container. When performing general actions, perform operations on the containers themselves. That is, if the form itself is moved, then the container of elements of the whole form (application) is moved.
I hope the author will understand my idea. :)
Once again I repeat: the work done is great, useful and informative. But any step away from the author's representation starts to create difficulties. Of course, there are no completely universal solutions. But some common standard functions of the library could be made really universal.
Regards, Alexey.
...I hope the author will understand my point.....
My point is clear. Thank you.
The library is still under development. It is far from the last version and many parts of it will be optimised and developed.
You can download the latest version (2016.11.20) in this article: GUI X: Text Input Box, Picture Slider and Simple Controls (build 5).
I see your point. Thank you.
The library is still under development. It is far from the latest version and many parts of it will be optimised and developed.
You can download the latest version (2016.11.20) in this article: GUIs X: Text Input Box, Picture Slider and Simple Controls (build 5).
I know it's not the last one. :) I downloaded the latest one for mt4 and I'm trying to build the interface on it. But I understand that the library for mt5 will also work under mt4, if there were not used mechanisms specific for mt5.
I hope those comments and suggestions that I have voiced will be reflected in the next versions of the library and it will become even more flexible and universal, and at the same time more simple from the point of view of practical application. During the development of the library was used "cascading" mechanism of inheritance of classes, the same I proposed and for the formation of form elements, that is, inheritance of containers. And the descendant can use not only global properties (of the whole form-application), but also properties of the parent: anchor points, visibility, movement and so on. :)
I will follow the release of new articles and the development of the library with great impatience.
Regards, Alexey.
I know it won't be the last. :) I downloaded the latest one for mt4 and I am trying to build the interface on it. But I understand that the library for mt5 will also work under mt4, if there were not used mechanisms specific for mt5.
MT4 version will not be developed from my side. Only for MT5.
I hope those comments and suggestions that I have voiced will be reflected in the next versions of the library and it will become even more flexible and universal, and at the same time more simple from the point of view of practical application.
Initially, it is difficult to say anything. You can think theoretically about how it would be better for a long time. Everything will be clear on real tests.
The version for MT4 will no longer be developed on my end. Only for MT5.
Initially it is difficult to say something. You can think theoretically about how it would be better for a long time. Everything will be clear on real tests.
Yes, I have already read that for mt4 version will not be developed - it is not terrible.
Well, the fact that only tests can show how to build a library better is undeniable. But from the point of view of OOP the proposed method has the best chances of practical implementation. :)