文章 "连续前行优化 (第七部分): 将自动优化器的逻辑部分与图形绑定，并通过程序控制图形"

新评论
 

新文章 连续前行优化 (第七部分): 将自动优化器的逻辑部分与图形绑定，并通过程序控制图形已发布：

本文介绍了自动优化程序的图形部分与其逻辑部分的连接。 它考虑了优化启动过程，从单击按钮到把任务重定向到优化管理器。

如前所述，ViewModel 是应用程序的图形部分与软件逻辑实现之间的连接器。 它是程序图形表述，其实现应用程序逻辑调用，并针对应用程序逻辑部分的回调在图形上做出反应。 相应地，来自 ViewModel 部分的公开属性对应于应用程序图形部分中的每个可编辑字段。 这些属性可以是 getter（只读），在这种情况下不能在图形中更改；也可以是 setter，如此即可覆盖隐藏在此属性后面的对象。 在前面的部分里，我们已经详细研究过数据绑定技术。 故此，我在这里仅提供一些示例。 

文本字段是通过可读写权限的属性进行连接。 举例，考虑一个字段，该字段指示正在执行优化的资产名称。 该字段的 XAML 标记极其简单。

    
<TextBox Width="100"
         IsEnabled="{Binding EnableMainTogles, UpdateSourceTrigger=PropertyChanged}"
         Text="{Binding AssetName}"/>

除了设置文本窗口的宽度外，它还含有字段 IsEnabled 和 Text。 第一个设置该字段是否可编辑。 如果将其设置为 true，则该字段可编辑。 如果为 false，则该字段被锁定。 “Text” 字段包含在此字段中输入的文本。 然后，每个结构都有一对花括号。 其内容设置对象与特定公共属性的连接，而属性来自在 “Binding” 参数之后指定的 ViewModel 类。

作者：Andrey Azatskiy

 

您再次展示了您作为程序员的高超专业水平。可以说，多一点可用性，就能多一点人气。要理解这些文章，你需要花费相应的时间来撰写它们。你会把你的优化器放在 kodobase 中，只提供代码和使用说明吗？也许会有更多的交易者注意到它。

我看到自定义优化标准 还没有出现，日历..... 中的高度也没有出现。由于必须使用 OnTester()，我们完全可以只使用自定义标准。我想再一次思考自动输入测试期的问题。我的实践表明，最好在多个工具上以 3-5 周为周期执行测试前向优化。手动编写每首乐曲的所有测试期并非易事。使用 MQL5 工具创建接收和输出周期的脚本并不难，但由于沙箱和格式的限制，您必须手动将它们传输到自动优化器。您可以在程序的功能中做到这一点。您个人可能不需要，但您为谁撰写过如此庞大和复杂的文章呢？

与众所周知的同类产品相比，自动优化程序的优点是运行可靠，缺点是设置复杂。不过，您为找到它的人准备了一本使用手册。

 
Good Beer:

您再次展示了您作为程序员的高超专业水平。可以说，多一点可用性，就能多一点人气。要理解这些文章，你需要花费相应的时间来撰写它们。你会把你的优化器放在 kodobase 中，只提供代码和使用说明吗？也许会有更多的交易者注意到它。

我看到自定义优化标准 还没有出现，日历..... 中的高度也没有出现。由于必须使用 OnTester()，我们完全可以只使用自定义标准。我想再一次思考自动输入测试期的问题。我的实践表明，最好在多个工具上以 3-5 周为周期执行测试前向优化。手动编写每首乐曲的所有测试期并非易事。使用 MQL5 工具创建接收和输出周期的脚本并不难，但由于沙箱和格式的限制，您必须手动将它们传输到自动优化器。您可以在程序的功能中做到这一点。您个人可能不需要它，但您一直在为谁撰写如此庞大和复杂的文章呢？

与众所周知的同类产品相比，自动优化程序的优点是运行可靠，缺点是设置复杂。不过，您为找到它的人准备了一本使用手册。

谢谢您的评论。正如我在文章结尾所写，我将在上一篇文章中添加所有新增内容。这是之前计划的内容之一。我试图在所有发表的文章中描述整个程序，从卸载报告的部分到自动优化程序本身的内部结构。我还记得承诺的编辑工作，而且我已经在做了。不过，我将在下一篇文章中发表，因为我必须先完成程序第一版的描述。我记得大学老师曾告诉我们："汽车制造公司不会在已生产的汽车版本上更换新的制动系统"。
关于代码，它附在文章后面，如果需要，您可以修改、拆解和更新（我会进行承诺的编辑，如果您需要更个性化的东西，可以将其作为选项添加，或者如果您感兴趣，可以自己解决），这就是为什么我写得如此详细，以便有一张所有工作原理的图片。我将增加自动分段功能。

新评论