Discussion of article "MQL5 Cookbook: Indicator Subwindow Controls - Buttons"

[MetaQuotes]

New article MQL5 Cookbook: Indicator Subwindow Controls - Buttons has been published:

In this article, we will consider an example of developing a user interface with button controls. To convey the idea of interactivity to the user, buttons will change their colors when the cursor hovers over them. With the cursor being over a button, the button color will be slightly darkened, getting significantly darker when the button is clicked. Furthermore, we will add tooltips to each button, thus creating an intuitive interface.

The article will also cover some events: mouse move event, state of the left mouse button, left-click on an object and the event of modifying chart properties. We are going to create a button panel that will take up the entire space of the indicator subwindow. For illustrative purposes, the buttons will be arranged in three rows, with four buttons in each row.

Author: Anatoli Kazharski

[Vasiliy Sokolov]

Good article for beginners. However, in more complex interfaces this approach is no longer acceptable. The first thing that catches your eye:

for(int i=0; i<BUTTON_COLUMNS; i++)
     {
      for(int j=0; j<BUTTON_ROWS; j++)
        {
            ...
      ...
...

I.e. a rigid table structure is sewn into the algorithm and this construction is found in almost all functions. Now let's imagine that the subwindow contains several graphic elements that are not related to the table in any way. For them we will have to describe their own positioning model, and this is not good. The positioning model should be one and universal, i.e. in this case, the "table" layout should be a special case of this model.

[Anatoli Kazharski]

C-4:

Good article for beginners. However, in more complex interfaces this approach is no longer acceptable. The first thing that catches your eye:

I.e. a rigid table structure is sewn into the algorithm and this construction is found in almost all functions. Now let's imagine that the subwindow contains several graphic elements that are not related to the table in any way. For them we will have to describe their own positioning model, and this is not good. The positioning model should be one and universal, i.e. in this case, the "table" layout should be a special case of this model.

Yes, you are right. I'll try to come up with something more original next time. )

In this case, to get away from the special case, it is enough to use a one-dimensional array and one loop.

[Andrey Khatimlianskii]

I don't understand why you should use OBJ_EDIT.

It would have been much more useful to "revive" the standard buttons from the library (so that they would also glow under the mouse).

I.e. it seems to be a useful article, but I don't understand why such a way was chosen.

ps: I envy the author's fruitfulness ;)

[Anatoli Kazharski]

komposter:

...

I'm used to using OBJ_EDIT already, as it is displayed during visualisation in the tester.

In this case, you could use any object for the example. It's a creative process, after all. )

[Vasiliy Sokolov]

komposter:

I don't understand why you should use OBJ_EDIT.

It would be much more useful to "revive" the standard buttons from the library (so that they also glow under the mouse).

I.e. it seems to be a useful article, but I don't understand why such a way was chosen.

ps: I envy the author's fruitfulness ;)

In reality, standard buttons are very slippery control element, because in the first place does not support frame colour (although it is very strange why), and in the second place, depending on the type of frame BORDER_FLAT, BORDER_RAISED visually positioned clearly outside its location, I'm not saying that in addition to this change their shade depending on the state of pressing and very slow to change its display without ChartRedraw. In reality, the button except for its chopped interface a la Windows 3.11 does not give any advantages compared to other elements. Yes, there is a special field OBJ_SELECTED, indicating whether the button is pressed or not, but in reality there are no problems to create your own object OBJ_EDIT, containing the flag of pressing.

[Vasiliy Smirnov]

And the buttons aren't buttons at all).

[Vasiliy Sokolov]

komposter:

It would be much more useful to "animate" standard buttons from the library (so that they would also glow under the mouse).

And I wonder, is there a single professional developer who would use the standard library of graphic elements in his products?

[Anatoli Kazharski]

zfs:
And buttons aren't really buttons at all).

A button is anything you can push. ))

[Anatoli Kazharski]

C-4:
And I wonder, is there any professional developer who would use the standard library of graphic elements in his products?

I think there are products in the Market with interfaces whose elements resemble those used in the standard library.

[Sergey Pavlov]

I wonder, when you were preparing the material - did you read this article?