how to create objects dynamicly? (Some OOP stuff) - page 4

 

Absolutely. It took me months to create my own GUI framework with MQL, not calculated the experience which I had already from the past creating libraries like these. The most difficult part are not the events, its more the architecture and the almost impossibility to debug the code, because of all the nestings and recursions but also because of the states of the mouse which get already invalid when the debugging starts.

By the way, I offered a collaboration to MQ with these libs months ago and unfortunately not even got an answer. But fact is, the standard control library is just a nice but also bad try in comparison to what's actually possible. One can do way better. Maybe I should offer the library at the market place here, but I am scaring the bunch of work to write the whole documentation for it.

 
Doerk Hilger:
This is no question at all. OOP is based on the prinicipes of the nature. The earth doesnt feed you, it just provides the ressources and its up to you if, when and where you need what. 
Can you say what you mean by that? I get the general feeling of what you say, but not quite clear.
You mean, when creating a framework, just care for providing the resources? I get that but somehow find it difficult to practice because my tendency is too strong.

For instance, if I create a framework and I now create the button and the the radio button which is a somekind of button container - when I come to create the radiobutton, my tendency is to think on the dependent object, the button in this case, and how I communicate with it. It's a procedural programming habbit, I wonder if you made the shift sometime in your past from procedural to OO and you can point me to a clear view of what I need to focus on this case. Because I tend to focus more on the button (dependent object) then on the radiobutton.

Not sure I made it clear, it's just a question about pointing out the important things to focus on when creating a level in a framework.
 
Amir Yacoby:
Can you say what you mean by that? I get the general feeling of what you say, but not quite clear.
You mean, when creating a framework, just care for providing the resources? I get that but somehow find it difficult to practice because my tendency is too strong.

For instance, if I create a framework and I now create the button and the the radio button which is a somekind of button container - when I come to create the radiobutton, my tendency is to think on the dependent object, the button in this case, and how I communicate with it. It's a procedural programming habbit, I wonder if you made the shift sometime in your past from procedural to OO and you can point me to a clear view of what I need to focus on this case. Because I tend to focus more on the button (dependent object) then on the radiobutton.

Not sure I made it clear, it's just a question about pointing out the important things to focus on when creating a level in a framework.

Maybe I missed the point but I would like to give you my opinion.

I think you are too much on "theory", and waiting the light from someone else. There is no one perfect solution, there are solutions and you need to find it from your experience and your concrete needs.

This topic started from a practical case, and it knows became an obscure discussion on OOP. There is an interesting series of articles on GUI, you should take a look, then try to build an interface using the Standard Library, and using the library from these articles, and study the code...or not.

Just a suggestion, as I really don't see how you could be helped much better.

Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)
Graphical Interfaces I: Preparation of the Library Structure (Chapter 1)
  • 2016.02.01
  • Anatoli Kazharski
  • www.mql5.com
This article is the beginning of another series concerning development of graphical interfaces. Currently, there is not a single code library that would allow quick and easy creation of high quality graphical interfaces within MQL applications. By that, I mean the graphical interfaces that we are used to in familiar operating systems.
 
Alain Verleyen:

Maybe I missed the point but I would like to give you my opinion.

I think you are too much on "theory", and waiting the light from someone else. There is no one perfect solution, there are solutions and you need to find it from your experience and your concrete needs.

This topic started from a practical case, and it knows became an obscure discussion on OOP. There is an interesting series of articles on GUI, you should take a look, then try to build an interface using the Standard Library, and using the library from these articles, and study the code...or not.

Just a suggestion, as I really don't see how you could be helped much better.

Alain, I built an interface and I read the articles.
Maybe it's not the place to discuss OO, you might be right.
I started discussing it because Doerk presented the topic as response to the topic beginner and talked about correct OO approach.
The topic begginer himself was interested in Doerk's OO presentation, and I think it's natural to discuss that here.
Though you might be right that maybe it's too theoretical, still my opinion is that correct OO can not without involving some theory and in the end it becomse practical.

My difficulty is OO correct thinking, I just wondered if by chance Doerk might know from his experience the mental difficulty I presented.

 
Alain Verleyen:

There is an interesting series of articles on GUI, you should take a look, then try to build an interface using the Standard Library, and using the library from these articles, and study the code...or not.


I´ve just downloaded it to see what it does. And the first impression shows, that they did the same bad mistakes they did with the Standard Control Library. Already the very first example with one single dialog window lifts up the CPU usage from 10% (without) to 50-65% (loaded). This is already the best proof that the authors don´t have the necessary experience to develop such a library and that this cannot be - a - way to do it right.

I don´t understand anyway why MQ does not provide a professional GUI framework instead of explaining how its (not) done. Most of the MQL programmers surely want to develop EAs and Indicators, but don´t want to bother with such stuff.

Furhermore, the panel of their example is dead in the strategy tester, and this is where all such GUI stuff gets absurd anyway. This is no critics against you or against what you wrote, I know myself that there is simply no better public stuff available for MQL here.

 
Amir Yacoby:

Alain, I built an interface and I read the articles.
Maybe it's not the place to discuss OO, you might be right.
I started discussing it because Doerk presented the topic as response to the topic beginner and talked about correct OO approach.
The topic begginer himself was interested in Doerk's OO presentation, and I think it's natural to discuss that here.
Though you might be right that maybe it's too theoretical, still my opinion is that correct OO can not without involving some theory and in the end it becomse practical.

My difficulty is OO correct thinking, I just wondered if by chance Doerk might know from his experience the mental difficulty I presented.

There is no problem to discuss OOP here.

I don't agree about your "OO can not without involving some theory", but that doesn't matter.

 
Alain Verleyen:

There is no problem to discuss OOP here.

I don't agree about your "OO can not without involving some theory", but that doesn't matter.

Well in that case how do you explain the fact that there is bad oo programming? Just take a look at the topic originators attempt to oo solution and Doerks response. There must be theory that makes the difference betwenn right and wrong, isn't it?
 
Doerk Hilger:

I´ve just downloaded it to see what it does. And the first impression shows, that they did the same bad mistakes they did with the Standard Control Library. Already the very first example with one single dialog window lifts up the CPU usage from 10% (without) to 50-65% (loaded). This is already the best proof that the authors don´t have the necessary experience to develop such a library and that this cannot be - a - way to do it right.

I don´t understand anyway why MQ does not provide a professional GUI framework instead of explaining how its (not) done. Most of the MQL programmers surely want to develop EAs and Indicators, but don´t want to bother with such stuff.

Furhermore, the panel of their example is dead in the strategy tester, and this is where all such GUI stuff gets absurd anyway. This is no critics against you or against what you wrote, I know myself that there is simply no better public stuff available for MQL here.

Doerk, your most probably right, but that's not my point.

You should write a concrete example why this CPU issue happen, explain to Anatoli (author of the articles) what is the problem. I am sorry to say, that up to now all what you said is almost useless, even if you are 100% right. It's just too general and theoretical. No offense.

 
The problem is, that this issue is much too complex to give exact instructions. And thats why I am trying to provide some ideas and possible ways to those who are interested. Unfortunately I dont have the time to write an article nor to publish a fully documented library. Sorry. 
 
Doerk Hilger:
The problem is, that this issue is much too complex to give exact instructions. And thats why I am trying to provide some ideas and possible ways to those who are interested. Unfortunately I dont have the time to write an article nor to publish a fully documented library. Sorry. 
Shxxxx. You got it
Reason: