Making a crowdsourced project on Canvas - page 14
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
ElementSet, where you have to specify (1) property and value or (2) property, modifier and value.
Yes, it's universal in terms of accessing control properties.
Generally PropGet/Set is a good mechanism for handling template classes when inherited interface is initially unknown.
But I want to bring the discussion back to my original question - how can I make a "quick start" for a programmer on the colour scheme of controls?
And is it possible to implement not a functional (SetBgColor or SetProp(Enum_Color, ), etc.), but a more universal class of attributes.
So that all the controllers would access one universal class of attributes and the coder could easily understand which colour is used by which controller.
But all this is my reasoning concerning my scheme. I don't exclude that it will still very much change when I'll start transitioning. So everything I wrote above may no longer be relevant to the topic under discussion here. )
In principle I agree, it will be clear what colours it has and what can be changed.
is there a question then - does Theme imply redundancy of unused parameters?
Yes, it is redundant, for all variants. But then it is convenient to create a new theme by repainting and changing values in the previous one. Just like themes in Windows.
P.S.
And I'm skeptical about mass changes of some values by the coder different from those used in the current theme. It reminds me of a Delphi project where the first thing you try to do is paint the interface in your own colours which subsequently doesn't change when changing the system theme.
And why smudge the design styles somewhere? Inherit a theme class from one of the existing themes and redraw only those values in it that need to be changed.
there is this CSS technology
1) known and well documented
2) familiar and versatile
3) tags==controls in principle, which makes it suitable for our task
try it, it should work as intended.
there is a CSS technology
Then go straight to LESS / SCSS (SASS)
Then go straight to LESS / SCSS (SASS)
ugh, Lass is probably good, but we don't need its functionality. we're not making an interpreter.
We take purely the principle of building and redefining styles in cascade^selective^pointwise - the way they do it.
And be sure to include a responsive design option for different resolutions. See Media Queries in CSS
And some parts may be fixed in size, while others may stretch as far as they can.
Dear forum members, I have no desire to demotivate anyone, but in my opinion, the technology under discussion is so complex that it cannot be implemented by joint dispersed efforts. We cannot combine these efforts effectively as we all differ in levels of understanding, professionalism and approaches... We are also separated by distances and even countries.
My conclusion is that this technology can be implemented by a single developer who has worked long and hard on it. Maybe more than a year. But this person is unlikely to crowdsource this technology because he put in too much effort, too much soul, and simply exhausted himself with this work... It's his project and he has the right not to distribute it freely. (Maybe in the beginning, but not always).
I think this technology has already been implemented in MQL.
P.S. Although, even if it is - why not try to implement it again? ))
Why it might be useful:
1. the interface on the bitmap is fast. So fast that it is virtually indistinguishable from the system interface. For example, I've implemented translucent elements with gradients, andeven when they move, they are smoothly rendered without any visible delay, taking into account the colour mixing and alpha channel calculation on other objects with translucent gradients.
2. The interface is scalable. You can make the application more complex and it won't slow down due to deletion and creation of a large number of graph objects. Redrawing costs are minimal, it's just replacing a picture, in thousandths of a second.
3. You can create ready-made controls and provide an opportunity to create new ones, because you can provide your own event pool, for example:
OnMouseDown - pressed the LKM
OnMouseUp - pressed the mouse button
OnMouseHoverOn - hovering mouse cursor over an object
OnMouseHoverOut - moves mouse cursor away from object
OnMouseClick - press and click within the object boundaries
OnMouseDblClick - double mouse click within the bounds of the object
OnDragStart - event that occurs once at the beginning of movement with pressed left mouse button
OnDragMove - event generated during movement with the left mouse button
OnDragEnd - event generated after moving with LKM
OnPut - object is cast to another object
OnGet - object is dumped to another object
OnFocus - object got focus
OnBlur - object loses focus
OnResize - object has changed size
OnParentResize - the parent object has changed size
OnKeyPress - key pressed
OnChange - value of a field changed
etc.
You're exaggerating a bit in the following:
The speed at which a bitmap is drawn depends on its size. If you redraw the whole bitmap representing the window when you redraw the part, the response will be slow (verified). The obvious solution is to have only the area of the bitmap repainted.
However, to redraw only part of the bitmap pattern representing a window, you need to store the digital mask of the bitmap in memory (in an array). Next, you need to navigate within this mask, and find the desired pattern within it. However, take into account that there may be many windows. Now evaluate the amount of memory needed to store the masks of all the windows. You could come up with a priority system to choose which windows to remember and which to "forget", and when. However, it's not an easy thing to do.
You have to understand, redrawing is rewriting values in an array, and if you need to rewrite 1000000 values (approximate number of pixels in the window image and in the bitmap), it will not be "thousandths of seconds", but seconds. Therefore, you should draw a window completely only once, save it in memory and then, at events, redraw each object separately. Then the speed will be very high.
Apparently, you have implemented only separate objects, but try to create a window and implement interactivity of its elements there. You will understand what I mean.
As for the events you cited, their implementation in the program is not connected with the technology of drawing controls and should be present in any interface.
...
Apparently you've only implemented individual objects, but try creating a window and implement the interactivity of your elements there. You'll see what I mean.
...
You are slightly exaggerating the following:
The bitmap drawing speed depends on its size. If you repaint the whole bitmap representing a window, the response will be slow (tested). The obvious solution is to have only the area of the part to be repainted.
However, to redraw only part of a bitmap drawing representing a window, you need to have a digital mask of that bitmap stored in memory (in an array). Next, you need to navigate within this mask, and find the part you want in it. However, take into account that there may be many windows. Now evaluate the amount of memory needed to store the masks of all the windows. You could come up with a priority system to choose which windows to remember and which to "forget", and when. However, this is not an easy task.
You have to understand, redrawing is rewriting values in an array, and if you want to rewrite 1000000 values (approximate number of pixels in the window image and in the bitmap), it will be seconds, not "thousandths of a second". Therefore, you should draw a window completely only once, save it in memory and then, at events, redraw each object separately. Then the speed will be very high.
You have probably implemented only single objects, but try to create a window and implement interactivity of your elements there. You will understand what I am talking about.
As for the events you cited, their implementation in the program is not related to the technology of drawing controls and must be present in any interface.
I want to make a little clarification:
First we create a digital mask of the window with all its elements. Then we create a bitmap with ResourceCreate(). We get our window on the chart.
Then we move the mouse over the interface of this window and catch, for example, the pointing event (_Object_Pointed).
I will describe two approaches of object interactivity implementation - one bad, the other - better:
1. If the digital mask of our window was not saved in the array after it was first created, then in order to change any detail of the drawing of that window, we need to recreate it completely. That is, you have to re-digitize it. This in itself takes time because you need to initialize the array with the pixel colour values of all the window's details in order to pass it to ResourceCreate(). The bigger the window and the more details it contains, the longer it will take (about 250 milliseconds to 2 seconds). And so, on every event of every element. This option is too defective.
2. If a numeric mask has been stored in an array, we only need to re-initialise those values that relate to a specific part of that window. We find that part in the array and rewrite its values. Next, - we send the array to ResourceCreate() and immediately get the result.
That's actually the whole technology. Almost))