I suggest adding mouse button status. It won't affect speed, but it can be useful )
struct Window
{
long ChartId; // current window identifieruint Color; // window background colourint Width; // window widthint Height; // window heightint height[]; // sub_windows heightint Left_bar; // number of the leftmost bar in the windowdouble Right_bar; // number of the rightmost bar in the windowdouble Total_bars; // the maximum number of bars in the windowint BarsInWind; // number of visible bars in the windowdouble Y_min; // The minimum value of the price in the windowdouble Y_max; // The maximum value of the price in the windowdouble dy_pix; // price change for one pixelint dx_pix; // changing the number of bars per pixelint MouseX; // coordinate X of the current position of the mouse pointerint MouseY; // coordinate Y of the current position of the mouse pointerint MouseStatus; // mouse buttons statusdouble MouseBar; // the current bar position of the mouse pointer double MousePrice; // the current price of the mouse pointerdatetime MouseTime; // the current time of the mouse pointerint MouseSubWin; // number of the subwindow in which the mouse pointer is locatedint WindowsTotal;// total subwindows, including the main windowint SubWin; // current subwindowdatetime time[]; // array of opening time of all visible bars in the window
};
I suggest adding mouse button status. It won't affect speed, but it can be useful )
I can't agree, as I don't see much sense in it.
The point is that the status of mouse buttons and keys is an event model, which should be processed only where the occurrence of this event is caught, namely in OnChartEvent. You are not going to limit an infinite loop of polling the occurrence of some event outside the event handler. So what is the point of putting this status outside OnChartEvent, when all the processing of these clicks should be done in OnChartEvent, the status of which is in lparam and sparam.
Except for the purpose of introducing a new structure of mouse event identifiers to improve code readability.
The point is that the status of mouse buttons and keys is an event model, which should be handled only where the occurrence of this event is caught, namely in OnChartEvent. You are not going to limit an infinite loop of polling the occurrence of some event outside the event handler. So what is the point of putting this status outside OnChartEvent, when all the processing of these clicks should be done in OnChartEvent, the status of which is in lparam and sparam.
Except for the purpose of introducing a new structure of mouse event identifiers to improve code readability.
And why store mouse coordinates then? ) Also event-driven )
I didn't understand about the loop...
In particular, I needed the status to avoid drawing a part of the object when dragging with the mouse.
Why store mouse coordinates then? ) Also event-driven )
Mouse coordinates are a different matter. Current mouse coordinates are not event information. The event is their change.
There may be times when mouse coordinates are needed outside OnChartEvent. For example, here.
Oleksii Chepurnyi:
I didn't understand about the loop...
In particular, the status was needed to avoid drawing a part of the object when dragging with the mouse.
Well, when dragging the mouse, the command to redraw part of the object is called from OnChartEvent at the moment when the mouse coordinate changes and while the mouse is pressed, and OnChartEvent has this status, why embed it in the Window structure?
If you would do the same thing not from OnChartEvent, and at the same time in the instance W of the Window structure there would be MouseStatus, you would have to organise an endless loop of polling of this parameter (MouseStatus) to catch the moment of releasing the mouse button, which would hang the CPU.
This loop is not necessary only in OnChartEvent.
I just want to say that you can and should use the button status only from OnChartEvent, where it is already present.
If I'm wrong, please give me a concrete example where this status would be required not from OnChartEvent.
If I'm wrong, please provide a concrete example where this status would be demanded from something other than OnChartEvent.
I wrote an example above, everything works fine )
In OnChartEvent when moving the mouse we change the parameters and give the command to redraw the canvas. Without a parameter in the structure we would have to pass sparam to an object, from there to another object, and there to the Draw() method.
The mouse coordinates are a different matter. Current mouse coordinates are not event information. The event is their change.
There may be times when mouse coordinates are needed outside OnChartEvent. For example, here.
Well, when you drag the mouse, the command to redraw a part of the object is called from OnChartEvent at the moment when the mouse coordinate changes and while the mouse button is pressed, and OnChartEvent has this status, why embed it in the Window structure?
If you would do the same thing not from OnChartEvent, and at the same time in the instance W of the Window structure there would be MouseStatus, you would have to organise an endless loop of polling of this parameter (MouseStatus) to catch the moment of releasing the mouse button, which would hang the CPU.
This loop is not needed only in OnChartEvent.
I just want to say that you can and should use the button status only from OnChartEvent, which already has it.
If I'm wrong, then give me a concrete example where this status would be required not from OnChartEvent.
Very strange reasoning. There is no logic at all.
Both mouse coordinates and pressed keys are external states. It is passed through parameters to the handler, where if it is put into the internal variables of the object (which is certainly useful), it should be there as a whole, not in parts. A library is by definition something that is made not for one's own needs, but in a generalised form, taking into account the potential needs of others. You can't know all the needs in advance, so you just don't make artificial restrictions like this.
In OnChartEvent when moving the mouse we change the parameters and give the command to redraw the canvas. Without a parameter in the structure we would have to pass sparam to an object, from there to another object, and there to the Draw() method.
This is a classic of the genre - in all window libraries, the states of mouse buttons are passed in a single structure with the cursor coordinates.
because they all together describe one entity and cannot be separately at all.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
I suggest adding mouse button status. It won't affect speed, but it can be useful )
I suggest adding mouse button status. It won't affect speed, but it can be useful )
I can't agree, as I don't see much sense in it.
The point is that the status of mouse buttons and keys is an event model, which should be processed only where the occurrence of this event is caught, namely in OnChartEvent.
You are not going to limit an infinite loop of polling the occurrence of some event outside the event handler. So what is the point of putting this status outside OnChartEvent, when all the processing of these clicks should be done in OnChartEvent, the status of which is in lparam and sparam.
Except for the purpose of introducing a new structure of mouse event identifiers to improve code readability.
I can't agree as I don't see much point in it.
The point is that the status of mouse buttons and keys is an event model, which should be handled only where the occurrence of this event is caught, namely in OnChartEvent.
You are not going to limit an infinite loop of polling the occurrence of some event outside the event handler. So what is the point of putting this status outside OnChartEvent, when all the processing of these clicks should be done in OnChartEvent, the status of which is in lparam and sparam.
Except for the purpose of introducing a new structure of mouse event identifiers to improve code readability.
And why store mouse coordinates then? ) Also event-driven )
I didn't understand about the loop...
In particular, I needed the status to avoid drawing a part of the object when dragging with the mouse.
Why store mouse coordinates then? ) Also event-driven )
Mouse coordinates are a different matter. Current mouse coordinates are not event information. The event is their change.
There may be times when mouse coordinates are needed outside OnChartEvent. For example, here.
I didn't understand about the loop...
In particular, the status was needed to avoid drawing a part of the object when dragging with the mouse.
Well, when dragging the mouse, the command to redraw part of the object is called from OnChartEvent at the moment when the mouse coordinate changes and while the mouse is pressed, and OnChartEvent has this status, why embed it in the Window structure?
If you would do the same thing not from OnChartEvent, and at the same time in the instance W of the Window structure there would be MouseStatus, you would have to organise an endless loop of polling of this parameter (MouseStatus) to catch the moment of releasing the mouse button, which would hang the CPU.
This loop is not necessary only in OnChartEvent.
I just want to say that you can and should use the button status only from OnChartEvent, where it is already present.
If I'm wrong, please give me a concrete example where this status would be required not from OnChartEvent.
If I'm wrong, please provide a concrete example where this status would be demanded from something other than OnChartEvent.
I wrote an example above, everything works fine )
In OnChartEvent when moving the mouse we change the parameters and give the command to redraw the canvas. Without a parameter in the structure we would have to pass sparam to an object, from there to another object, and there to the Draw() method.
The mouse coordinates are a different matter. Current mouse coordinates are not event information. The event is their change.
There may be times when mouse coordinates are needed outside OnChartEvent. For example, here.
Well, when you drag the mouse, the command to redraw a part of the object is called from OnChartEvent at the moment when the mouse coordinate changes and while the mouse button is pressed, and OnChartEvent has this status, why embed it in the Window structure?
If you would do the same thing not from OnChartEvent, and at the same time in the instance W of the Window structure there would be MouseStatus, you would have to organise an endless loop of polling of this parameter (MouseStatus) to catch the moment of releasing the mouse button, which would hang the CPU.
This loop is not needed only in OnChartEvent.
I just want to say that you can and should use the button status only from OnChartEvent, which already has it.
If I'm wrong, then give me a concrete example where this status would be required not from OnChartEvent.
Very strange reasoning. There is no logic at all.
Both mouse coordinates and pressed keys are external states. It is passed through parameters to the handler, where if it is put into the internal variables of the object (which is certainly useful), it should be there as a whole, not in parts. A library is by definition something that is made not for one's own needs, but in a generalised form, taking into account the potential needs of others. You can't know all the needs in advance, so you just don't make artificial restrictions like this.
I wrote an example above, everything works fine )
In OnChartEvent when moving the mouse we change the parameters and give the command to redraw the canvas. Without a parameter in the structure we would have to pass sparam to an object, from there to another object, and there to the Draw() method.
This is a classic of the genre - in all window libraries, the states of mouse buttons are passed in a single structure with the cursor coordinates.
because they all together describe one entity and cannot be separately at all.
updated to version 1.29
new:
1. added the following defines for simplicity of code writing and improving readability:
2. added the MouseStatus parameter to the Window structure, which can take 4 values, as requested by the workers: