Type() method of CObject derivatives in Standard library, always return 0 when casting to CObject. - page 4
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
Doesn't change a thing. Anything below 2ms is completely imperceptible to the human brain, and the difference between the two methods works out to mere microseconds on a full blown GUI. In this case it all comes down to developer preference. For the record, my preference is to use obj.Type() but in a pinch dynamic-casting will do, and there won't be any negative consequences for doing so.
I think hundreds of thousands of iterations on a single task is a bit overkill to test GUI app performance, because these kinds of tasks are only executed mostly once at every set interval e.g. every tick, in real-world GUI apps. I agree, the performance difference is barely noticeable.
I proposed another solution, but just to be clear: I don't discount your proposed solutions. They both make sense to me, and the OP seems satisfied with one of yours.
I think hundreds of thousands of iterations on a single task is a bit overkill to test GUI app performance, because these kinds of tasks are only executed mostly once at every set interval e.g. every tick, in real-world GUI apps. I agree, the performance difference is barely noticeable.
I proposed another solution, but just to be clear: I don't discount your proposed solutions. They both make sense to me, and the OP seems satisfied with one of yours.
With respect, the point of this exercise is to be able to iterate over all of the controls in one single collection. I do agree with your idea, however, because from a practical stand-point you would only really need to iterate over objects if for example you needed to deselect all buttons when a certain event occurs. In those regards it is much more practical to do what you did and just have a collection with buttons only.
With respect, the point of this exercise is to be able to iterate over all of the controls in one single collection. I do agree with your idea, however, because from a practical stand-point you would only really need to iterate over objects if for example you needed to deselect all buttons when a certain event occurs. In those regards it is much more practical to do what you did and just have a collection with buttons only.
Yours were the well-thought solutions without having to modify or clone the controls classes, or use multiple array instances. I was just thinking that maybe the OP was hoping for a quick fix (it seems it's not the case).
I was actually hoping somebody else would give a better solution, but it seems that's all there is to it. But it was a surprise to me that you even made a small library addressing this very problem, when any ordinary programmer would take the pain of modifying about two dozens of header files at every update, and be content with it.
I have seen the controls classes from the standard library improve over the years, but updates often take a long time and not worth waiting for. But hopefully one day we can see the control types defined on Defines.mqh and the standard control classes updated with their Type(), or a similar fix.
CCheckGroup only has check-boxes. Why would you need to iterate them to get an ID when they can only ever be check-boxes?
CCheckGroup as a simple example. CCheckBox has its own childs: CBmpButton, CEdit.
CDialog has CPanel, CEdit, CBmpButton, CWndClient.
The main issue is the hierarchy and child objects, the method "Control" is a recursive function, so one can access all controls on the panel regardless of private, protected or public member, but what we don't know, is the type of the object to cast it correctly and take the opportunity of its specific public methods, otherwise it fails during compile. There are two ways, we know the hierarchy and loop through members or try to guess the type by dynamic_cast and check the pointer.
I believe some sort of Type for each object is a minimum requirement to work with OOP, that might be why you have coded your own include files and tried to fill the GAP by subclass.
It is a must as @Alain Verleyen already mentioned.
But till then, I agree, subclass is the best solution, and dynamic_cast and clone will be next solutions.
Yours were the well-thought solutions without having to modify or clone the controls classes, or use multiple array instances. I was just thinking that maybe the OP was hoping for a quick fix (it seems it's not the case).
I was actually hoping somebody else would give a better solution, but it seems that's all there is to it. But it was a surprise to me that you even made a small library addressing this very problem, when any ordinary programmer would take the pain of modifying about two dozens of header files at every update, and be content with it.
I have seen the controls classes from the standard library improve over the years, but updates often take a long time and not worth waiting for. But hopefully one day we can see the control types defined on Defines.mqh and the standard control classes updated with their Type(), or a similar fix.
Yeah, my main intention to raise this topic was reporting the issue, I had already reported a bug in Standard Library and it was fixed for both MQL4 and MQL5, I have also found a bug in CCheckGroup::Check(const int idx,const int value) which causes array out of range issue.
Meanwhile solutions provided by @nicholi shen was quite helpful and instructive.