自定义符号。误差、错误、问题、建议。 - 页 27

新评论
 
Stanislav Korotky:

在一个空的新的自定义符号上添加一对一的ticks（特别是来自MQ Demo上的EURUSD）会出现错误5310（不是立即出现，而是在一个任意日期的循环中）。

怎么了？我如何知道哪些具体的蜱虫被骂？将数组放入日志--那里没有违反时间顺序。

尝试插入检查蜱虫的复制。
我有一个指标在tick处理中的实时数据，当复制CopyClose时，有时会触发复制错误。
我不明白可能是什么原因。也许在你的情况下，有一个复制错误。

另外，在CopyTicks中，你复制了大量的ticks Limit，然后在while循环中，即每一次迭代你都会复制一个大的ticks阵列。
而在CustomTicksAdd中，你向数组传递同样多的ticks。
尝试复制一个刻度，并通过一个刻度。
你是在一个while循环中运行。

input int Limit = 10000;
input datetime Start = D'2020.06.01';

int fillArray(ulong &_start)
{
  MqlTick array[];
  int size = CopyTicks(_Symbol, array, COPY_TICKS_ALL, _start, Limit);

  if(size <= 0) 
  {
     Print("Ошибка копирования ценовых данных "+_Symbol+" "+(string)size+" ",GetLastError());
     return(size);
  }

  if(size > 0)
  {
    _start = array[size - 1].time_msc + 1;
    if(CustomTicksAdd(symbolName, array) == -1)
    {
      Print("Error:", GetLastError());
      return(-1);
    }
  }
  return(size);
}

...
{
  ulong startMsc = (ulong)Start * 1000;
  while(fillArray(startMsc) > 0);
}
已添加。与自定义符号无关。

互联网连接被切断了几秒钟，连接后出现了复制错误4401所要求的历史记录没有找到
 很奇怪，M5周期还没有变成新的柱状，但错误却出现了。
 
Roman:

试着插入检查复制的蜱虫。
在我的指标中，在tick处理的实时数据上，当复制CopyClose时，有时会发生复制错误。
我不明白可能是什么原因。也许在你的情况下，有一个复制错误。

另外，在CopyTicks中，你复制了大量的ticks Limit，然后在while循环中，即每一次迭代你都会复制一个大的ticks阵列。
而在CustomTicksAdd中，你向数组传递同样多的ticks。
试着复制一个刻度，并传递一个刻度。

没有复制错误，代码得到的是复制的点数（大小）的正常值，数组一直被正常的数据填充。极限值可以改变，但从1到几千的任何有意义的值都会发生错误。一次性复制所有刻度线（如某些代码）显然是错误的，因为它可能导致内存分配 错误，并将线程锁定很长时间而无法向用户显示进度。而以10个小批量（更不用说1个）复制蜱虫，会使整个过程变慢--这是不可接受的。

建议的变体是最佳的。即使对某人来说是有争议的，正式的代码是正确的（或举出我错在哪里），目前的行为是错误的，即必须在没有代码5310的情况下增加刻度线。

此外，在清除蜱虫数据库方面仍有一个长期存在的问题。调用CustomTicksDelete(symbolName, 0, LONG_MAX)；不想删除所有的ticks，而留下一些（观察到的不是持续的，而是大约一段时间一次）。如果你重新启动专家顾问，自定义符号会被完全清除。与CopyTicks的情况一样--没有错误。

 
如果你想在不产生更多OnTick事件的情况下编写ticks，使用不同的函数可能会更好。
 
Stanislav Korotky:

也许在包的交界处有相同毫秒的蜱虫，这算作一个错误？

只是一个猜测

 
Andrey Khatimlianskii:

也许在包的交界处有相同毫秒的蜱虫，这算作一个错误？

只是一种猜测。

你可以从代码 中看到，有重复的刻度线。在这种情况下，刻度线的标志可能不相互对应。

 
fxsaber:
如果你需要在不产生更多OnTick事件的情况下写入ticks，你可能最好使用一个不同的函数。

