Gallery of UIs written in MQL - page 55
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 also have the full screen canvas redrawing completely every time I change, but it takes no longer than 50ms...
The most expensive is to draw text. Therefore, in order not to use TextOut every time, I store them in arrays. It turns out much faster.
Yes, TextOut is used. I'll think what can be done with it.
Well, simple arithmetic works here: the sum of the areas of 10 - 17 windows is much larger than the full screen. Agreed. Plus secondary additional drawings necessary to create shadows, icons, frames....
And about TextOut I will check and write. Interesting idea.
I don't understand your simple arithmetic :). In my arithmetic there is no need to draw those pixels that are not visible to the user, and the maximum size of the canvas for drawing is limited by the display size in pixels.
I draw in layers, no matter how many windows, all in one bitmap. There can be as many as a hundred windows. Simple primitives are drawn in a minuscule amount of time. The longest, as I wrote above is texts. But they with the help of TextOut at the first use, and further already from ready arrays.
A plan for future work needs to be approved.
I'll issue an update every week. Saturday or Sunday.
1. In the next release I will release a full version of the engine. I will fix bugs and speed up rendering.
2. The second release will be dedicated to tables. I will restore the basic features.
3. The third release - I will make dynamic tables. I hope to implement them in a week. I will try.
4. Fourth release - dynamic window. I will try to post the finished version.
At this stage, the basic versions of the builder, engine and markup language can be considered complete.
I will definitely open a branch of templates written in KIB-code, where I will post finished windows and groups of elements. With illustrations to make it easier for those who want to build the interface.
And I will try to write tutorial articles so that people can use the full range of possibilities.
In this thread I will continue to post code, pictures and explanatory material as I can. I will be very busy doing the above mentioned work.
I don't understand your simple arithmetic :). In my arithmetic there is no need to render those pixels that are not visible to the user, and the maximum size of the canvas for rendering is limited by the display size in pixels.
I draw in layers, no matter how many windows, all in one bitmap. There can be as many as a hundred windows. Simple primitives are drawn in a minuscule amount of time. The longest, as I wrote above is texts. But they with the help of TextOut at the first use, and further already from ready arrays.
Working with one large canvas has a lot of limitations. I have already thought about this option and even discussed with Nikolay.
Let me explain: you do it because you use the standard Ccanvas class. There are ready-made solutions within the framework of which you work. But I don't use the Ccanvas class. All rendering codes are personal development. That's why I don't stick to the concept - one canvas for EVERYTHING. In my opinion, it is technically inconvenient and inefficient solution in a graphical environment. It's easier to use sets of bitmap objects and attach ready-made resources to them than to have one bitmap and programmatically build the interaction of images on it. It is even hard to imagine. But this is not the main thing.
Imagine how much harder it is to realise the concept of a multi-window GUI if you have only ONE canvas. I wouldn't take on such a task.
But even this is not decisive. The main reason for rejecting the idea of one canvas for all images: when there is only one canvas, moving the interface windows requires redrawing inside the MQL environment. In contrast, if each window occupies its own bitmap object and is moved by the ObjectSetInteger() function, - the redrawing of the moved objects falls on standard functions that work outside the MQL environment. Therefore, it is much faster.
You just have a different development direction in which other solutions work more effectively.
Thank you very much for the tip on TextOut. I will investigate this point.
The template branches are writtenin KIB code that
Yes, for debugging I will implement disconnecting the user program from the engine, if that's what you meant. Probably misunderstood.
Working with one large canvas has a lot of limitations. I have already thought about such an option and even discussed it with Nikolay.
Let me explain: you do it because you use the standard Ccanvas class. There are ready-made solutions within the framework of which you work. But I don't use the Ccanvas class. All rendering codes are written by personal development. So I don't stick to the concept - one canvas for EVERYTHING. In my opinion, it is technically inconvenient and inefficient solution in a graphical environment. It is easier to use sets of bitmap objects and attach ready-made resources to them, than to have one bitmap and programmatically build the interaction of images on it. It is even hard to imagine. But this is not the main thing.
Imagine how much harder it is to realise the concept of a multi-window GUI if you have only ONE canvas. I would not take on such a task.
But even this is not decisive. The main reason for rejecting the idea of one canvas for all images: when there is only one canvas, moving the interface windows requires redrawing inside the MQL environment. In contrast, if each window occupies its own bitmap object and is moved by ObjectSetInteger(), - the redrawing when moving falls on standard functions that work outside the MQL environment. Therefore, it is much faster.
You just have a slightly different development direction in which other solutions work more efficiently.
Thank you very much for the tip on TextOut. I will investigate this point.
I'm just NOT using the standard kanvas :).
And I just found it easier to implement a multi-window interface on one bitmap. But to each his own!
And in practice it seems to be faster to redraw the whole canvas than to use ObjectSetInteger, etc....
I am just NOT using the stock canvas :).
And I just found it easier to implement a multi-window interface on one bitmap. But to each his own!
Alas, not in all cases. For my tasks it is technically easier to work with a limited set of bitmaps. And 100% faster. Much faster.
But, for other developments other solutions work better, and so yes - to each his own. :)