Discussion of article "Custom Graphical Controls. Part 3. Forms"
A good and useful piece of work, Dimitri. There is a suggestion for the fourth part: "Form Wizard" or "Visual Form Editor". What do you think about it?
Respect, Dimitri. You have done a great job.
Please accept some criticism for the next version of v4 classes.
1. there is not enough abstraction in the basic project. It turned out that each control you have acts as an independent unit. As a result, you can't combine them into an array, for example.
2. Each class of an element now has, by and large, its own unique set of functions. This is not a good thing. There should be one common ancestor whose functions are simply overridden in descendants. Especially since there are so many functions with the same name in the current classes. what's stopping you from making a common ancestor?
3. if a base class appears, it will be possible to hide event handling inside the descendants, instead of putting all of them outside in the form. to make a cascade of events inside objects (similar to CSS in the web).
But in general, all three parts of the article are worthy of award, especially I liked the "nudges" when pressing buttons and their interactive responses to presses depending on the state of the element.
PS.
And the multilevel menu you still finish, a separate article on it is not necessary, too fat for such a small task to write a new article. Let it be just an upgrade in v4 version.
The CTreeCtrl tree class can be taken from the article https://www.mql5.com/en/articles/272 or CTreeNode offered in the MT kit.
- 2011.03.16
- o_O
- www.mql5.com
A good and useful piece of work, Dimitri. There is a suggestion for the fourth part: "Form Wizard" or "Visual Form Editor". What do you think about it?
Personally, I see it positively. But is it necessary? Visual only simplifies the placement of objects. If you do it properly, you need to bind code generation for created objects, binding of variables or classes to the object. And most importantly, event handling.
But in these non-abstract classes it can't be done. They are very manual. In many places it is necessary to write newly created objects and their processing.
For events, for example, there is no such division into system and user - like Draw (basic system) and OnDraw - addition from the user with its own drawing.
In other structures (for example Joomla!) there is not only one custom function OnDraw. And it is divided into two - BeforDraw and AfterDraw. That is, the programmer can handle the system event EVENT_DRAW - both before the start of system drawing and after its end.
Respect, Dimitri. You have done a great job.
Please accept some criticism for the next version of v4 classes.
1. there is not enough abstraction in the basic project. It turned out that each control you have acts as an independent unit. As a result, you can't combine them into an array, for example.
2. Each class of an element now has, by and large, its own unique set of functions. This is not a good thing. There should be one common ancestor whose functions are simply overridden in descendants. Especially since there are so many functions with the same name in the current classes. what's stopping you from making a common ancestor?
3. if a base class appears, it will be possible to hide event handling inside the descendants, instead of putting all of them outside in the form. to make a cascade of events inside objects (similar to CSS in the web).
But in general, all three parts of the article are worthy of award, especially I liked the "nudges" when pressing buttons and their interactive responses to presses depending on the state of the element.
PS.
4. A multi-level menu you still finish, a separate article on it is not necessary, too fat for such a small task to write a new article. Let it be just an upgrade in v4 version.
The CTreeCtrl tree class can be taken from the article https://www.mql5.com/en/articles/272 or CTreeNode offered in the MT kit.
1- You can assemble single-type controls into an array. Why would you want to collect dissimilar controls into one array?
2. If you use a base class (one for all controls), it means that it must have all the methods that any of the subclasses can have. With independent classes, in the drop-down list of methods (during development), we have only those methods that actually exist in the class. In my opinion, this is a very important point. I can imagine someone sitting and trying to call the SetWidth() method for a vertical scrollbar.
The second argument - all classes are commented for doxygen, if there is a base class and subclasses, there won't be so obvious structuring in documentation.
I try to make ready-made solutions so that they can be used with "eyes closed". To speed up the process of creating a new control, you can use a template with all the mandatory methods.
3. I don't quite understand. If a control has another control in it, its event handling is hidden. In any case, you will have to call Event() for each control.
4. I don't know, maybe... I have my own class specially designed for menu creation, it is not necessary to call AddNode(), AddItem() is called, and the level is determined by the number of spaces with which the name of the item begins. The process of creating a tree is very clear. So far it works with the display in the comment and key control. In general, you can make several tree menus: 1) like a regular main menu with drop-down tabs, 2) display items of one tab and the path to the top, 3) with tree display (like windos explorer).
1. Personally, I see it positively. But is it necessary? Visualisation only simplifies the placement of objects. If you do it properly, you need to bind code generation for created objects, binding variables or classes to the object. And most importantly, the processing of events.
2. But in these non-abstract classes it cannot be done. They are very manual. It is necessary to write in many places newly created objects and their processing.
For events, for example, there is no such division into system and user - like Draw (basic system) and OnDraw - an addition from the user with its own drawing.
In other structures (for example Joomla!) there is not only one custom function OnDraw. And it is divided into two - BeforDraw and AfterDraw. That is, the programmer can handle the system event EVENT_DRAW - both before the start of system drawing and after its end.
1. It will be possible to automatically generate the code for handling events of controls and get event functions for all controls, like HScrollBar1_OnChange()....
2. There are no events yet, for example, when values are set programmatically, events are generated only when values are entered by the user. This is a sufficient minimum, nothing extra. Otherwise, someone learning programming on his own will be flooded with events.
A good and useful piece of work, Dimitri. There is a suggestion for the fourth part: "Form Wizard" or "Visual Form Editor". How do you look at it?
... There is a suggestion for part 4: "Form Wizard" or "Visual Form Editor". What do you think of that?
1. single-type controls can be assembled into an array. Why to collect different types of controls into one array?
To bring everything into one loop and get rid of specific types in event servicing.
2. If you use a base class (one for all controls), it means that it must have all the methods that any of the subclasses can have. With independent classes, in the drop-down list of methods (during development), we have only those methods that actually exist in the class. In my opinion, this is a very important point. I can imagine someone sitting and trying to call the SetWidth() method for a vertical scrollbar.
All the functions in the base class are empty stoppers with minimal general functionality. Even if someone unknowingly calls an unrelated function for an element, absolutely nothing bad will happen. that's the power of OOP. Polymorphism.
The second argument - all classes are commented for doxygen, if there is a base class and subclasses, there will not be such an obvious structuring in documentation.
there will be. only it will be different... :)
- 2010.03.25
- MetaQuotes Software Corp.
- www.mql5.com
1. to get everything into one loop and get rid of specific types in event servicing.
2. the point is that the base class - it has no implementation of functions of specific actions. all functions in the base class are empty stoppers with minimal general functionality. Even if someone unknowingly calls an unrelated function for an element, absolutely nothing bad will happen. this is the power of OOP. Polymorphism, however.
3. it will. only it will be different.... :)
1. Is that all? For the sake of this to mess around with point 2 - method dump?
Alternatives:
1) The need to manually add an Event() call for each class (which consists in copying with the mouse one line and changing a few letters to the left of the point) and at the same time, in the list of methods of each class we have only working methods corresponding to this class, clicked the point, the list popped up and everything is clear.
2) Automatic processing of Event() of all classes, while one function will still need to be called from OnChartEvent(), and on the other hand: a dump of methods in the list. Also, you'd have to destroy pointers in the deinit.
Look a little deeper and further, why all Event() should be processed in one loop, each control should have its own actions for its Event(), controls are not only for entering a value and not only for making everything move and flicker on the screen, but also (to the main extent) to use the entered values in the programme.
3. You will have to read about half of the methods of one control in one place in the documentation, and the other half in another.
1. That's it? For the sake of this, to mess with point 2 - the dumping of methods?
Alternatives:
1) The need to manually add an Event() call for each class (which consists in copying with the mouse one line and changing a few letters to the left of the point) and at the same time, in the list of methods of each class we have only working methods corresponding to this class, clicked the point, the list fell out and everything is clear.
2) Automatic processing of Event() of all classes, while one function will still need to be called from OnChartEvent(), and on the other hand: a dump of methods in the list. Also, we'll have to destroy pointers in the deinit.
Look a little deeper and further, why all Event() should be processed in one loop, each control should have its own actions for its Event(), controls are not only for entering a value and not only for making everything move and flicker on the screen, but also (to the main extent) to use the entered values in the programme.
3. You will have to read about half of the methods of one control in one place in the documentation, and the other half in another.
You have done everything right.
Given the possibilities of ME is quite convenient, Japanese minimalism in the era of total kitsch, everything is there, nothing superfluous.
Those who want to loop through objects can implement a postfix shell where they can write whatever they want.
- 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 Custom Graphical Controls. Part 3. Forms is published:
This is the last of the three articles devoted to graphical controls. It covers the creation of the main graphical interface component - the form - and its use in combination with other controls. In addition to the form classes, CFrame, CButton, CLabel classes have been added to the control library.
Author: Дмитрий