Making a crowdsourced project on Canvas - page 6
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
There is a fundamental question.
Let's say there are two applications, panels, indicators, on one chart. Should each of them draw on its own canvas or both of them on a common one?
There are questions in both cases.
Now I suggest that we simply draw some canvas. With all elements on it.
Anyway, we won't be able to control the number of such running instances with canvas (or we'll get deep into OS functions for "multi-window interface" on canvas. It may come to this at some point, but not yet).
As a consequence - I propose not to do interactions between kanvas at the level of sending "window events" between them right now.
Also, I can't imagine right now how multiple ex5's would exchange data on the contents of a single shared kanvas.
With the keyboard, everything is more or less clear. There is an event when a key is pressed, there is a code for that key. What more do you want?
Unfortunately there is no completeness to the code. nowadays chart events do not distinguish between A and a
I already wrote on this subject in the SD
By the way, I think it would make life a lot easier in terms of a normal DND by introducing the OnMouseDown event.
CHART_MOUSE_MOVE event in sparam sends state of buttons and keyboard. = left, right, ctrl, shift, alt.
In other words DND is implemented now.
In other words, we can implement DND now.
Yes, I'm aware of that, because I implemented it in my recent project. So now DND can be implemented only through asshole.
First of all for the normal drag and drop it is necessary to enable or disable some chart properties, otherwise the chart is dragged together with canvas, of course in almost any case we should disable them.
Secondly, MouseMove is not bound to an object, like Click, for example, so if there are two objects under the mouse, both will be dragged. In the standard library, this is how it is, by the way.
And it will be so if there is no internal logic, selecting which object to pull.
So, the second problem of MoseDown event seems to be effectively solved.
There is also a third point. MouseMove is a spam event. It should be forced to enable and when enabled, it will be sent to all codes on the chart and may be the cause of good brakes due to the number of messages, so if there is a way not to use it, it's better not to use it.
Oh, there's also a third point. MouseMove is a spam event. It has to be forcefully enabled and when enabled will be sent to all codes in the graph and can cause good lags due to the number of messages, so if there is a way not to use it, it's better not to use it.
Yes, I'm aware of that, because I implemented it in my recent project. So now DND can be implemented only through asshole.
The first, for normal drag and drop we need to disable and enable some chart properties, otherwise the chart is dragged together with canvas, of course in almost any case you have to disable them.
Secondly, MouseMove is not tied to an object, like Click, for example, so if there are two objects under the mouse, both will be pulled. In the standard library, this is how it is, by the way.
And it will be so if there is no internal logic, selecting which object to pull.
So, the second problem of MoseDown event seems to be effectively solved.
There is also a third point. MouseMove is a spam event. It should be forced to enable and when enabled, it will be sent to all codes on the chart and may be the cause of good brakes due to the number of messages, so if there is a way not to use it, it's better not to use it.
You do realise that if we go kanvas - we're on our own. There are no high level events anymore. No mt objects that can receive them
If only mouse movements and button states. i wouldn't call it an asshole )). it's just a low level event.
If there is any lag, it's invisible to the naked eye. In my panel at one time MouseMove was sending out thousands of items, including invisible, then I made smarter sending, but visually it did not add speed.
I can't tell you how fast it's going to be.
Nad thousands of objects don't make a difference in speed.
you do realise that if we go into canvass, we are on our own. There are no high-level events anymore. No mt objects to receive them.
If only mouse movements and button states. i wouldn't call it an ass )). it's just a low level event.
There's also the level of interaction with other code. At least, between several instances of one indicator, for example. You should take it into account.
But yes, all this is clear.
There is also a level of interaction with other codes. For example, between several instances of one indicator. You have to take it into account.
Honestly, I have no idea what kind of interaction you're talking about.
Do several instances of an indicator output on one canvas?