我的方法。核心是引擎。 - 页 165 1...158159160161162163164165166167168169170171172...184 新评论 Nikolai Semko 2019.01.31 13:24 #1641 Dmitry Fedoseev:我想是的。但如果是GUI,那就是另一个文件,这在市场上是不可能的。 也许是这样。我不知道。但我认为这个问题是可以解决的,如果皮奥特有价值的东西。你需要向市场发送一个文件,你不需要发送引擎,没有引擎也可以工作。彼得,还是我误解了什么? Реter Konow 2019.01.31 13:36 #1642 Nikolai Semko: 也许.我不知道。但我认为如果彼得有价值的东西,这个问题是可以解决的。你需要向市场发送一个文件,你不需要发送引擎,没有引擎也可以工作。皮奥特,还是我理解错了什么?你说对了,尼古拉。专家顾问的工作没有引擎。一旦EA被放置在一个单独的图表上,引擎就会创建EA的GUI,并接收来自它的指令。该引擎可以在不同的EA之间切换。当切换时,它只是从一个文本文件中重新加载另一个核心。它可以完全留在原地,但要分配一个单独的图表,并随时保持在那里。 Реter Konow 2019.01.31 13:53 #1643 有一个想法是让用户不必到处拖着内核文件让引擎下载。当产生一个GUI时,构造函数产生一个内核文件。而不是保存到文件中,构造函数可以将内核保存到一个资源中,并在常规属性文件中为该资源写入一个连接字符串。当用户连接创建的Connexion Properties文件时,这个资源与内核将在初始化他们的EA时被整合。此外,当连接到引擎时,后者将简单地从EA读取带有内核的资源并播放GUI。因此,将不需要与内核一起拖动文件。 Vasiliy Sokolov 2019.01.31 14:19 #1644 Maxim Kuznetsov: 根据目前的规则,具有额外依赖性的产品不能通过市场分发。此外,我怀疑这在法律上是被禁止的或相当困难的。不能使用外部ex*库,包括那些不包含对dll调用的库。然而,指标,如彼得的引擎,不受此限制。 Maxim Kuznetsov 2019.01.31 15:51 #1645 Vasiliy Sokolov:不能使用外部ex*库,包括那些不包含对dll调用的库。然而,这一限制并不适用于指标,如彼得的引擎。我是通过询问服务台市场对这个问题特别感兴趣。答案很清楚,虽然不是很高兴:-)市场的产品必须是一个本身的东西,不需要安装任何其他组件。所有必要的指标和库都应该通过资源部挤在里面。 这是符合逻辑的--一个人买了一个产品,这个产品(以及它的所有主张)应该立即可以得到,而不需要额外的工作。 也不存在某些依赖性被更新,但专家顾问掉线的情况:-) Renat Akhtyamov 2019.01.31 17:04 #1646 而在一般情况下,交易是。 我的收入 - "核心 - 引擎";) Nikolai Semko 2019.01.31 17:12 #1647 Реter Konow: 有一个想法是让用户不必到处拖动内核文件,以便引擎能够上传它。当产生一个GUI时,构造函数产生一个内核文件。而不是保存到文件中,构造函数可以将内核保存到一个资源中,并在内核属性文件中写一个字符串来连接这个资源。当用户连接创建的Connexion Properties文件时,这个资源与内核将在初始化他们的EA时被整合。此外,当连接到引擎时,后者将简单地从EA读取带有内核的资源并播放GUI。因此,将不需要拖动内核文件。 哦,伙计,我还以为是这样实施的呢。当然,随身携带配置文件的意义何在?想象一下,彼得,你也可以把引擎塞进一个普通的ex*文件,作为一个类。也没有六翼七*的人:)) Реter Konow 2019.01.31 17:20 #1648 Nikolai Semko: 哦,天哪,我以为它是以你的方式实施的。当然,随身携带你的配置文件有什么意义呢。想象一下,彼得,你也可以把引擎塞进一个普通的ex*文件,作为一个类。也没有六翼七*的人:))你能更详细地描述一下吗?如何、什么和为什么。 Реter Konow 2019.01.31 17:30 #1649 Nikolai Semko:...想象一下,彼得,你也可以把引擎塞进一个普通的ex*文件,作为一个类。...尼古拉,如果你建议开放引擎代码,让大家把它放在EA中,那么我想过了。唉,这将使发动机的发展受到限制。一切都将发生在一个单一的应用线程中,这将限制所使用的资源,而且通过并行化计算所能实现的大部分好处都将丧失。此外,用户将开始对引擎进行修改,并分发修改后的版本,这将造成混乱和新的开发问题。 因此,这个想法在理论上是好的,但在实践中,唉......(。 Nikolai Semko 2019.01.31 19:59 #1650 Реter Konow:尼古拉,如果你建议开放引擎代码,让大家把它放在EA中,那么我想过了。唉,这将使发动机的发展受到限制。一切都将发生在一个单一的应用线程中,这将限制所使用的资源,而且通过并行化计算所能实现的大部分好处都将丧失。此外,用户将开始对引擎进行修改,并分发修改后的版本,这将造成混乱和新的开发问题。 因此,这个想法在理论上是好的,但在实践中,唉......(。 彼得,证据在哪里?哪里有研究报告比较一个程序在一个ex5线程(甚至没有必要用ex4做实验)和两个线程的执行速度?这只是一个假设性的推测,顺便说一下,这是我(在这里)第一次陈述,当时我没有设法从你那里得到至少一个关于你的方法的优点的表述。你已经把这个假设当作事实来践行了。我个人承认可能会有优势,但纯粹根据直觉(不是根据知识),我打赌75%的人不会有任何优势,因为两个程序之间的互动和数据交换是不自由的,而且两个ex5的处理器是一个。但这个问题的答案只能由开发者自己或定性的实验来给出。 1...158159160161162163164165166167168169170171172...184 新评论 您错过了交易机会: 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符(不带空格) 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号,请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置,否则您将无法登录。 忘记您的登录名/密码? 使用 Google 登录
我想是的。但如果是GUI,那就是另一个文件,这在市场上是不可能的。
也许.我不知道。但我认为如果彼得有价值的东西,这个问题是可以解决的。
你说对了,尼古拉。专家顾问的工作没有引擎。一旦EA被放置在一个单独的图表上,引擎就会创建EA的GUI,并接收来自它的指令。该引擎可以在不同的EA之间切换。当切换时,它只是从一个文本文件中重新加载另一个核心。它可以完全留在原地,但要分配一个单独的图表,并随时保持在那里。
根据目前的规则,具有额外依赖性的产品不能通过市场分发。此外,我怀疑这在法律上是被禁止的或相当困难的。
不能使用外部ex*库,包括那些不包含对dll调用的库。然而,指标,如彼得的引擎,不受此限制。
不能使用外部ex*库,包括那些不包含对dll调用的库。然而,这一限制并不适用于指标,如彼得的引擎。
我是通过询问服务台市场对这个问题特别感兴趣。答案很清楚,虽然不是很高兴:-)市场的产品必须是一个本身的东西,不需要安装任何其他组件。所有必要的指标和库都应该通过资源部挤在里面。
这是符合逻辑的--一个人买了一个产品,这个产品(以及它的所有主张)应该立即可以得到,而不需要额外的工作。
也不存在某些依赖性被更新,但专家顾问掉线的情况:-)
而在一般情况下,交易是。
我的收入 - "核心 - 引擎"
;)有一个想法是让用户不必到处拖动内核文件,以便引擎能够上传它。当产生一个GUI时,构造函数产生一个内核文件。而不是保存到文件中,构造函数可以将内核保存到一个资源中,并在内核属性文件中写一个字符串来连接这个资源。当用户连接创建的Connexion Properties文件时,这个资源与内核将在初始化他们的EA时被整合。此外,当连接到引擎时,后者将简单地从EA读取带有内核的资源并播放GUI。因此,将不需要拖动内核文件。
哦,天哪,我以为它是以你的方式实施的。当然,随身携带你的配置文件有什么意义呢。
你能更详细地描述一下吗?如何、什么和为什么。
...
尼古拉,如果你建议开放引擎代码,让大家把它放在EA中,那么我想过了。唉,这将使发动机的发展受到限制。一切都将发生在一个单一的应用线程中,这将限制所使用的资源,而且通过并行化计算所能实现的大部分好处都将丧失。此外,用户将开始对引擎进行修改,并分发修改后的版本,这将造成混乱和新的开发问题。
因此,这个想法在理论上是好的,但在实践中,唉......(。
尼古拉,如果你建议开放引擎代码,让大家把它放在EA中,那么我想过了。唉,这将使发动机的发展受到限制。一切都将发生在一个单一的应用线程中,这将限制所使用的资源,而且通过并行化计算所能实现的大部分好处都将丧失。此外,用户将开始对引擎进行修改,并分发修改后的版本,这将造成混乱和新的开发问题。
因此,这个想法在理论上是好的,但在实践中,唉......(。