我同意。我会试一试的。但我认为目前的方法没有理由不奏效。

 
Stanislav Korotky:

没有复制错误，代码得到的是复制的点数（大小）的正常值，数组一直被正常的数据填充。极限值可以改变，但从1到几千的任何有意义的值都会发生错误。一次性复制所有刻度线（如某些代码）显然是错误的，因为它可能导致内存分配 错误，并将线程锁定很长时间而无法向用户显示进度。而以10个为单位的小批量复制蜱虫（更不用说1个了），会使整个过程变慢。

建议的变体是最佳的。即使有人质疑，正式的代码是正确的（或举出我错的地方），目前的行为是错误的，即必须在没有代码5310的情况下添加刻度线。

此外，在清除蜱虫数据库方面仍有一个长期存在的问题。调用CustomTicksDelete(symbolName, 0, LONG_MAX)；不想删除所有的ticks，而留下一些（观察到的不是持续的，而是大约一段时间一次）。如果你重新启动专家顾问，自定义符号会被完全清除。与CopyTicks的情况一样--没有错误。

err_custom_ticks_wrong_order

5310

不 按时间排序的刻度线阵列


有可能你没有时间大批量地删除蜱虫，因为你在下一次迭代中会覆盖已经存在的蜱虫。
也就是说，它们作为一个阵列相互叠加，而它的飞行没有延迟，所以当另一个包到达时，内存没有时间被清除。
这就是为什么我建议一次添加一个勾，我一次复制一个勾，没有问题。

至于清除ticks数据库，在这种情况下我不喜欢恒定的LONG_MAX。
CustomTicksDelete函数的帮助说，要删除指定范围内的价格历史中最后一个tick的时间。
而LONG_MAX比这个值大得多，是自01.01.1970以来的时间，以毫秒 计。也就是说，传递了一个更大的值，而这个参数并不是为其设计的。
尽量使用与毫秒数位相对应的数字，即13值。

 
fxsaber:

你可以从代码 中看到，有重复的刻度线。在这种情况下，蜱虫的基本标志可能不对应。

接收数组中的重复刻度是CopyTicks吗？如何明确这些是重复的蜱虫，而不是相同的蜱虫（蜱虫毕竟没有唯一的标识符）？即使有重复的，在理论上，具有相同截止点的刻度线也不会破坏序列。最后，问题来了--复制体是如何形成的？

 
Roman:

err_custom_ticks_wrong_order

5310

时间数组不 按时间排序


有可能是大包小包的蜱虫没有时间被删除，因为你在下一次迭代中覆盖了你已经有的蜱虫。
也就是说，它们作为一个阵列相互叠加，而它的飞行没有延迟，所以当另一个包到达时，内存没有时间被清除。
这就是为什么我建议一次添加一个勾，我一次复制一个勾，没有任何问题。

没有一个字是关于删除的，没有任何东西被覆盖。迭代的时间是不重叠的。总是在一个空的自定义字符中--要么是一个新的字符，要么是在成功地删除了所有刻度线之后。

 
Stanislav Korotky:

接收数组CopyTicks中的重复刻度？如何明确这些是重复的蜱虫，而不是相同的蜱虫（蜱虫毕竟没有唯一的标识符）？即使有重复的，在理论上，具有相同截止点的刻度线也不会破坏序列。最后，一个问题出现了--复制体是如何形成的？

我更仔细地看了代码。当你分批收到的时候，你就会错过蜱虫。可能有一种情况，当Ticks[Limit - 1].time_msc == Ticks[Limit + k], k >= 0。

因此，当你用跳过的方式添加时，标志可能不匹配。


确保所有具有相同时间的历史刻度都在该部分的最后。也就是说，下一块的开始应该有一个不同的时间。否则，即使写给客户，也会有损失。

如果你想使用CopyTicks，最简单的方法是丢弃所收到的数据包中时间最长的最极端的ticks。并使_start等于这个时间。
1...202122232425262728293031323334
新评论