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.