来自一个 "傻瓜 "的问题 - 页 176 1...169170171172173174175176177178179180181182183...277 新评论 Yedelkin 2012.08.31 15:20 #1751 Karlson:3Б.通过打开半卖出的方式部分关闭--OUT。 太糟糕了 :/ 事实证明,在历史上可以有几笔具有OUT属性的交易,而头寸仍会存在。 Anatoli Kazharski 2012.08.31 15:24 #1752 Yedelkin: 坏:/ 为什么不好?这很简单,如果我没有理解错的话。如果是OUT,并且有一个位置,那么就有一个量的减少。如果OUT而没有位置,则表示位置被完全关闭。 Yedelkin 2012.08.31 15:59 #1753 tol64: 为什么不好呢?一切都很简单,如果我没有理解错的话。如果有一个位置和OUT,就有一个量的减少。如果OUT,并且没有位置,则说明位置被完全关闭。不好的事情是这样的。你的做法是"如果OUT了,有了位置,就有了量的减少。如果没有OUT,也没有位置,那么这个位置就被完全关闭了。"有一个特点,我觉得很麻烦,就是每次都需要额外检查终端数据库中是否存在位置信息。 我们都知道,基地终端的信息与实际情况相比有一定的滞后性。因此,我们不能排除这样的情况,即检查结果是"有一个头寸,并且是OUT",但事实上该头寸已经被关闭。换句话说,人们有可能收到不准确的信息,并以此作为采取错误行动的依据。 或者人们将不得不发明额外的检查、延迟或任何方便的东西。但你可以不使用所有这些技巧。特别是,没有检查职位的可用性。要做到这一点,只需在平仓和DEAL_ENTRY_OUT 属性之间保持一对一的对应关系(对应关系--现在《手册》中的表述),并将减仓量分配到一个单独的交易属性 中。然后就可以在历史记录(HistorySelectByPosition)中找到一个属性为DEAL_ENTRY_OUT 的交易,并保证该仓位没有减少,而是完全关闭,而且在任何情况下都不会被逆转。 Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок www.mql5.com Стандартные константы, перечисления и структуры / Торговые константы / Свойства сделок - Документация по MQL5 Anatoli Kazharski 2012.08.31 16:22 #1754 Yedelkin:不好的事情是这样的。你的做法是"如果OUT了,有了位置,就有了量的减少。如果没有OUT,也没有仓位,那么仓位就被完全关闭了。"有一个特点,我觉得很麻烦,就是每次都要额外检查终端数据库中的仓位信息。 我们都知道,基地终端的信息与实际情况相比有一定的滞后性。因此,我们不能排除这样的情况,即检查结果是"有一个头寸,而且是OUT",但实际上该头寸已经被完全关闭。换句话说,有可能获得不准确的信息,并将其作为采取错误行动的依据。 或者人们将不得不发明额外的检查、延迟或任何方便的东西。但你可以不使用所有这些技巧。特别是,没有检查职位的可用性。要做到这一点,只需在平仓和DEAL_ENTRY_OUT 属性之间保持一对一的对应关系(对应关系--现在《手册》中的表述),并将减仓量分配到一个单独的交易属性 中。那么在历史记录(HistorySelectByPosition)中找到一个属性为DEAL_ENTRY_OUT的 交易就足够了,并且可以确定该仓位没有减少,而是完全关闭,而且在任何情况下都不能被逆转。在OnTrade()中,我们收到来自服务器的响应。也就是说,如果我们在OnTrade()中检查事件,我们就已经确定是否有一个头寸了。尽管我们可以提供标准选项,如DEAL_ENTRY_FULLOUT(完全关闭)或DEAL_ENTRY_PARTOUT(部分关闭),使一切都变得完美优雅。)))同时,你可以制作单独的函数,这样你就不必每次都引入 "繁琐的检查"。 Yedelkin 2012.08.31 17:44 #1755 tol64:尽管你可以做一些标准的选项,如DEAL_ENTRY_FULLOUT或DEAL_ENTRY_PARTOUT,让一切都变得完美优雅。))) 这就是事情的真相。我们甚至不需要在OnTrade中进行额外的检查,因为与提议的解决方案(FULLOUT/PARTOUT)相比,OnTrade的检查显得过于繁琐。 Anatoli Kazharski 2012.08.31 17:58 #1756 Yedelkin: 这就是问题的关键...你甚至不必在OnTrade中做额外的检查,与提议的解决方案(FULLOUT / PARTOUT)相比,这仍然显得很麻烦。 尝试向服务台提出建议。也许他们会考虑这个问题,并在某一天实施。 Yedelkin 2012.08.31 18:57 #1757 tol64: 尝试向服务台提出建议。也许他们会考虑这个问题,并在某一天实施。 我已经做了 :)作为一个语言错误......哇,我花了一个小时才写好。 Anatoli Kazharski 2012.08.31 19:04 #1758 Yedelkin: 我已经做了 :)作为一个口误......哇,我花了一个小时才写好。 这仍然不能被称为一个错误。但你现在能做什么呢,你已经被派去了。)) Yedelkin 2012.08.31 19:09 #1759 tol64: 这仍然不能被称为一个错误。但是,既然你已经被派来了,你能做什么呢。)) 好吧,这就是评价类别发挥了一点作用的地方 :)我试图证明错误类别的合理性 :) Валерий 2012.09.01 01:21 #1760 Yedelkin: 是的,每个时期都对应着一定的数值。几年前有人在论坛上发过这个帖子。你可以通过运行下面这样的线路来自己找出答案。该脚本将 以十进制系统打印 所有时期的ENUM_TIMEFRAMES值。void OnStart() { //--- for(int i=(int)PERIOD_CURRENT;i<=(int)PERIOD_MN1;i++) { ResetLastError(); string period=EnumToString((ENUM_TIMEFRAMES)i); if(GetLastError()) continue; Print(EnumToString((ENUM_TIMEFRAMES)i)+"="+IntegerToString(i)); } } //+------------------------------------------------------------------+ 1...169170171172173174175176177178179180181182183...277 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
3Б.通过打开半卖出的方式部分关闭--OUT。
坏:/
为什么不好呢?一切都很简单,如果我没有理解错的话。如果有一个位置和OUT,就有一个量的减少。如果OUT,并且没有位置,则说明位置被完全关闭。
不好的事情是这样的。你的做法是"如果OUT了,有了位置,就有了量的减少。如果没有OUT,也没有位置,那么这个位置就被完全关闭了。"有一个特点,我觉得很麻烦,就是每次都需要额外检查终端数据库中是否存在位置信息。
我们都知道,基地终端的信息与实际情况相比有一定的滞后性。因此,我们不能排除这样的情况,即检查结果是"有一个头寸,并且是OUT",但事实上该头寸已经被关闭。换句话说,人们有可能收到不准确的信息,并以此作为采取错误行动的依据。 或者人们将不得不发明额外的检查、延迟或任何方便的东西。
但你可以不使用所有这些技巧。特别是,没有检查职位的可用性。要做到这一点,只需在平仓和DEAL_ENTRY_OUT 属性之间保持一对一的对应关系(对应关系--现在《手册》中的表述),并将减仓量分配到一个单独的交易属性 中。然后就可以在历史记录(HistorySelectByPosition)中找到一个属性为DEAL_ENTRY_OUT 的交易,并保证该仓位没有减少,而是完全关闭,而且在任何情况下都不会被逆转。
不好的事情是这样的。你的做法是"如果OUT了,有了位置,就有了量的减少。如果没有OUT,也没有仓位,那么仓位就被完全关闭了。"有一个特点,我觉得很麻烦,就是每次都要额外检查终端数据库中的仓位信息。
我们都知道,基地终端的信息与实际情况相比有一定的滞后性。因此,我们不能排除这样的情况,即检查结果是"有一个头寸,而且是OUT",但实际上该头寸已经被完全关闭。换句话说,有可能获得不准确的信息,并将其作为采取错误行动的依据。 或者人们将不得不发明额外的检查、延迟或任何方便的东西。
但你可以不使用所有这些技巧。特别是,没有检查职位的可用性。要做到这一点,只需在平仓和DEAL_ENTRY_OUT 属性之间保持一对一的对应关系(对应关系--现在《手册》中的表述),并将减仓量分配到一个单独的交易属性 中。那么在历史记录(HistorySelectByPosition)中找到一个属性为DEAL_ENTRY_OUT的 交易就足够了,并且可以确定该仓位没有减少,而是完全关闭,而且在任何情况下都不能被逆转。
在OnTrade()中,我们收到来自服务器的响应。也就是说,如果我们在OnTrade()中检查事件,我们就已经确定是否有一个头寸了。尽管我们可以提供标准选项,如DEAL_ENTRY_FULLOUT(完全关闭)或DEAL_ENTRY_PARTOUT(部分关闭),使一切都变得完美优雅。)))
同时,你可以制作单独的函数,这样你就不必每次都引入 "繁琐的检查"。尽管你可以做一些标准的选项,如DEAL_ENTRY_FULLOUT或DEAL_ENTRY_PARTOUT,让一切都变得完美优雅。)))
这就是问题的关键...你甚至不必在OnTrade中做额外的检查,与提议的解决方案(FULLOUT / PARTOUT)相比,这仍然显得很麻烦。
尝试向服务台提出建议。也许他们会考虑这个问题,并在某一天实施。
我已经做了 :)作为一个口误......哇,我花了一个小时才写好。
这仍然不能被称为一个错误。但是,既然你已经被派来了,你能做什么呢。))
是的,每个时期都对应着一定的数值。几年前有人在论坛上发过这个帖子。你可以通过运行下面这样的线路来自己找出答案。
该脚本将 以十进制系统打印 所有时期的ENUM_TIMEFRAMES值。