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
2. Framework from scratch.
Similar here. When I started to go a bit deeper into the standard libraries I found many things, which I did not like. Not only the bad performance of those, but also lack of flexibility and also because of an incomplete architecture. I am missing for example a global CMouse class/object as well as a class between CWnd and CObject, because CWnd objects are childs of the chart as well as lines are, and there is no connection to such and no final implementation of any such objects at all like I described it above. And, there is no master object, which holds all such chart objects which makes it possible to show/hide all of them with one command, destroy them, whatever. CCanvas, same thing, a nice class but where is the implementation with CWnd which allows me to create interactive objects based on bitmaps that inherit from CWnd? And so on.
What is the role of a global CMouse? Does it serve the end user as a standalone class only, to get easy access to mouse managing? How is it relates to framework?
About the class between CWnd and CObject, I don't follow your explanation as to why you found them needed. CWnd objects are child of the chart, as well as lines - I don't get the problem in that, and why there is no connection?
You also say that there is no final implementation of any such objects at all like you decribed above? (where did you describe?)
The opportunity of a global mouse object is, at least in my GUI, to save any informations about the mouse (position, press position, price of position etc.) accessible for every class dealing with auch informations. Furthermore the mouse object hold informations about exclusive usage of the mouse, for example when dragging. This just saves much CPU time while something is dragged or is about to become clicked etc.
Last but not least: Nothing of the standard library works in strategy tester when used in EAs because there are no mouse events. And if you want to implement mouse support in strategy tester, you'll be grateful for such a mouse class too, because the class does not care where the information about mouse movements is from, but the objects which need the info still know where they have to look for.
---
Its not only the class between CWnd and CObject I am missing, its actually more the missing master object/container which holds pixel based objects as well as time/price based objects. As you mentioned too, they are all objects of the chart, so the logical master should be an object which represents the chart and which holds all the objects. And to realize such, there must be a class between CWnd and CObject.
The background for this idea is not only the logic, its also a matter of performance. In my case, when the chart changes somehow, the master object detects this, it loops all contained objects which can be containers of lines, containers of CWnd as well as any single objects from any of these types, and "informs" any object which wants to be informed by that. This means just, there is one single loop at exactly one point in the code, and due to usage with containers and sub containers, this is extremely efficient.
I also use this master to freeze all objects at once and to prevent any physical updates by just one line of code. The difference in performance is drastically. Example: When I create all the visual objects I need for my EA, and in some cases theses are more than 1000, I freeze this master object upfront, create the other objects and "thaw" it afterwards which results in one physical update of the chart. Without freezing, this process can take a whole minute. With freezing, its less than 2 seconds.
Before I started to create the GUI by myself, I really tried it with the standard libs. Later, I tried to keep at least some parts. But the problem was, that it simply was impossible to realize what I had in mind because of an incomplete implementation and an architecture which is kinda ... LetsMakeSomethingThatWorksSomehowForWeDontKnow. Visual performance is reached with clear hierarchy, but the standard libs are somehow anarchistic.
Anyway, I am not the first person who recognized this. And as Alain mentioned already, I am not sure if this really helps, because its too theoretical. I just can talk about my experience with all this stuff which is not just based on MQL, but my opionion is nevertheless just my opinion and of course not law.
But for the second type, the way of thinking and considerations discussed here is very valuable and very practical too. Of course an article would be better, but nevertheless.
I don't think that people will build frameworks after reading just this thread, but still it has good pieces of information and insights, that seems that lack even for people who already built public MQL frameworks.
So, for the mouse and tester if I got you right you use the ::OnTester() to call your mouse instead of a user input, if I follow you.
Thanks again, Doerk.
The opportunity of a global mouse object is, at least in my GUI, to save any informations about the mouse (position, press position, price of position etc.) accessible for every class dealing with auch informations. Furthermore the mouse object hold informations about exclusive usage of the mouse, for example when dragging. This just saves much CPU time while something is dragged or is about to become clicked etc.
Last but not least: Nothing of the standard library works in strategy tester when used in EAs because there are no mouse events. And if you want to implement mouse support in strategy tester, you'll be grateful for such a mouse class too, because the class does not care where the information about mouse movements is from, but the objects which need the info still know where they have to look for.
Or am I missing something?
The mouse object does not look itself if its over an object or if its currently in use by an object, this is done by the objects themselves. But the mouse object is the central "place" where such information can be stored.
The standard control classes work like that, that on every mouse movements all objects are looped to figure out, if this motion has something to do with them, this takes much CPU time which can be seen easily when you start the task manager and just move the mouse when EA or Indicator is loaded and a CDialog object is part of the EA or indicator. The more complex the dialog, the higher the CPU usage.
In my GUI, with the existence of a global mouse object, this is done different. You can have 10000 objects and the CPU usage does not grow at all when the mouse is moved. Its done that way, that only as soon as the mouse button went down on a specific object, this one specific object informs the mouse object, that it has the focus, and as soon the mouse moves after this button-down event, no other object needs to take care of it, and any further movement of the mouse / any further mouse-move-event is routed directly to the object which has the focus - which is always exclusive - by using its pointer.
And due to the circumstance, that all chart objects, no matter if these are time/price based (trendlines etc.) or pixel coordinate based (panels etc.) have a common base class, all these objects can use a common set of overloaded functions to handle this. Thats also a reason why I mentioned, that there is a class missing between CWnd and CObject, because this base class between is the same base class that is used by time/price based objects as well and only this makes it possible to communicate effectively and to handle such events effectively.
Yes.
Nevertheless I have the option to catch any movements if clicked or not, and also with better CPU performance and without using the object names, but that was not the question here.