Gallery of UIs written in MQL - page 76

New comment
 
Edgar Akhmadeev #:

Neither are we yet. We have to start somewhere. Spread out and jump.

I'm making the first version at my discretion, there is no way out, but I will definitely listen to the intelligent opinion of respected forum members.
 
Like STALKER2, we'll finish it together.
 
Edgar Akhmadeev #:
Like STALKER2, we'll finish it together.
Okay.)
 
UI is still 100% pure MQL.
All vector based, fully scalable and adjustable to any display. 
All visual displays work asychronously within a core class which handles and distributes all MQL events to objects, depending on their subscription settings and based on event-priorities.  
It also provides an API to access all data and to control trading also from indicators written in MQL (special templates) and from C#.  
>400 classes, <>200.000 lines of code, 9 years of ongoing development, MT4 and MT5 - identical code by using conditional compiling and downward-compatibility-base-classes. Main development in MQL5 only. 
No original libraries or classes.
Actually the whole code is 99,99% MQL, only pipe-interactions and string-comparisons are done with C#/DLLs. 

The screenshot shows a trade with CFD but with the mapped volume of the underlying future. That´s why there is a real orderbook and volume profile as well. 

 
And btw this is also part of it, an enhanced Dev-environment with a objects and classes browser etc:
 
 

Current stage of VE development:

  • Almost 400-odd window properties, elements and parameters from the core are integrated and tabbed into the editor windows. All of them will become controllable settings of GUI elements created in VE.
  • 52 templates of various control elements necessary in the work of users are integrated.
  • A lot of work has been done on design and styling. I continue to weigh a variety of solutions to achieve practicality and usability of the VE GUI.
  • Once the integration of templates and properties, as well as their sorting and distribution, is complete, work on functionality will begin.
  • At the moment the GUI is written in the KIB markup language, which is quite tedious. The transition to visual editing has not happened yet. However, this will happen in the near future.
  • There are graphical defects. They are temporary.
  • The height of the Taskbar has been reduced to save space.
  • The frame of the editor window has been moved out of the field of view for more space.


 
Sounds awesome Peter, I think once you're using the VE to build itself it will definitely give you some valuable insight on how your UI design is working.
Looking forward to the next development update. 
 
Douglas Prager #:
That sounds awesome, Peter. I think when you use VE to build yourself, it will give you valuable insights into how your UI design works.
Looking forward to the next development update.
Thank you, Douglas. You're right, that's exactly right. There is a minimum technical "treshhold" to overcome.

I will follow your fundamental development with interest as well.
 
Doerk Hilger #:
UI is still 100% pure MQL.
All vector based, fully scalable and adjustable to any display. 
All visual displays work asychronously within a core class which handles and distributes all MQL events to objects, depending on their subscription settings and based on event-priorities. 

I hope I'm not stealing the very interesting thread and forgive me Peter if I do, it won't be a discussion just hope for a short answer for the theorethical interest - do you mean you have a kind of static class that knows (keeps track of all the object pointers) all the class objects instansiated in the system and each object has access to subscribe itself to required events on that control static class and that static control singleton class just delivers the events to all object? If so do you view that as correct in terms of OOP or maybe is it acceptable event driven programming? Because you wrote about it, I guess you would want to accept questions about it and if so please let's keep it as short as possible to not hijack this thread, although it is related. 

 
Amir Yacoby #:

I hope I'm not stealing the very interesting thread and forgive me Peter if I do, it won't be a discussion just hope for a short answer for the theorethical interest - do you mean you have a kind of static class that knows (keeps track of all the object pointers) all the class objects instansiated in the system and each object has access to subscribe itself to required events on that control static class and that static control singleton class just delivers the events to all object? If so do you view that as correct in terms of OOP or maybe is it acceptable event driven programming? Because you wrote about it, I guess you would want to accept questions about it and if so please let's keep it as short as possible to not hijack this thread, although it is related. 

Yes, thats exactly what it is. 
Brief description:

The core receives all MetaTrader events and any object can subscribe to the core. Therefore the CObject class had to be redesigned/modified as well, so that any object has a function named "public: virtual void OnEACycle(CCycleParams * cpm)". Such a cycle could then be a chart-event, init, deinit etc. Every object can also have an "public: virtual void OnEATick()". Nice side effect is, that you get an extra feature that way, coz u can subscribe to the end of any cycle as well, no matter which it is. Pretty useful to close a file or finish any other stuff, simply at the end of any cycle. 

Furhtermore, every CObject object can have childs and also subscribers. Means, an object could trigger its own events like when sth. was clicked or similar. Then you simply perform an object.SubEvent(STH_CLICKED, params). That way the object itself does not care who needs this information, its just distributed to the subscribers, they receive an OnSubEvent(int msg, CSubEventParams * sep) and can do with that whatever they want. 

All in all, this way it is more releated to that way of coding we know from C#, where you also just use .Invoke() to fire events and don't care about who gets them. 

Its actually not that super-complicated to implement, but of course the details are the challenge in the end, since its a core/base for every single EA or indicator for the future which has to function in every scenario.  

1...6970717273747576777879808182
New comment