Gallery of UIs written in MQL - page 45

New comment
 
hini #:
I downloaded the gif, not sure if it's a problem with my OS. Just reporting it.
Yes, found the cause. Resizing the chart in different ways generates different combinations of OnChartEvent() events coming in. When changing manually, the OnChartChange event comes 2 times (I checked). When switching charts - once or twice. When closing the navigator window once, but other events come as CharEvent Custom. When moving the terminal window to another monitor - once.

In general, it is necessary to write conditions catching all variants of event combinations when changing chart sizes.
 
I would like to add why you cannot simply check the chart sizes by comparing them with the previously recorded ones.

When switching charts, the ChartGetInteger() functions of chart sizes send incorrect values, which makes the algorithm "think" that the sizes have been changed and the taskbar "jumps" from its place. I had to work hard to get round this problem. Now I will check what values of chart sizes are reported to ChartGetInteger() functions on these events.
 
That is, when switching charts, the sizes do not change, but the ChartChange event comes, but the ChartGetInteger() function for some reason ALWAYS reports the sizes 480 (width) and 167 (height). Always and at any chart size. (Build 2470. I haven't checked the new one yet).
 
On the new build (4435) when switching charts the ChartGetInteger() function returns values 490 width, 103 height. The actual chart sizes are 1068 width and 438 height.

Note that the sizes do not change when switching charts.
 
Based on these conditions, I will continue to study the peculiarities of incoming events in order to distinguish real changes in chart sizes from erroneous ones. And when the developers fix the function, I will just simplify the code. :)
 
Tested different chart resizing events. The problem seems to be only with chart switching, where no actual resizing occurs. But the ChartGetInteger() function persistently reports 490 to 103.

Everything is fine on the other events.


Taskbar fix in the next release.
 
Реter Konow chart resizing events. The problem only seems to occur when the chart is switched, in which case no actual resizing occurs. However, the ChartGetInteger() function consistently reports 490 to 103.

All other events are fine.


The taskbar issue will be fixed in the next release.
Thanks for your hard work! Looking forward to your work.
 
hini #:
Thank you for the work you have done! Looking forward to seeing your work.
Thank you!
 

Cleaned, recompiled, reinstalled.

I'll list what I noticed, in no particular order:

1. After opening a window, nothing appears on the taskbar. After minimising the window, the button appears. After unfolding it does not disappear. If the concept of behaviour "like in Windows" is conceived, it should appear at once.

2. With a dynamic window, after the cursor is moved over the minimise and maximise buttons, they remain highlighted as long as the cursor is inside the window.

3. With a dynamic window, the header becomes grey after expanding, stays grey after returning, and restores the colour only after minimising and returning.

4. The expanded window does not hide the time and price scales on the chart.

5. A table placed under"H_TAB, "Report" by the command"i, AT, _X2X, "MF", 5, _Y2H, "Report", 5," ignores the left edge setting. Same with"i, AT, _X2X, "MF", 5, _Y2Y, "MF", 20,".

6. Most importantly. The fact that the dynamic window doesn't allow V_BOX has completely changed my design. The two tables were in their own boxes for ease of positioning and having scrolling. Now that I had to draw them directly on the "MF", I can't position the bottom table immediately below the top table. Binding "i, AT, _X2X, "MF", 5, _Y2H, "Table1", 5," does not work because the group name Table1 is not an element. I managed to bind to the last row of the table, but with a dynamic table this is not an option. I haven't figured out how to refer to the table and not to the group. If it is intended to add rows to the table programmatically, then the way of addressing the table is assumed.

7. One more thing. Your dynamic window is a peer window that can be expanded and collapsed. I would like not a window, but a desktop. Like in your constructor. So that it

a) open expanded at once, covering the entire chart

b) not have a header and frame (only a taskbar)

c) cannot be collapsed

d) allow you to place items like a regular window.

That is, replace DINAMIC with FULLSCREEN or DESKTOP. You already have the basis for this.

 
Edgar Akhmadeev #:

...

Thanks for the detailed opinion.

I will try to solve your problem with dynamic window - complexity of tables arrangement.

Let me put it this way - a dynamic full-screen window has a special purpose in the user GUI and as a consequence has specific limitations. It is not universal like the "SETTINGS" window. And this is logical. After all, everything specifically "customised" is always limited in some way.

However, a dynamic table or an infinite list can be combined with other groups of elements in a dynamic window and they do not need a separate, "sole" space, although in my opinion, it is more convenient. How to realise compatibility of tables with other groups? - This is a question of technology.

For the sake of experiment, I will take your tables and try to insert them into a full-screen window. Of course, I need to correct the code...

Result:

(Click on the picture)


I won't post the code yet, because frankly speaking everything is very "raw". I had to use tricks and "crutches". But, as you can see, everything can work.

1...383940414243444546474849505152...70
New comment