Discussion of article "Graphical interfaces X: Advanced management of lists and tables. Code optimization (build 7)"
Published article Graphical Interfaces X: Advanced List and Table Management. Code Optimisation (build 7):
Author: Anatoli Kazharski
What to access to do the same with the combobox list, it doesn't work like that:
if(id==CHARTEVENT_CUSTOM+..){
m_combobox_sm.Clear();
m_combobox_sm.ItemsTotal(4);
m_combobox_sm.VisibleItemsTotal(4);
string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};
for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}
}
What to access to do the same with the list of combo box, it doesn't work like that:
if(id==CHARTEVENT_CUSTOM+..){
m_combobox_sm.Clear();
m_combobox_sm.ItemsTotal(4);
m_combobox_sm.VisibleItemsTotal(4);
string items_text[4]={"FALSE","item 1/0","item 2/0","item 3/0"};
for(int i=0; i<4; i++){m_combobox_sm.SetItemValue(i,items_text[i]);}
}
The CComboBox class has methods that return pointers to the list and scrollbar. By getting pointers to these elements you can call their methods.
CListView *GetListViewPointer(void) { return(::GetPointer(m_listview)); }
CScrollV *GetScrollVPointer(void) { return(m_listview.GetScrollVPointer()); }
1. The zebra style will now be set as default for all tables, or have I misunderstood?
1. Zebra style is an enabled mode. It is disabled by default. If you need it, it is enough to call the corresponding method, specifying the second colour. Actually, the article explains it in detail.
2. it will be possible.
3. I will think about it as part of further code optimisation.
1. Zebra style enabled mode. Disabled by default. If you need it, it is enough to call the corresponding method, specifying the second colour. Actually, the article tells about it in detail.
2. it will be possible.
3. I will think about it as part of further code optimisation.
3. To be honest, I am somewhat surprised by the presence of repetitive methods in your programme. I wish I had studied it more carefully... You may consider my code an "unoptimised pile", but I don't have any mechanism repeating twice. There are no similar functions. I wish you to do the same. )
Nowadays, when elements are mostly made of several graphical objects, you cannot do without common virtual methods. By optimisation in this part I meant the stage of development when all elements will be drawn. Then, I suppose, these standard virtual methods can be reduced to a single declaration and implementation in the base class of an element.
I don't want to discuss your code here at all. It is private, so keep it to yourself. My opinion about what I have seen in your code has not changed.
1. At present, when elements are mostly assembled from several graphical objects, it is impossible to do without common virtual methods. By optimisation in this part I meant the stage of development when all elements will be drawn. Then, I suppose, these standard virtual methods can be reduced to a single declaration and implementation in the base class of an element.
2. I don't want to discuss your code here at all. It is private, so keep it to yourself. My opinion about what I have seen in your code has not changed.
1. Perhaps, when you start implementing the technology of "drawn" controls, you will manage to get rid of duplication of methods. However, as you have noticed yourself - you assume that it will help. That is - perhaps it won't... My opinion is that these things are not related.
A "drawn" control element is not functionally different from an element built from several objects, but its creation requires a completely different technology. That is, a technology different from the one that is used to create elements made of multiple objects.
It is interesting that the drawn element consists of several objects, but these objects, - on the one hand are not MT-objects (but just drawing details), and on the other hand - inside the programme the drawing details are the same functional objects with their own properties.
That is, the number of objects does not become less. Just from MT-objects, details of elements (and elements themselves) become internal objects of the programme. And the programme (unlike the OnChartEvent() function) sees them, defines them and works with them.
The technology is very complex and requires very high optimisation of the code...
2. Not having any idea how the whole mechanism works, you hurried to make your opinion. You could not change it because you have seen a tiny part of the code so far. Well, I will have to put up with such an opinion of yours. Alas.)
P.S Let's not discuss it. I'm not offended. :)
1. Perhaps, when you implement the technology of "drawn" controls, you will be able to get rid of duplication of methods. However, as you have noticed yourself - you assume that it will help. That is - perhaps it won't... My opinion is that these things are not related.
I assume, as I haven't implemented and tested it yet.
A "drawn" control element is not functionally different from an element built from several objects, but its creation requires a completely different technology. That is, a technology different from the one that is used to create elements made of multiple objects.
It is interesting that the drawn element consists of several objects, but these objects, - on the one hand are not MT-objects (but just drawing details), and on the other hand - inside the programme the drawing details are the same functional objects with their own properties.
That is, the number of objects does not become less. Just from MT-objects, details of elements (and elements themselves) become internal objects of the programme. And the programme (unlike the OnChartEvent() function) sees them, defines them and works with them.
You write such obvious things that it is not even interesting to discuss it with you. I see it a bit differently. I will express my opinion in one of the next articles of the second stage of the library's development.
I assume, as I haven't implemented and tested it yet.
You write such obvious things that it is not even interesting to discuss it with you. I see it a little differently. I will express my opinion in one of the next articles of the second stage of the library's development.
Well, I don't know why these things are obvious to you. Have you already implemented it?
The technology we talked about is not described in any MQL article. Or am I wrong and can you give me a link?
The main thing is that it is impossible to come to this technology by means of cosmetic optimisation - you need to"replace the foundation".
Changing the foundation is the hardest process. Usually everything collapses, - schemes, interconnections, mechanisms.... EVERYTHING. Then everything is restored anew.
In general, - you can't wish your enemy to go through it (and besides, - you have to go through it many times...). And in the end, the code will be quite different from what it was in the beginning.
H.Y. Imagine if someone says to you after all your efforts: "Your code is an unoptimised heap". Would you be offended? :)
Well, I don't know why these things are obvious to you. Have you already implemented it?
The technology we were talking about is not described in any MQL article. Or am I wrong and you can give me a link?
If I haven't implemented something yet, it doesn't mean that I haven't thought about it and don't know how I will implement it. I just haven't got my hands on it yet. Unlike you, I describe everything I do in detail. It also takes time.
I don't have to read articles to implement something. If there is no ready-made solution, I look for my own methods. But you have the opportunity to read articles. And instead of reading and not asking questions that are explained in the article, you keep "shooting" at random.
The main thing is that it is impossible to come to this technology through cosmetic optimisation - you need to"change the foundation".
Changing the foundation is the hardest process. Usually everything collapses - schemes, interconnections, mechanisms.... EVERYTHING.
And at the end, the code will be quite different from what it was at the beginning.
It is different with OOP. You just have an absolute gap in this sphere of knowledge. What you have "the hardest process" can be solved quite simply with OOP.
H.I. Imagine if someone says to you after all your efforts: "Your code is an unoptimised heap". Would you be offended? :)
Offence is not peculiar to me. I remember that one of the English forum participants suggested a solution (without implementation) how to improve the scheme. I used it. The hardest process did not arise. With your approach you will torture yourself for a long time bragging about poor implementation and fighting with windmills.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
New article Graphical interfaces X: Advanced management of lists and tables. Code optimization (build 7) has been published:
Fig. 3. Part of the library scheme regarding the relationship between the form and controls
Author: Anatoli Kazharski