Creating a graphic library from scratch - 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
I'm sure it's not worth doing from scratch.
Very clever people have spent a lot of time and knowledge to make the same standard library or the Anatoli library.
People have invested time and knowledge and it would be foolish not to use it.
We should just take the best, from our point of view, in both and build a new one.
We need to learn from other people's mistakes. We will make our own.)
Only FOR!
The ultimate goal of the library is not clear.
And this is a common problem with all graphics libraries, as far as I can see.
All the projects offered on the forum have to solve one of two problems: either to increase the user's income, or to increase the efficiency of getting the same income.
I don't remember a single project author bothering to show examples illustrating how to solve one of these problems.
The most striking example, I remember in the "Canvas is cool" thread, was the presentation of simply mesmerisingly beautiful graphics... However, how it increased the user's (at least the author's) income, or how it increased the effectiveness of getting it - I never understood.
The same goes for Anatoly's library. Great structure, well thought out, but... I'm sure even the author himself doesn't use all the features of this library. As for the users, I think we can forget about them.
Another example is Peter Konov's project. For people who can't (don't want to) understand OOP it is quite a working solution with good features, but... Again - not a single example showing an increase in revenue generating efficiency.
As I see it, most of these projects are more necessary to nurture conceit of their authors. In general, it is a necessary thing. But, one should not expect any "final goals". It's like expecting my TS League (which is just a collection of all kinds of simple experts) to monitor, profit, grail... Although it is just an indicator of various TS principles working on different symbols.
And this is a common problem with all graphics libraries, as far as I can see.
All the projects offered on the forum have to solve one of two problems: either to increase the user's income, or to increase the efficiency of getting the same income.
I don't remember at least one project author bothered to show examples illustrating how to solve one of these tasks.
In fact, this is a section of the programmers' forum ..... You should not look for financial sense here))) I myself prefer to solve these issues separately from this forum.
The ultimate goal of the library is not clear.
I`ve started with your library, thanks to you, then I`ve refined it a bit, then some more)))) finally changed everything, including rewritten functions of lines, also wide line function from source canvas, removed fake functions, put stub on event. I`ve still not completely abandoned structure W although there`s little left there too. I've added calculation of bar on the left and right by binary search among other elements and also added binary search itself with ability to choose greater or lesser value. Also added ability to build from arrays of any kind (timeseries/common ) And came to conclusion that it is necessary to change the construct))))))
I'm coming full circle.
I understand the hierarchy.
I have to go back to the control again, but there are still some coordinates that I would like to put separately. I would like to put them in a circle. I think the kotrol will go from the coordinates, so it will be truer and greatly simplify the system. Of course, I may be wrong in my arguments - but so far it seems a naive solution.
And kotrol - this is nothing but a basic element of styles - which in theory should be after the coordinates.
Logic - we can have an element without styles, but not without coordinates
This is actually a section of the programmers' forum ..... You should not look for financial sense here))) I prefer to deal with these issues separately from this forum myself.
Very funny.
There's a thread next to it where there are heated battles that "no one will work for free" - you say, "it's not worth looking for financial sense" ???
Very funny.
Next to the topic in which there are heated battles that "no one will work for free" - you say, "do not look for financial sense"?
I'm not even claiming authorship of the library I received.... Let alone its financial component.
I just wanted to know how it should be done - correctly.
If there is a small need, you can even gather the code on the scrapheap.
Although ideally I'd like to make some mini version of this correct one. For minimum code and maximum usefulness.
The ultimate goal of the library is not clear .
Nikolai, welcome.
The ultimate goal is to try and address the shortcomings of the tools that are already in place at the moment.
I suppose that most likely it will be a continuation of development of the standard library in order to improve the ease of connecting it to the projects and to improve the graphical component, leaving the chart objects and move to canvas.
But on the whole, let's not speculate on what the outcome will be.
Nikolai, welcome.
The ultimate goal is to try and address the shortcomings of the tools that are already in place at the moment.
I suppose that most likely it will be a continuation of the development of the standard library in order to improve the ease of connecting it to the projects and to improve the graphical component, leaving the chart objects and the transition to canvas.
But in general, let's not puzzle over what will happen.
Briefly, about engineering :
If you have an urge to improve some "A" by re-designing it, you should specify its critical flaws. Simply list them and explain why it is impossible to eliminate them in the process of A's evolutionary development.
On the other hand, no one forbids it. If you like writing code, write it... You rewrite "A", but in your own way, but it'll be new
I'm coming full circle.
I understand the hierarchy.
I have to make the control once again, but there are still some coordinates that I would like to put separately. I would like to put them in a circle. I think the kotrol will go from the coordinates, so it will be truer and greatly simplify the system. Of course, I may be wrong in my arguments - but so far it seems a naive solution.
And kotrol - this is nothing but a basic element of styles - which in theory should be after the coordinates.
Logic - we can have an element without styles, but not without coordinates.
You don't even need to argue with that, it's true )))
Styles, themes - it's all possible to screw in later, if you initially envisage such an addition. In fact, all this should occur in a basic control and therefore the increase in functionality will also go in this class.
Regarding coordinates, I see two types - absolute coordinates, which are calculated relative to the chart and local coordinates, which are calculated relative to the parent.
If, for example, a form is rendered, its placement in a chart is handled by absolute coordinates. If a button is placed in a form, it must be positioned relative to the container in which it is placed, i.e., relative to the form.
When mouse move events are received, we get the absolute coordinates of the cursor point relative to the chart in the handler. When verifying that the cursor hits the form or any of the elements, we need to compare the absolute coordinate of the cursor with the current position of the element, taking into account its positioning. That is, for a form it will simply be a comparison with its current coordinates and size, but for a button it will be calculating the absolute position of the button in the coordinate system. That is, the X coordinate for comparison will be calculated as follows X = (Parent==null)?X():(X()+Parent.X()), where X() is a class function that returns the X position of the item. However, the check for the presence of the parent itself can be performed within this function itself. As the result, if an element has a parent, then the coordinate will be returned as addition of the parent's coordinate to its own coordinate in the parent. In fact, the number of nested elements can be arbitrary and each of them is positioned relative to the element on which it is located, not relative to the graph, so the absolute coordinate can be calculated recursively.