Making a crowdsourced project on Canvas - page 36
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
Any element of a dialogue (form, control (button, list, picture)) has some properties. Procedural programming does not define the concept of "property" or "field". In procedural programming, we have functions and variables (global or local). But variables are common to, so they cannot be used to describe the properties of each individual control. Then what is the solution? A simple one - structures!
Yes, a structure can have a description of necessary properties of a control, as well as an array of nested (up to infinity) controls.
All this stuff is stored in an array of dialog boxes.
We can make it more universal: the control description structure consists of two arrays: properties array and slave element array. A property array is an array of structures of a property-value pair. With this approach, each new control can have any arbitrary set of properties. But this is not convenient for processing. It would be more logical to specify specific properties of the control in the structure: dimensions, location, colour, frame, and so on and so forth - everything that any control needs.
And the structure will also contain an array of pixels of the control.
When a mouse event is received, all arrays are looped around to check if the cursor hits a particular control. The check is performed from the last to the first control.
Once it is determined which control has the cursor then the given array element is sent to the repaint function and then the resource array is updated and the image on the chart is updated.
I don't know what he has posted and what he has done in GUI matters, but in my threads he has made no technical suggestions, no solutions and no discussions on the subject. Only empty trolling, pointing out third party solutions and urging not to reinvent the wheel.
Back to the topic at hand.
As far as I'm familiar with the standard library (very little actually), there elements and windows are composed of MT objects. That is, in our context - they are not drawn on the canvas. Of course they are drawn, but not on our canvas, which prevents us from controlling pixel colours, creating surface gradients and more.
In theory, we could take the library structure, copy and make an analog on the kanvas. In theory...
The problem is that CCanvas itself is not suitable for making a GUI on it. Why? Because the kanvas system is used mainly for graphic primitives. So, in essence, this class does not provide anything but primitives. The GUI archetype has to be built by yourself. And in this case, the class isn't necessary. It's more convenient to make do with your own solutions. After all, you can draw a rectangular marker without the class. Just like you can create or load a canvas. It is very simple. Therefore, I preferred my own solution.
But someone cannot do without CCanvas. That's why I don't insist on it.
The problem with CCanvas is that its GUI is strictly tied to the chart window.
That is, you can't make a full-fledged window as a terminal interface module.
And it would be very cool to write your own interface modules.
slightly wrong of course :-)
I posted an interface to the Tcl DLL (which is Tool Common Language), which has Tk graphics that are shared as a GUI in Python/Ruby/etc
the goal was not to get a GUI, but a nice byproduct :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
in my opinion convenient and most importantly short :-)
I am not agitating anyone - I know tcl/tk, I use it, I share my experience (see sourceforge atcl)
Yes Max, that's exactly what I'm talking about TCL and your prototype that we were discussing at the time. The limitation there was that the user had to have the appropriate library installed on his computer. It didn't seem to be difficult, but it's still a certain limitation.
Let's leave that in the past. Max, join us in the discussion. Roman, join in too ))).
From the above it can be understood that a structure element is a specific dialog control, it contains its own properties and can contain nested controls. The set of properties of such a universal control is limited only by the developer's imagination.
Of course, we can avoid the structure and describe the properties of controls in a multidimensional array, but it's not initially cost-effective because we need to clearly remember which index of the control stores any property. And the array cannot contain heterogeneous data types. It turns out that the description of the control element in the procedural programming is only possible through the structures. That is, the structure element is a concrete control, i.e. the concrete object of the dialog with its properties.
The problem with CCanvas is that its GUI is strictly tied to the chart window.
That is, you can't make a full-fledged window as a terminal interface module.
And it would be very cool to write your own interface modules.
Then there will be the reverse - linking the interface to the chart. For example, to make a button that is strictly linked to the time and price.
A separate GUI can be written in no time - with all tables, tabs, menus and whistles. In C# or even BASIC. And inside the chart is a significant problem for external applications.
Any element of a dialogue (form, control (button, list, picture)) has some properties. Procedural programming does not define the concept of "property" or "field". In procedural programming, we have functions and variables (global or local). But variables are common to, so they cannot be used to describe the properties of each individual control. Then what is the solution? A simple one - structures!
Yes, a structure can have a description of necessary properties of a control, as well as an array of nested (up to infinity) controls.
All this stuff is stored in an array of dialog boxes.
We can make it more universal: the control description structure consists of two arrays: properties array and slave element array. A property array is an array of structures of a property-value pair. With this approach, each new control can have any arbitrary set of properties. But this is not convenient for processing. It would be more logical to specify specific properties of the control in the structure: dimensions, location, colour, frame, and so on and so forth - everything that any control needs.
And the structure will also contain an array of pixels of the control.
When a mouse event is received, all arrays are looped around to check if the cursor hits a particular control. The check is performed from the last to the first control.
Once it is determined which control has the cursor then the element in the array sends to the repaint function and then updates the resource array and updates the picture on the chart.
1. Suppose you have designed a simple structure of basic controls - a window, a button, a checkbox. Each one consists of a set of components - objects. Checkbox - base, text, icon. Button - base, text, icon, and so on. Each object of each element must have its own set of properties. You can write them in a structure or class, but in my opinion, it is not convenient. Why? - Because when you put them in a window, you need to find them on the canvas with cursor. When you move the cursor, they have to come into focus. For this, their current coordinates must be in an array. And it is more convenient if all their properties (including current coordinates) are in the same array. In this way you can immediately access any property of any element on the canvas which is the focus of the cursor. It's also easier to loop through an array of items.
That is, it's easier to traverse ONE array in a loop to find the element the cursor has hit. It is even more convenient if this array is global. Then, in any function, you can take the necessary information from it and change the values of the necessary properties, of the necessary elements.
This is the shortest and most efficient access to elements and their fastest processing. This is my "core".
2. However, knowing the whims of professionals to strive for maximum imitation of standard OOP, I do not propose this technology.
3. an array of pixels doesn't need to be stored anywhere. It is built at the moment of necessity, according to the parameters of the elements in the array. For example: you need to redraw the window. We call the repaint function. The function calls the array of elements, sees all its properties, declares the array of pixels, calculates its size, draws its objects successively in the loop, calls ResourceCreate(). That's it.
An element caught under the cursor is sent to the same function for redrawing. It receives a notification (repaint flag) and its number in the item array. Next, the function calls the required resource via ResourceReadImage(), puts it into the pixel array and then, inside the pixel array, finds the area of the required element and repaints all its objects. That's it.
1. Suppose you have designed a simple structure of basic controls - a window, a button, a checkbox. Each consists of a set of constituent parts - objects. Checkbox - base, text, icon. Button - base, text, icon, and so on. Each object of each element must have its own set of properties. You can write them in a structure or class, but in my opinion, it is not convenient. Why? - Because when you put them in a window, you need to find them on the canvas with cursor. When you move the cursor, they have to be in focus. For that, their current coordinates have to be in an array. And it is more convenient if all their properties (including current coordinates) are in the same array. In this way you can immediately access any property of any element on the canvas which is the focus of the cursor. It's also easier to loop through an array of items.
That is, it's easier to traverse ONE array in a loop to find the element the cursor has hit. It is even more convenient if this array is global. Then, in any function, you can take the necessary information from it and change the values of the necessary properties, of the necessary elements.
This is the shortest and most efficient access to elements and their fastest processing. This is my "core".
2. However, knowing the whims of professionals to strive for maximum imitation of standard OOP, I do not propose this technology.
3. an array of pixels doesn't need to be stored anywhere. It is built at the moment of necessity, according to the parameters of the elements in the array. For example: you need to redraw the window. We call the repaint function. The function calls the array of elements, sees all its properties, declares the array of pixels, calculates its size, draws its objects successively in the loop, calls ResourceCreate(). That's it.
An element caught under the cursor is sent to the same function for repainting. It receives a notification (repaint flag) and its number in the item array. Next, the function calls the required resource via ResourceReadImage(), puts it into the pixel array and then, inside the pixel array, finds the area of the required element and repaints all its objects. That's it.
Actually, this should work regardless of the construction technology. But it can be perceived differently. In your case, you pass an array in the loop and determine which control has the cursor at that moment. Thus, when you define the index you immediately see the properties of the found item. But how can you store different types of data in one big array?
Actually, this should happen irrespective of the construction technology. You can only perceive it in different ways. In your case, you loop through the array and determine which control has the cursor at the moment. Thus, when you define the index you immediately see the properties of the found item. But how can you store different types of data in one big array?
In principle, it is possible to generalize the types. I've come to the conclusion that nothing bad will happen, if the vast majority of object properties are of type int. All other (double is practically absent in properties of graphical objects) abbreviated types I've disregarded for the sake of simplification. The memory "overrun" is so insignificant that there's no sense in thinking about it. Of course, we cannot go for such a sacrilege for the sake of professionalism))). But this is the 21st century and I'm not threatened by bonfires).
I made the names of objects as numbers, and put them in the general series of properties of objects.
The only place where I needed a different type of data was control parameters. There I created a second kernel, which stores the parameters properties, and the values themselves in the string type, which I can easily cast to anything (or rather, to what is prescribed in the parameter properties).
HINT: By "control element parameter" you mean the PARAMETER MANAGED BY THE EQUIPMENT.1. Suppose you have designed a simple structure of basic controls - a window, a button, a checkbox. Each consists of a set of constituent parts - objects. Checkbox - base, text, icon. Button - base, text, icon, and so on. Each object of each element must have its own set of properties. You can write them in a structure or class, but in my opinion, it is not convenient. Why? - Because when you put them in a window, you need to find them on the canvas with cursor. When you move the cursor, they have to come into focus. For this, their current coordinates must be in an array. And it is more convenient if all their properties (including current coordinates) are in the same array. In this way you can immediately access any property of any element on the canvas which is the focus of the cursor. It's also easier to loop through an array of items.
That is, it's easier to traverse ONE array in a loop to find the element the cursor has hit. It is even more convenient if this array is global. Then, in any function, you can take the necessary information from it and change the values of the necessary properties, of the necessary elements.
This is the shortest and most efficient access to elements and their fastest processing. This is my "core".
2. However, knowing the whims of professionals to strive for maximum imitation of standard OOP, I do not propose this technology.
3. an array of pixels doesn't need to be stored anywhere. It is built at the moment of necessity, according to the parameters of the elements in the array. For example: you need to redraw the window. We call the repaint function. The function calls the array of elements, sees all its properties, declares the array of pixels, calculates its size, draws its objects successively in the loop, calls ResourceCreate(). That's it.
An element caught under the cursor is sent to the same function for repainting. It receives a notification (repaint flag) and its number in the item array. Then the function calls the required resource via ResourceReadImage(), puts it into the pixel array, and further, within the pixel array, finds the area of the required element and repaints all its objects. That's it.
ugh this eternal negativity to oop, right across the line
Have you ever wondered how it came about? The point is that many people who write in procedural style and don't know about OOP face the desire to group functions, and then this desire develops into a desire to combine these functions into one memory area and refer to it, i.e. physically refer to the area with functions that is stored in a variable. Then we want to change our selected bunch of functions without duplicating code (we get inheritance). So a person who is initially familiar only with the procedural style some time later asks why there are so many restrictions in a mql (reference to multiple inheritance).
In general, it is believed that it is easier to teach OOP at once, because if a person is familiar with procedural style, it will be very hard to retrain later (for most people), but there are others, since initially there was only procedural style... described above.
ZS There's a variation on OOP in general, kind of familiar with OOP at the procedural code level, and really using OOP to its fullest.
A class is a reference to a memory (table) of functions, which can be rewritten and extended while keeping the main array + reference to variables. and I forget what else.... (like 32 bytes)
With search eternal problem, I've recently compared built-in sort function with Red sort (one of the template sort), speed loss by 3-6 times in certain conditions (built-in lost =)
On GUI I think there are standard methods.
,
Ugh, this eternal negativity towards the OOP, right across the line.
Have you ever wondered how it came about? The matter is that many people who write in procedural style and not knowing about OOP face the desire to group functions, then this desire grows into a desire to combine these functions into one memory area and refer to it, i.e. physically refer to the area with functions that is stored in a variable. Then we want to change our selected bunch of functions without duplicating code (we get inheritance). So a person who is initially familiar only with the procedural style some time later asks why there are so many restrictions in a mql (reference to multiple inheritance).
In general, it is believed that it is easier to teach OOP at once, because if a person gets acquainted with procedural style then it will be very hard to retrain (for most people), but there are others, since initially there was only procedural style... described above.
ZS There's a variation on OOP in general, kind of familiar with OOP at the procedural code level, and really using OOP to its fullest.
A class is a reference to a memory (table) of functions, which can be rewritten and extended while keeping the main array + reference to variables. and I forget what else.... (like 32 bytes)
With search eternal problem, I've recently compared built-in sort function with Red sort (one of the templates), speed loss by 3-6 times in certain conditions (built-in lost =)
On GUI I think there are standard methods.
,
I don't have any negativity to the concept of OOP. I'm an adherent of it myself. I have a negative to standards. To be more precise, to mindlessly following them).
Aside from that, I'm for OOP. But I'm for simplified OOP.