Если в MT изменить таймфрейм или имя символа чарта, то все индикаторы на чарте выгрузятся с чарта и загрузятся на него снова. При этом, в отличие от MT4, в MT5 последовательность выгрузиться/загрузиться не определена из-за особенности внутренней архитектуры. Данное обстоятельство иногда вызывает не сразу очевидные проблемы, связанные с тем, что...
那么,有了这样的结构,就有可能有非常快的指标?
更有可能的是,OnCalculate不会在每个tick 上被调用,而是在一包tick之后。
如果是这样,这是个好消息。
我们有一个想法,对于不包含#property tester_everytick_calculate标志的指标,包括基于收到一包ticks的计算模式,而不是基于每一个tick。
这将从根本上解决指标迟缓的问题,保留了对某些指标的每个tick进行保证处理的可能性。
我提出另一个解决方案。
符号InfoTick
返回一个MqlTick类型的变量中指定符号的当前价格。
参数
返回的值
那么在OnCalculate中,只需写出以下结构即可
这种解决方案在使用和实施上会更加灵活和方便。
SZY 最好能有刻度线的编号,并能得到当前和指标刻度线的编号。但这种变体对开发者来说更加困难。因此,可能没有必要。
我建议另一个解决方案。
如果开发商什么都不做(顺便说一句,这是一个非常好的选择),仍然可以通过这种方式绕过所有的刹车系统
如果开发者什么都不做(顺便说一句,这是一个非常好的选择),现在可以通过这种方式绕过所有的刹车系统
好吧,我们不需要条形中间的刻度,反正它们被强制跳过了。让我们等待mql的实施。
好吧,我们不需要条形中间的刻度,反正它们被强制跳过了。让我们等待mql的实现。
说实话,我不明白,是什么阻碍了患者自己写出解决问题的方法?
以及为什么开发者应该在这里改变一些东西?
该方案可以作为一个mqh-文件实现,并连接到任何指标,因为它是在Init_Sync 中实现的。但这需要大量的代码,不是很明显。而这里只有几行字。
重新连接通信后冻结更新别人的隐形时间段的问题得到了整理和修复。原因是重新连接后的缓存状态不正确。
测试版1946年可通过帮助->检查桌面更新->最新测试版。
Rinat,3天的测试没有问题,谢谢!
说实话,我不明白是什么阻碍了患者自己写出解决问题的方法?
而开发商为什么要在这里改变一些东西呢?
患病者不能以任何方式改变指标中传入的点数,他们在指标中跳过这些点数,直到一个新的条形图,如果指标计数的时间很长,无论如何都会跳过这些点数。不知何故,我们必须适应现实。
如果一个符号的峰值是每分钟~800次,那么几个符号的合成就已经是每分钟2300次了。打开一个合成和一个符号,每分钟达到~3000次的峰值。再加上另一个相同的合成时间框架和相同的符号,我们就得到了...好吧,Elder的屏幕是三个,我们每分钟得到~9000次,或每秒钟150次。Rinat已经写过关于性能问题的文章。当你需要每分钟为所有的tf符号提供1-n个刻度时,为什么要通过一个多符号-mtf指标每秒空闲的150个刻度?同样,托管mql的好处包括没有来自主机系统的开销,终端是同一个主机,只用于指标和EA。如果指标计算 由RSI(3)+EMA(5)+EMA(7)组成,那么在未来10年内当然没有问题。
在合成(实际上是一个来自终端的多符号指标)中,开发人员不知不觉地想出了粘贴一些符号的想法,为什么我们要在指标中以程序员的手艺水平复制这个系统的元素(让我们假设它甚至不完美)?如果系统可以简化,为什么不这样做?当地球还站在三只大象上的时候,5秒钟的计时器不是白发明的。
你可以引入没有历史记录的时间框架5秒,并且5秒内仅有一次点击,并测试各种解决方案(用一些前缀编译一个只在5S上工作的指标,其他指标不会在其上运行)--终端的现有意识形态不会改变,因此我们可以改变和修改解决方案,最佳/最优解决方案将在测试中形成。
(LMS到你的开发库、合成器、分离窗口等。开发人员)。
即使每分钟有一百万次点击,这也不会使解决方案 不可行。
每分钟一百万次点击并不会使解决方案 不可行。
这个问题不是关于解决方案的可操作性。在每一个达到的刻度线上调用指标的合理性,在这之前有一个未知的刻度线被错过,此外,一个刻度线的一些过时被考虑?如果有些东西被跳过(随着负载的增加),并且不知道打勾的相关性,那么这种情况并不能解决分析问题--如果不能,那么为什么要费心思去做呢。一般来说,禁止流向指标,每5秒从平台上留出指标一次--每分钟12次,这就足够了。
这个问题不是关于解决方案的可操作性。在每个达到的刻度线上调用指标的合理性,在这之前,除了一些过时的刻度线被认为是?如果有些东西被跳过(随着负载的增加),并且不知道打勾的相关性,那么这种情况并不能解决分析问题--如果不能,为什么要费心思去做。在一般情况下,应该禁止流向指标,每5秒从平台上传来的刻度应该被留下 - 每分钟12个刻度,这就足够了。
愚蠢的行为。