文章 "图形界面 X: 高级列表和表格管理。代码优化 (集成构建 7)" - 页 4 123456789101112 新评论 Artyom Trishkin 2017.01.03 19:40 #31 Anatoli Kazharski:那就通过事件。但不是通过频率如此之高的计时器。一般来说，刹车是在你这边，而不是在图书馆或视频录制这边。我没有问题了。很明显，刹车在我这边--别那么脆弱（你试图为自己辩护;））。但事实是，没有录像就没有这样的制动器。它们存在，但很小。在尝试未知字符数时，没有计时器如何组织事件模型？OnTick()无法让您在 "非本地 "符号上及时发现所需的事件。 因此，只能通过计时器循环浏览所有需要的符号，定义标准并发送事件。然后就可以处理事件了。 我已经想过这个问题了。无论如何，您都无法摆脱在计时器中循环浏览字符并控制所需标准的做法。而且事件处理 不需要太多时间。虽然这会稍微减轻计时器的负担。当然，我会试试的，我已经打算试试了。 Anatoli Kazharski 2017.01.03 19:53 #32 Artyom Trishkin:...在搜索未知字符数时，如何在没有计时器的情况下组织事件模型？OnTick()无法及时确定 "非本地 "字符上的所需事件。 因此，只能通过计时器循环查看所有所需字符，确定标准并发送事件。然后再处理事件。 我已经想过这个问题了。无论如何都无法摆脱在计时器中循环查看字符并控制所需标准的做法。而且事件处理 不需要太多时间。虽然这会稍微减轻计时器的负担。我当然会试试，我已经打算这么做了。录制视频时，处理过程中有多少字符？这个选项不合适吗？>>>MQL5 Recipes - Multicurrency Expert Advisor：简单、准确、快速的方案示例。如果不适合，为什么？ Реter Konow 2017.01.03 20:25 #33 Artyom Trishkin:在搜索未知字符数时，如何在没有计时器的情况下组织事件模型？OnTick()不允许您在 "非本地 "字符上及时定义所需的事件。 因此 - 只能通过循环中的计时器查看所有所需字符，定义标准并发送事件。然后再处理事件。 我已经想过这个问题了。无论如何，您都无法摆脱在计时器中循环查看字符并控制所需标准的做法。而且事件处理 不需要太多时间。虽然这会稍微减轻计时器的负担。我当然会试试--我已经打算试试了。有一次，我出于某种原因研究了进入的刻度之间的时间间隔。我在寻找一些规律。我为此花了几个星期的时间。我可以说，观察到的刻度线流动频率不高于 90-100 毫秒。如果您需要检查大量仪器的刻度线，我认为没有必要超过每 100 毫秒一次。我不认为仪器之间的 ticks 到达存在任何不同步，因此有必要将检查频率提高到最大 16 毫秒。 您可以轻松检查仪器上的刻度是否同步到达，这样就可以通过警报将总刻度频率提高到 16 毫秒。 Artyom Trishkin 2017.01.03 20:27 #34 Anatoli Kazharski:录制视频时，处理过程中有多少个字符？这种变体不合适吗？>>>MQL5 Recipes - Multicurrency Expert Advisor：简单、准确、快速方案的示例。如果不适合，为什么？涉及的符号总数约为 34 个中的 13 个 - 首先确定符号上是否存在信号，然后选择有信号的符号，这些符号参与计时器中的搜索 - 寻找价格越过所需水平的符号。我想知道为什么我需要为市场观察中的每个符号搜索一个新的条形图--如果只使用三个 tf，即日线、周线和月线，这是不可接受的资源浪费。我们需要其他算法。但还是那句话--与当前符号的刻度无关。至于建议的事件模型，我已经实践过了，但只是在图表打开的情况下。但这样一来，我就必须为每个必要的符号（事先不知道）添加一个代理，由它来发送事件，这不是需要更多 资源吗？ Anatoli Kazharski 2017.01.03 20:46 #35 Artyom Trishkin:涉及的符号总数约为 34 个中的 13 个--首先确定符号上是否存在信号，然后选择有信号的符号，这些符号参与定时器中的搜索--搜索价格越过所需水平的情况。我想知道为什么我需要在定时器中为市场观察中出现的每个符号搜索新的条形图--如果只使用三个 tf（日、周和月），这是不允许的资源浪费。我们需要其他算法。但还是那句话--与当前符号的刻度无关。至于建议的事件模型，我已经实践过了，但只是在图表打开的情况下。但这样一来，我就必须为每个必要的符号（事先不知道）添加一个代理，由它来发送事件，这不是需要更多 资源吗？我不能确定最终结果会如何。我必须进行测试。我自己也很忙，如果你做了，请稍后有空时演示一下。非常有趣。现在我正在开发一个无限制的多行输入框（CTextBox）。它几乎类似于 Windows 应用程序 "记事本"。) Artyom Trishkin 2017.01.03 20:50 #36 Anatoli Kazharski:我不能确定最终结果会如何。我得测试一下。我自己也很忙，如果你做了，请稍后有空时演示一下。非常有趣。我正在开发一个无限制的多行输入框（CTextBox）。它几乎类似于 Windows 应用程序 "记事本"。)好吧，我们拭目以待。有趣的输入框--让我们拭目以待;) Andrey Khatimlianskii 2017.01.04 17:10 #37 Artyom Trishkin:我想知道为什么我需要在计时器中为市场观察中的每个符号搜索一个新的条形图--在只使用三个 tf（日、周和月）的情况下，这是不可原谅的资源浪费。我们需要其他算法。但还是那句话--与当前符号的刻度无关。下一个条形图出现的理论时间是已知的。这对所有工具都是一样的。只有在预估时间到来时，才能在工具的工作列表中检查条形图是否真的出现。 Artyom Trishkin 2017.01.04 20:18 #38 Andrey Khatimlianskii:下一小节的理论出现时间是已知的。这对所有工具都是一样的。只有在这个预计时间到来时，您才能在工具的工作列表中查看某个条形图是否真的出现了。是的，安德烈，这是已知的。但不同的市场是不同的。在外汇市场是一回事，在股票市场则完全不同。我不想手动控制这个时间。我希望它能自行确定任何市场的新条形图，而无需指定从何时开始等待其出现。是的，并非同一市场的每个符号都会在第一个刻度线出现的同时出现新的条形图。这意味着需要等待一段时间才能在所有符号上出现新的条形图。 Andrey Khatimlianskii 2017.01.04 23:18 #39 Artyom Trishkin:是的，安德烈，这是众所周知的。但不同市场的情况不同。在外汇市场是一回事，在股票市场则完全不同。我不希望手动控制这个时间。我希望它能自行确定任何市场的新条形图，而无需指定开始等待的时间。是的，并非同一市场的每个符号都会在第一个刻度线出现的同时出现新的条形图。这就意味着，您需要等待一段时间，才能在所有符号上看到新的条形图。嗯，是的，在某处和上午 11 点可能会出现一个条形图，但从 00:00 开始检查是不可行的。那么最简单的办法就是把新条形图的检查放在单独的第二个定时器中（就我而言，这样做通常没有意义）。 Artyom Trishkin 2017.01.04 23:37 #40 Andrey Khatimlianskii:是的，某个条形图可能会在上午 11 点出现，从 00:00 开始检查是不可行的。那么最简单的方法就是将新条形图的检查放在单独的第二个定时器中（就我而言，这通常没有意义）。 在符号规格中，有报价和交易时段。也许我们应该尝试从它们....。 123456789101112 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
那就通过事件。但不是通过频率如此之高的计时器。一般来说，刹车是在你这边，而不是在图书馆或视频录制这边。我没有问题了。
很明显，刹车在我这边--别那么脆弱（你试图为自己辩护;））。但事实是，没有录像就没有这样的制动器。它们存在，但很小。
在尝试未知字符数时，没有计时器如何组织事件模型？OnTick()无法让您在 "非本地 "符号上及时发现所需的事件。
因此，只能通过计时器循环浏览所有需要的符号，定义标准并发送事件。然后就可以处理事件了。
我已经想过这个问题了。无论如何，您都无法摆脱在计时器中循环浏览字符并控制所需标准的做法。而且事件处理 不需要太多时间。虽然这会稍微减轻计时器的负担。当然，我会试试的，我已经打算试试了。
...
在搜索未知字符数时，如何在没有计时器的情况下组织事件模型？OnTick()无法及时确定 "非本地 "字符上的所需事件。
因此，只能通过计时器循环查看所有所需字符，确定标准并发送事件。然后再处理事件。
我已经想过这个问题了。无论如何都无法摆脱在计时器中循环查看字符并控制所需标准的做法。而且事件处理 不需要太多时间。虽然这会稍微减轻计时器的负担。我当然会试试，我已经打算这么做了。
录制视频时，处理过程中有多少字符？
这个选项不合适吗？>>>MQL5 Recipes - Multicurrency Expert Advisor：简单、准确、快速的方案示例。如果不适合，为什么？
在搜索未知字符数时，如何在没有计时器的情况下组织事件模型？OnTick()不允许您在 "非本地 "字符上及时定义所需的事件。
因此 - 只能通过循环中的计时器查看所有所需字符，定义标准并发送事件。然后再处理事件。
我已经想过这个问题了。无论如何，您都无法摆脱在计时器中循环查看字符并控制所需标准的做法。而且事件处理 不需要太多时间。虽然这会稍微减轻计时器的负担。我当然会试试--我已经打算试试了。
有一次，我出于某种原因研究了进入的刻度之间的时间间隔。我在寻找一些规律。我为此花了几个星期的时间。我可以说，观察到的刻度线流动频率不高于 90-100 毫秒。
如果您需要检查大量仪器的刻度线，我认为没有必要超过每 100 毫秒一次。我不认为仪器之间的 ticks 到达存在任何不同步，因此有必要将检查频率提高到最大 16 毫秒。
您可以轻松检查仪器上的刻度是否同步到达，这样就可以通过警报将总刻度频率提高到 16 毫秒。录制视频时，处理过程中有多少个字符？
这种变体不合适吗？>>>MQL5 Recipes - Multicurrency Expert Advisor：简单、准确、快速方案的示例。如果不适合，为什么？
涉及的符号总数约为 34 个中的 13 个 - 首先确定符号上是否存在信号，然后选择有信号的符号，这些符号参与计时器中的搜索 - 寻找价格越过所需水平的符号。
我想知道为什么我需要为市场观察中的每个符号搜索一个新的条形图--如果只使用三个 tf，即日线、周线和月线，这是不可接受的资源浪费。我们需要其他算法。但还是那句话--与当前符号的刻度无关。
至于建议的事件模型，我已经实践过了，但只是在图表打开的情况下。但这样一来，我就必须为每个必要的符号（事先不知道）添加一个代理，由它来发送事件，这不是需要更多 资源吗？
涉及的符号总数约为 34 个中的 13 个--首先确定符号上是否存在信号，然后选择有信号的符号，这些符号参与定时器中的搜索--搜索价格越过所需水平的情况。
我想知道为什么我需要在定时器中为市场观察中出现的每个符号搜索新的条形图--如果只使用三个 tf（日、周和月），这是不允许的资源浪费。我们需要其他算法。但还是那句话--与当前符号的刻度无关。
至于建议的事件模型，我已经实践过了，但只是在图表打开的情况下。但这样一来，我就必须为每个必要的符号（事先不知道）添加一个代理，由它来发送事件，这不是需要更多 资源吗？
我不能确定最终结果会如何。我必须进行测试。我自己也很忙，如果你做了，请稍后有空时演示一下。非常有趣。
现在我正在开发一个无限制的多行输入框（CTextBox）。它几乎类似于 Windows 应用程序 "记事本"。)
我不能确定最终结果会如何。我得测试一下。我自己也很忙，如果你做了，请稍后有空时演示一下。非常有趣。
我正在开发一个无限制的多行输入框（CTextBox）。它几乎类似于 Windows 应用程序 "记事本"。)
好吧，我们拭目以待。
有趣的输入框--让我们拭目以待;)
我想知道为什么我需要在计时器中为市场观察中的每个符号搜索一个新的条形图--在只使用三个 tf（日、周和月）的情况下，这是不可原谅的资源浪费。我们需要其他算法。但还是那句话--与当前符号的刻度无关。
下一个条形图出现的理论时间是已知的。这对所有工具都是一样的。
只有在预估时间到来时，才能在工具的工作列表中检查条形图是否真的出现。
下一小节的理论出现时间是已知的。这对所有工具都是一样的。
只有在这个预计时间到来时，您才能在工具的工作列表中查看某个条形图是否真的出现了。
是的，安德烈，这是已知的。但不同的市场是不同的。在外汇市场是一回事，在股票市场则完全不同。我不想手动控制这个时间。我希望它能自行确定任何市场的新条形图，而无需指定从何时开始等待其出现。
是的，并非同一市场的每个符号都会在第一个刻度线出现的同时出现新的条形图。这意味着需要等待一段时间才能在所有符号上出现新的条形图。
是的，安德烈，这是众所周知的。但不同市场的情况不同。在外汇市场是一回事，在股票市场则完全不同。我不希望手动控制这个时间。我希望它能自行确定任何市场的新条形图，而无需指定开始等待的时间。
是的，并非同一市场的每个符号都会在第一个刻度线出现的同时出现新的条形图。这就意味着，您需要等待一段时间，才能在所有符号上看到新的条形图。
嗯，是的，在某处和上午 11 点可能会出现一个条形图，但从 00:00 开始检查是不可行的。
那么最简单的办法就是把新条形图的检查放在单独的第二个定时器中（就我而言，这样做通常没有意义）。
是的，某个条形图可能会在上午 11 点出现，从 00:00 开始检查是不可行的。
那么最简单的方法就是将新条形图的检查放在单独的第二个定时器中（就我而言，这通常没有意义）。