文章 "图形界面 X: 高级列表和表格管理。代码优化 (集成构建 7)"
已发布文章《图形界面 X：高级列表和表格管理》（Graphical Interfaces X: Advanced List and Table Management.代码优化（第 7 版）：
如何访问组合框列表才能做到这一点？
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]);}
}
如果要访问列表的组合框，又该如何做呢？
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]);}
}
CComboBox 类中有一些方法可以返回指向列表和滚动条的指针。通过获取 指向这些元素的指针，可以调用它们的方法。
CListView *GetListViewPointer(void) { return(::GetPointer(m_listview)); }
CScrollV *GetScrollVPointer(void) { return(m_listview.GetScrollVPointer()); }
3.老实说，我对您的方案中出现重复性方法感到有些惊讶。我希望我能更仔细地研究一下......你可以认为我的代码是 "未经优化的堆砌"，但我没有任何重复两次的机制。没有类似的函数。我希望你也能这样做。)
如今，当元素大多由多个图形对象组成时，就离不开常用的虚拟方法了。在这一部分，我所说的优化是指所有元素都将被绘制的开发阶段。然后，我想这些标准虚拟方法可以简化为元素基类中的单一声明和实现。
我不想在这里讨论你的代码。这是私人代码，请不要外传。我对你的代码的看法没有改变。
1.目前，当元素大多由多个图形对象组合而成时，没有常用的虚拟方法是不可能的。在本部分中，我所说的优化是指所有元素都将被绘制的开发阶段。届时，我想这些标准虚拟方法可以简化为元素基类中的单一声明和实现。
我不想在这里讨论你的代码。这是私人代码，请不要外传。我对你的代码的看法没有改变。
1.也许，当您开始实施 "绘制 "控件技术时，您将设法摆脱方法的重复。但是，正如您自己所注意到的，您认为 这将会有所帮助。也就是说--也许不会我的看法是，这些事情并不相关。
一个 "绘制 "的控制元素在功能上与由多个对象构建的元素并无不同，但它的创建需要一种完全不同的技术。也就是说，这种技术不同于创建由多个对象构成的元素的技术。
有趣的是，绘制的元素由多个对象组成，但这些对象--一方面不是 MT 对象（而只是绘制细节），另一方面--在程序内部，绘制细节是具有自身属性的相同功能对象。
也就是说，对象的数量并没有减少。从 MT 对象开始，元素细节（以及元素本身）就成为程序的内部对象。程序（与OnChartEvent() 函数 不同）可以看到它们、定义它们并与它们一起工作。
这项技术非常复杂，需要对代码进行高度优化...
2.您根本不知道整个机制是如何运作的，就匆忙发表了自己的意见。你无法改变它，因为你目前只看到了代码的一小部分。好吧，我只能忍受你这样的观点了。唉）。
P.S我们不要讨论这个问题了。我并不生气。:)
1.也许，当您采用 "绘制 "控件技术时，就能摆脱方法的重复。但是，正如您自己所注意到的那样，您认为 这样做会有帮助。也就是说--也许不会我的看法是，这些事情并不相关。
我是假设，因为我还没有实现和测试过。
绘制 "的控制元素在功能上与由多个对象构建的元素并无不同，但其创建需要完全不同的技术。也就是说，这种技术不同于创建由多个对象构成的元素的技术。
有趣的是，绘制的元素由多个对象组成，但这些对象--一方面不是 MT 对象（而只是绘制细节），另一方面--在程序内部，绘制细节是具有自身属性的相同功能对象。
也就是说，对象的数量并没有减少。从 MT 对象开始，元素的细节（以及元素本身）成为程序的内部对象。程序（与OnChartEvent() 函数 不同）可以看到它们、定义它们并使用它们。
你写的东西太明显了，跟你讨论根本没意思。我的看法有点不同。我将在库第二阶段开发的下一篇文章中表达我的观点。
我想是的，因为我还没有实施和测试过。
你写的东西太明显了，跟你讨论根本没意思。我的看法有点不同。我会在图书馆第二阶段开发的下一篇文章中表达我的观点。
好吧，我不知道为什么这些事情对你来说是显而易见的。你们已经实施了吗？
我们谈到的技术在任何 MQL 文章中都没有描述。还是我说错了，你能给我一个链接吗？
最重要的是，不可能通过外观优化 来实现这种技术 - 您需要"更换基础"。
更换基础 是最困难的过程。通常情况下，一切都会崩溃--计划、互联、机制....。一切。然后，一切都要重新恢复。
一般来说，--你不能希望你的敌人经历这个过程（此外，--你必须经历很多次......）。 最后，代码会与开始时大不相同。
H.Y. 想象一下，如果有人在你付出所有努力后对你说："你的代码是一堆未经优化的代码"。你会生气吗？:)
好吧，我不知道为什么这些事情对你来说是显而易见的。你已经实施了吗？
我们所说的技术在任何 MQL 文章中都没有描述。还是我说错了，你可以给我一个链接？
如果我还没有实现某项技术，这并不意味着我没有考虑过它，也不意味着我不知道该如何实现它。我只是还没动手而已。我不像你，我会详细描述我所做的一切。这也需要时间。
我不需要阅读文章来实现某些东西。如果没有现成的解决方案，我就会寻找自己的方法。但你有机会阅读文章。你不去读，也不去问文章中解释过的问题，而是一味地随意 "射击"。
最重要的是，不可能通过外观优化 来实现这种技术--你需要"改变基础"。
改变基础 是最难的过程。通常情况下，一切都会崩溃--计划、互联、机制....。一切。
最后，代码会与开始时大相径庭。
OOP 则不同。你只是在这一知识领域存在着绝对的差距。你所说的 "最难的过程 "可以用 OOP 很简单地解决。
H.I. 想象一下，如果有人在你付出所有努力之后对你说："你的代码是一个未经优化的堆"。您会生气吗？:)
冒犯并不是我的专利。我记得有一位英国论坛的参与者提出了一个如何改进方案的解决方案（没有实施）。我采用了它。最困难的过程并没有出现。用您的方法，您将长期自欺欺人地吹嘘执行不力和与风车作斗争。
新文章 图形界面 X: 高级列表和表格管理。代码优化 (集成构建 7)已发布：
函数库的代码需要进行优化: 它应该更规范化, 这样可以 — 更具可读性并易于理解学习。此外, 我们将继续开发之前创建的控件: 列表, 表格和滚动条。
因此, 决定创建一个附加的继承中间类来放置频繁重复的代码和方法, 以便处理控件所附属表单的指针。函数库方案中在表单和控件之间相关联的部分如下:
图例. 3. 函数库方案中在表单和控件之间相关联的部分
作者：Anatoli Kazharski