Making a crowdsourced project on Canvas - page 4
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
It seems to me that after Anatoly's articles, it's at least a strange pastime to create the same eggs in profile again. Graphics is not a hot topic for MT at all.
- Users don't need graphical interfaces. As a consequence, it's impossible to monitor GUI and its development will never pay off.
- If you want to raise the skills, it is better to immediately get a job somewhere junior. So at least you will start making some money right away and raise your skills slowly.
- Too narrow a target audience. Who needs libraries? - Absolutely no one, except for a handful of programmers, and they have long since written all the libraries they need. For example I have two graphics libraries of my own.
I do not want to teach those present here, but I can give some advice: guys, smell the powder. Learn how to work with users. Learn their psychology. Learn how to monitor their ideas. Then quickly come down to earth and you will reason in a completely different way. I, too, once believed in some special and beautiful ideas, but all this nonsense, it does not work. What you are discussing here is of no use to anyone but you.+1
For most of so-called traders, they don't need beauty, they need money, or, at least, EAs with hyper super technologies of price calculation in the third phase of the moon, because it sounds nice and allows to brag and have hope for miracle technologies...
But some people do not need those who work only in a demo or in the real market with fairy lights :))).
Vladimir Pastushak:
And Bibles that only work in the demo or in real life with beauties few people need, or rather need who little balo need)))
Once again, we don't make bibbles.
We are solving a problem.
This thread is not about measuring, it is about solving real problems.
Vladimir, you can either observe without any negative comments or join us. But you will not be taught about OOP or phases of the moon in this thread.
Again, we don't make bibles.
We are solving a problem.
This thread is not for measuring, but for solving specific problems.
Vladimir, you can either watch without negative comments or join me. But you will not be taught about OOP or phases of the moon in this thread.
I can't join as I don't speak OOP to the fullest extent.
I just tried to save you time.
I'm going over to the side of observers...
The problem with the input field is that there's no good idea how to use what's available.
IMHO now, you can make full-fledged EDIT only if you draw your own GUI keyboard, but it will be hard to support languages, and it's inconvenient to type with mouse...
What extra features do you need to work with events or charts so that nothing gets in the way of input?
we'll ask for a refinement in the SD.
I for one don't understand such things at all :
Show me in the documentation or somewhere else where I can learn and understand where to apply this and how to understand it at all...
... Graphics are not a hot topic at all for MT ...
So it's not just about graphics. What's on offer here will give you the ability to create graphical interfaces of the highest quality. Being limited to the primitives of standard graphic objects, you come to the fact that a lot is missing. In addition, you have to operate with a very large number of graphical objects, which can be a nuisance in some cases.
Some spend their time on some entertainment or games, and there are people for whom entertainment is the solution of some interesting and useful tasks. Many people in this forum burn their time just for idle chatter.
I would be glad to take part in this forum but I've got my own tasks to do now. )
using as few graphical objects as possible
not just fewer, but none at all (except for bitmap_label which is used to draw everything)
How would a slider work, for example, if it was completely drawn? It requires at least two interacting objects...
are you talking about the mouse on the slider?
----
At the moment, there's only one problem so far, which Zorro wrote about - the input field.
Chart events don't give all the key codes. Also chart intercepts spacebar and enter.
not just smaller, but none at all (except bitmap_label, which is where everything is drawn).
are you talking about the mouse pressed on the slider?
----
At the moment, there's only one problem, which Zorro wrote about - input field.
Chart events don't give all the key codes. Also chart intercepts spacebar and enter.
Not really about the mouse.
I basically don't understand the mechanism of the "slider" control, which is completely drawn.
The main function of the slider is to convert the distance between two points, A and B, into the value of a custom parameter using a given proportion and step.
In my implementation, points A and B are represented by the location of two objects - the X coordinate of the slider track (its origin) and the X coordinate of the slider slide. The function measures the distance between the two points and converts it into a parameter value.
If both objects are merged in the picture, how will point A and point B be located? In this case, these points will just be pixels of the image.
How will the pixels return their coordinates to measure the distance between the points?
How will the image change as the slider is moved?
How will the slider's exact position (relative to its x-coordinate) be returned and its stroke limits fixed?
And how will I correct the position of the slider when it leaves the stroke boundaries?
All these mechanisms work in my implementation of the slider, and I do not understand the proposed technology, although I understand that you can significantly reduce the number of objects in this way.