Making a crowdsourced project on Canvas - page 39
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
...
Peter, you've done a great job of creating a GUI library in your style. But if you plan to publish it, it's still worth redesigning it to a different technology. I'm ready to help you in this and step by step transfer all the power of your library in a new way.
Alexey, let's say I would like to try it. How do you propose to do it? It's an impossible job.
Peter, I probably can't imagine even a small fraction of the amount of work you've done, and I'm more than sure that I simply underestimate the full scale of the objects created. BUT!
As always, there is a BUT!
Any project, not even necessarily in programming.
To begin with, we abstract away from the objects that have been created. That is, we won't represent them as a matrix, structures or classes. We will simply accept the notion of an OBJECT (aka control element, aka form, aka interface as a whole, and so on). You try laying out the interaction of objects structurally. When we find out together what is built, we will try to reveal the regularities on this basis. In principle, you won't have to identify them because you identified them long ago and made a unified treatment for them, you will simply explain the principle of operation and purpose. Then we will simply substitute one object for another in your project. Of course, it will be much harder than to write from scratch. But we have a slightly different goal in our case, so by and large there is no hurry. But publications on translation of the matrix algorithm into the object algorithm would probably be interesting not only to beginners. I am convinced that in the process of this work other participants will join us and share their ideas or prompt a more convenient implementation of this or that algorithm.
One way or another, the idea itself must first be represented by a flowchart of the algorithm.
I have made my suggestion. But you can do otherwise, it all depends on your desire and view of the issue (joint work).
Peter, I probably can't imagine even a small fraction of the amount of work you've done, and I'm more than sure that I simply underestimate the full scale of the objects created. BUT!
As always, there is a BUT!
Any project, not even necessarily in programming.
To begin with, we abstract away from the objects that have been created. That is, we won't represent them as a matrix, structures or classes. We will simply accept the notion of an OBJECT (aka control element, aka form, aka interface as a whole, and so on). You try laying out the interaction of objects structurally. When we find out together what is built, we will try to reveal the regularities on this basis. In principle, you won't have to identify them because you identified them long ago and made a unified treatment for them, you will simply explain the principle of operation and purpose. Then we will simply substitute one object for another in your project. Of course, it will be much harder than to write from scratch. But we have a slightly different goal in our case, so by and large there is no hurry. But publications on translation of the matrix algorithm into the object algorithm would probably be interesting not only to beginners. I am convinced that in the process of this work other participants will join us and share their ideas or prompt a more convenient implementation of this or that algorithm.
One way or another, the idea itself must first be represented by a flowchart of the algorithm.
I have made my suggestion. But you can do otherwise, it all depends on your desire and view of the issue (working together).
All right. I will do what I can. I will explain the solutions and architecture. But I don't know if I will succeed in the end.
Now the objects are arranged in the kernel. They need to be taken out of the kernel and put into classes.
1. I'd probably create three basic classes: "Rectangle_label", which would accommodate all the basic properties of rectangle labels, "Icon", and "Text". These objects are part of almost all controls.
2. Next, create a group of descendant classes. They would be divided by the following criteria: a) elements that control a parameter. b) elements which are controlled by the parameter.
3. The classes would describe the specific properties of each element.
These are just the first ideas. They may be wrong.
With this scheme, inheritance immediately turns out to be multiple - element classes (heirs) must include properties of three base classes at once.
All right. I'll do my best. I'll explain the solutions and the architecture. But I don't know if I'll be successful in the end.
Right now the objects are organized in the kernel. They need to be taken out of the kernel and put into classes.
1. I'd probably create three basic classes: "Rectangle_label", which would accommodate all the basic properties of rectangle labels, "Icon", and "Text". These objects are part of almost all controls.
2. Next, create a group of descendant classes. They would be divided by the following criteria: a) elements that control a parameter. b) elements which are controlled by the parameter.
3. The classes would describe the specific properties of each element.
These are just the first ideas. They may be wrong.
With this scheme, inheritance turns out to be plural at once - element classes (descendants) must include properties of three basic classes at once.
So here goes some reasoning.
"I would create three base classes: "Rectangle_label", which would contain all the basic properties of rectangular labels, "Icon", and "Text"." - Classically, the first object simply call Rectangle or Rect, the second generalized Image, well, the third can either be described by separate properties or also make a separate object. To indicate that the created data type is a class in c++ and in mql it is usual to indicate C before the type name, i.e. CRectangle, CImage, CText. But simple types that just contain heterogeneous data are more convenient to create as structures.
The first thing to consider is all of the basic properties of LARGE controls. Further on you can add any properties, it won't be a problem.
"a) elements that control a parameter. b) elements that are controlled by a parameter." - deciphering is required here. I don't understand what these descriptions mean.
"will there be success in the end" - it is still better to be sure there will be success. Otherwise, it is better not to start.Well here goes some reasoning.
1. "I would create three basic classes: "Rectangle_label", which would contain all the basic properties of rectangular labels, "Icon", and "Text". - Classically, the first object simply call Rectangle or Rect, the second generalized Image, well, the third can either be described by separate properties lobo also make a white object. To indicate a created data type as a class in c++ and in mql, it is customary to indicate C before the type name, i.e. CRectangle, CImage, CText
2. "a) elements that control the parameter. b) elements that are controlled by the parameter." - deciphering is required here. I don't understand what these descriptions mean.
"Will there be success in the end" - it is still better to be sure that there will be success. Otherwise, it is better not to start.1. The most basic class is GHObjest (basic graphical object). There should be x,y, x_size, y_sixe properties and different types of coordinate binding. These are common properties of ALL objects.
2. its descendants are CRec, CImage, CText. They have specific and inherent only properties.
3. Then, there are the window platform classes. There are several of them: Menu window, Options window, Dialog window, Dynamic window. There are a set of specific properties there.
3. Then, there are element classes. There may be up to 50 of them. They are divided into categories: 1) by method of parameter processing, 2) by ornamental method.
This is a good starting point. We need to make a markup language, not a library. What's the point otherwise?
ZS Most of the controls work with the parameter they are given. The essence of their purpose is to control some user parameter. But, each control does it in a different way.
ZSY. I forgot to add - you need a base class of parameter with its properties. CParam for example.
1. The most basic class is the GOBijest (basic graphical object). There should be x,y, x_size, y_sixe properties and different types of coordinate binding. These are common properties of ALL objects.
2. its descendants are CRec, CImage, CText. They have specific and inherent only properties.
3. Then, there are the window platform classes. There are several of them: Menu window, Options window, Dialog window, Dynamic window. There are a set of specific properties there.
3. Then, there are element classes. There may be up to 50 of them. They are divided into categories: 1) by method of parameter processing, 2) by ornamental method.
This is a good starting point. We need to make a markup language, not a library. What's the point otherwise?
ZS Most of the controls work with the parameter they are given. The essence of their purpose is to control some user parameter. But, each element does it differently.
I'm having a bit of a brain-explosion... )) It all needs to be drawn, otherwise you can't digest it. )
I'm having a bit of a brain blast... )) It all needs to be drawn, otherwise you can't digest it. )
)) Nothing...
The CParam parameter base class has several descendants. The point is that there are general properties of controlled item parameters, and there are specific ones. For example: a button has a controlled parameter type bool, while a drop-down list has a "menu" type. That is, a button toggles 1/0, while a list offers a limited selection. The slider, for example, has a parameter type of "range" - that is, range. There are several other types and all have unique properties.
Therefore, classes that are descended from the base parameter class should be as well. Something like "CBool", "CRange", "CMenu".
)) Nothing...
The CParam parameter base class has several descendants. The point is that there are common properties for controlled item parameters, and there are specific ones. For example: a button has a controlled parameter type of bool, while a drop-down list has a "menu" type. That is, a button toggles 1/0, while a list offers a limited selection. The slider, for example, has a parameter type of "range" - that is, range. There are several other types and all have unique properties.
Therefore, classes that are descended from the base parameter class should be as well. Something like "CBool", "CRange", "CMenu".
Wait. Let's try to look at it a little abstractly now.
Peter, from your point of view, what do controls like Button, Text label, Input box, Picture box have in common ?
Wait. Let's try to look at it a little abstractly now.
Peter, from your point of view, what do controls such as Button, Text label, Input box, Picture box have in common?
1. Coordinates, dimensions.
2. Coordinate dependencies, dimension dependencies.
3. a bunch more things depending on the total number of properties in the control functionality. I have 270 properties in my kernel. Most of them are common. But, I have a developed functionality that supports a lot of features. Hence, such a number of properties. We have to start with the simplest properties.
1. Coordinates.
2. Coordinate dependencies.
3. a bunch of other things depending on the total number of properties in the control function. I have 270 properties in my core. Most of them are common. But, I have an advanced functionality that supports a lot of features. Hence, such a number of properties. We have to start with the simplest properties.
Yes, of course with the simplest properties. What primitive objects could the same Text Label consist of? Or what primitive objects could a simple Button consist of?