Gallery of UIs written in MQL - page 42
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
Lack of prioritised development directions never leads to good results. An elementary truth that all professional developers know. 4 years ago I couldn't put up a finished version of the designer because I didn't have a plan for completion. If I had a plan, everything would have been finished long ago. The next reason for stopping the project is fruitless arguments with other people's opinions on the forum. Debates about approaches in programming or the necessity-unnecessity of the GUI as such... Unfortunately, it was a useless waste of time.
So what is the completion of this project? The answer to this question is very important because it determines the choice of directions for further development.
And so, as I present it:
1. Software control of interface elements.
This is one of the main tasks at the moment. Now the user can only "catch" GUI events in the API file, but not get/change element properties or parameter values. Weighing the complexity, I can say that the task is easy and will be solved before the next release. Give the user programmatic access to a wide set of GUI elements and windows properties.
2. regular and dynamic tables .
Regular tables have already been implemented. Their work has been repeatedly tested. Such features as dragging and dropping columns and rows (changing their place in the table), collapsing/expanding table rows (adding T_FOLDER element) or hiding/unhiding columns worked. Automatic integration of controls into the table worked. For example, checkboxes, drop-down lists, buttons, sliders, input fields with buttons and simple input fields - all of them were integrated into the table by themselves when the keyword IS_TABLE was added to the group header. Values in cells could be coloured according to value. Tables could even be embedded in tree lists.
However, is it worth spending the time to bring back all the old features?
It's hard to say.
I think the first thing to do is to bring back the basic features of regular tables and make sure they work well. The rest is as it turns out.
But the main thing in the interface of a serious trading robot is dynamic tables. The ones that are capable of passing through an endless stream of data from the stock exchange. I have never implemented them before.
Conclusion: dynamic tables are a priority.
(We need to start development.)
3. Tree lists.
Quite realised GUI element redone many times before. And it worked better each time. The latest version is particularly good, but it's not finished. If I remember in detail, I can finish it in a day or two. But how much do you need it in a GUI? I think it won't hurt, but you shouldn't obsess over it.
Conclusion: tree list is not a priority for further development.
(I'll finish it when I have time.)
4. Dynamic windows.
The basic mechanisms - resizing, vertical and horizontal scrolling, scaling, adaptation of the scaled window to the chart size change - are already working well. But there are a lot of small, annoying bugs. Being complete, dynamic windows are ideal for large dynamic tables and long lists.
Conclusion: finishing dynamic windows is a priority.
(It may take a couple or three days of hard work with enthusiasm.)
5. Group and table minimisers.
G_FOLDER and T_FOLDER elements. Already worked very well in the past. How they work now I don't know, as I haven't had time to test them. Interestingly, in the latest development of the element phenomenon function, I unified the management of the tree list and these two types of collapsers. One function managed three elements and was no more than 400 - 500 lines in size (which is not much by my standards). If I get this function working again (it's disabled now), all three elements will work perfectly. Let's see.
Conclusion: elements G_FOLDER and T_FOLDER are not in priority.
(I will do it if I have the opportunity and desire).
And the last priority task that came to mind now:
6. Creation of a branch of templates of groups of elements and windows written in the markup language.
This will allow users to quickly and easily build the necessary interface for solving tasks, even without deep knowledge of the language.
If anyone has any thoughts on priorities for further development, please share. I will take note.
Yes, programme management is the most important, a must for anyone who will use the engine.
For me, dynamic tables are a must. I need the interface mainly for visualisation of events and reports in real time. The controls are the strapping to manage them (filters, etc.) With the implementation of this I could start to integrate the engine.
The second priority is a full screen window. But this is very simple - you already have this done in the designer. With a taskbar. And temporarily I can use the largest possible window. I have to choose the size, it's painful.
The third priority is graphics. I don't know how difficult it is. Maybe you should use standard kanvas tools, if they are flexible enough. I've never tried anything other than Fast And Furious Easy And Fast v1.
God willing the motivation is enough. More often than not it fades away after an encounter with the haters. "Good people are in the majority, but the evil ones are better organised".
The second priority is a full screen window. But this is very simple - you already have this done in the designer. With a taskbar. And temporarily I can use the largest possible window. I have to pick up the dimensions, which is painful.
The third priority is graphics. I don't know how difficult it is. Maybe you should use standard kanvas tools, if they are flexible enough. I've never tried it except Fast And Furious Easy And Fast v1.
God willing the motivation is enough. More often than not it fades away after an encounter with the haters. "Good people are in the majority, but the evil ones are better organised".
1. Programmatic item management will be in the next release. Tentatively in 7 - 10 days.
2. Dynamic tables are "in development". How long it will take I can't say yet. The process may be very fast.... or not so fast. Unknown.
3. You already have a full screen window. Try it out. In the window properties write "DINAMIC" instead of "SETTINGS". Test it and write about your impressions.(Just go to the field release version of the builder). You can change the size by pulling the edges of the window or zoom with the top button. There is an option with double-click on the top bar (where the window name is), or just grab the window by the "cap" and drag it up until it scales itself. The same manipulations work the other way round.
4. Print your window's API file and post it here. I will look and understand how the tables are printed there. This is important for future software connection implementation.
5. I will seriously think about custom charts. I have seen Anatoly's implementation, but have not tried to replicate this element.
An important nuance when working with a dynamic window:
The window does not accept elements of type V_BOX, because they contain their own canvas. This results in overlapping of one canvas on another. Therefore, this element should be commented out together with all lines i, IN, "V1", .
That is, the groups that are placed in the V_BOX element should be just in the window on "MF". You don't need to specifically comment out the i, IN, "V1" line.
If it doesn't work, I'll show you in more detail tomorrow. In pictures.
An example of converting the settings window into a dynamic window:
(click on the image)