在图形模式下为MQL创建一个GUI。 - 页 10 1...3456789101112131415 新评论 Алексей Барбашин 2018.06.22 20:42 #91 Renat Fatkhullin: 从μl、pips、文件或网络查询进行单向轮询。我们不能使用反向的直接呼叫。虽然我们可以添加一个像OnExternal这样的带参数的方法，但我们需要考虑到传输通道。它可以是。- 一个带有参数的callbucket，在dll中注册。- 命名的mutex作为一个触发器- 窗口信息为PostMessage我相信那会是很好的!我们不是在谈论向MT发送什么。转移本身可以以任何其他方式进行。重要的是要告诉MT，需要执行一些行动。这与你所开发的GUI库中的情况完全一样：所有的colbecs都是通过事件完成的。 顺便说一下，关于这个库：你打算扩大它并将它完全翻译成画布吗？也就是说，最终的 "产品 "不是一组图表对象，而是一个完整的画面。 在审查dll方面，我当然希望能够将dll作为MT的资源，这样我就不必将它们与专家顾问或指标一起 "拖 "出来。 Алексей Барбашин 2018.06.22 20:47 #92 Renat Fatkhullin: 为什么要在dotnet上做gui？简单的表格可以很容易地用C++和其他语言制作。而且不会有接口和资源损失的问题。而在MQL5中，用本地语言制作界面是绝对容易的。问题不在于GUI。使用MT工具可以很容易地创建这些界面。当然，这有点复杂，需要创建自己的处理类，但一切都可以解决。我开始用网络工作，因为不可能实现一些互联网工作的算法。在C++中是相当复杂和不稳定的，即使是母语，更不用说MT了。一旦我掌握了net，我也可以开始使用GUI，因为一切都为它准备好了，不像在MT。在任何语言的应用开发的开放问题中，即在任何，因为这些问题与网无关：1。反馈，2。将GUI连接到图表(https://www.mql5.com/ru/forum/103764)--是其中一个主题。 Как создать окно-форму в mt Dll с помощью Delphi? 2007.06.22www.mql5.com В одной из экспортируемых функций хочу создать не модальное окно-форму с помощью Делфи interface type TMTDllForm = class(TForm) private procedure W... Maxim Kuznetsov 2018.06.22 20:50 #93 Renat Fatkhullin: 从µl、pips、文件或网络查询进行单向轮询。我们不能使用反向的直接呼叫。虽然我们可以添加一个像OnExternal这样的带参数的方法，但我们需要考虑到传输通道。它可以是。- 一个带有参数的callbucket，在dll中注册。- 命名的mutex作为一个触发器- 窗口信息为PostMessage这是你的选择;-) 从应用程序的角度来看--在调用DLL之后，应该有一个标准的方法来对MT说 "这是你想要的，这是你得到的"。 长时间计算的典型情况，网络IO - MT调用DLL，DLL创建一个线程，并在其中做一些事情。需要有一种方法说 "就是这样，已经计算好了"。没有它，我们就会不断地对EA进行调查，以了解情况。 Алексей Барбашин 2018.06.22 20:51 #94 Maxim Kuznetsov:这是你的选择;-) 从应用的角度来看--应该有一种标准的方式来告诉MT "这是你想要的，这是你得到的"。 长时间计算的典型情况，网络IO--MT调用DLL，DLL生成一个线程，在其中做一些事情。需要有一种方法说 "就是这样，已经计算好了"。没有它，我们就会不断地对EA进行调查，以了解一些情况。 我附议! Yuriy Asaulenko 2018.06.22 20:55 #95 Алексей Барбашин:好的 是的，从一个平行的EA在一个短的定时器上拉出一个Dll有很大的意义。我们正在释放MT的主要信息流。特别是如果我们有一个黄牛党或日内的人。 Renat Fatkhullin 2018.06.22 20:59 #96 让我们尝试一下回调 Алексей Барбашин 2018.06.22 21:02 #97 我们都可以就一种开发环境的优点争论到底。但为了什么？我们都知道，没有一个发展系统是自给自足的，因为它解决的是具体问题。用任何其他语言或环境开发的任何其他插件组件都可以用来扩展其功能。我们只需要使其易于沟通。让我们不要走远：我们通过导入相同的Windows库......我们用它们来实现我们所缺少的功能。而且你不能说它纯粹是通过mql的方式实现的。)))因此，我们使用哪种外部应用程序来扩展能力和实现预期目标有什么区别？自己写的dll怎么会比Windows的差？以下是一篇文章，例如：https://www.mql5.com/ru/articles/364但这并不是要完全摆脱dll，这根本不会发生，因为MT有严格的自己的任务。无论你怎么看，这篇文章中都有系统库。是的，与自制库不同，这些库不需要与专家顾问或指标一起随身携带...那么，是什么阻止你在工具的资源中加入编译dll 的可能性呢？是的，你不能把它放在市场上，因为市场不允许使用dll，但这对你自己的发展会更方便。 Yuriy Asaulenko 2018.06.22 21:06 #98 Алексей Барбашин:我们都可以就一种开发环境的优点争论到底。但为了什么？我们都知道，没有一个发展系统是自给自足的，因为它解决的是具体问题。用任何其他语言或环境开发的任何其他插件组件都可以用来扩展其功能。我们只需要使其易于沟通。让我们不要走远：我们通过导入相同的Windows库......我们用它们来实现我们所缺少的功能。而且你不能说它纯粹是通过mql的方式实现的。)))因此，我们使用哪种外部应用程序来扩展能力和实现预期目标有什么区别？自己写的dll怎么会比Windows的差？以下是一篇文章，例如：https://www.mql5.com/ru/articles/364但这并不是要完全摆脱dll，这根本不会发生，因为MT有严格的自己的任务。在这篇文章中，无论你怎么看，系统库都是存在的。是的，与自制库不同，你不需要将这些库与专家顾问或指标一起携带...那么，是什么阻止你在工具的资源中加入编译dll 的可能性呢？是的，你不能把它放在市场上，因为市场不允许使用dll，但对于你自己的发展来说，这将是更方便的。 这类想法和帖子已经有10年历史了，但我们还在这里......雷纳特通常谈论生态系统，我们不允许... Алексей Барбашин 2018.06.22 21:17 #99 Yuriy Asaulenko: 这些想法和帖子是10年前的事了。雷纳特通常谈论生态系统，我们不允许...如果我们谈论的是生态系统，那么我们应该直接关闭MT中任何进口产品 的使用。但他们并没有这样做。毕竟，他们决定使用图书馆的进口产品并不是出于某种原因。有一段时间，MT无法处理网络请求，在处理文件时也有限制......所有这些都通过导入库而得到扩展。这都是显而易见的，所有的系统都是这样工作的。 即使是现在，MQL也只能从沙盒中处理文件。并不是有人在挑战这种做法，这是开发商的政策，每个人都理解并支持它。如果你需要走出沙盒或使用注册表来存储数据，或数据库或映射......那么请使用库来实现这一目的。对吗？这一切都很有意义。该工具不需要数据库或其他任何东西......这一切都只是为了开发人员，这就是为什么有MQL语言，所以你可以实现任何功能的工具。而既然有了开发环境，MT本身就不再是一个东西了。))你只需要...)))) Renat Fatkhullin 2018.06.22 21:17 #100 Yuriy Asaulenko: 这类想法和帖子已经有10年了，但我们还在这里......雷纳特通常谈及生态系统，我们不会让...怎么还是这样呢？ 所有互操作性的可能性已经存在了很长时间。DLL支持 甚至在2004年就被引入。 我们的语言在不断发展，变得更加强大和实用。而且这个生态系统比任何人的都要强大。 1...3456789101112131415 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
从μl、pips、文件或网络查询进行单向轮询。
我相信那会是很好的!我们不是在谈论向MT发送什么。转移本身可以以任何其他方式进行。重要的是要告诉MT，需要执行一些行动。这与你所开发的GUI库中的情况完全一样：所有的colbecs都是通过事件完成的。
顺便说一下，关于这个库：你打算扩大它并将它完全翻译成画布吗？也就是说，最终的 "产品 "不是一组图表对象，而是一个完整的画面。
在审查dll方面，我当然希望能够将dll作为MT的资源，这样我就不必将它们与专家顾问或指标一起 "拖 "出来。
为什么要在dotnet上做gui？
问题不在于GUI。使用MT工具可以很容易地创建这些界面。当然，这有点复杂，需要创建自己的处理类，但一切都可以解决。我开始用网络工作，因为不可能实现一些互联网工作的算法。在C++中是相当复杂和不稳定的，即使是母语，更不用说MT了。一旦我掌握了net，我也可以开始使用GUI，因为一切都为它准备好了，不像在MT。在任何语言的应用开发的开放问题中，即在任何，因为这些问题与网无关：1。反馈，2。将GUI连接到图表(https://www.mql5.com/ru/forum/103764)--是其中一个主题。
从µl、pips、文件或网络查询进行单向轮询。
这是你的选择;-)
从应用程序的角度来看--在调用DLL之后，应该有一个标准的方法来对MT说 "这是你想要的，这是你得到的"。
长时间计算的典型情况，网络IO - MT调用DLL，DLL创建一个线程，并在其中做一些事情。需要有一种方法说 "就是这样，已经计算好了"。没有它，我们就会不断地对EA进行调查，以了解情况。
这是你的选择;-)
从应用的角度来看--应该有一种标准的方式来告诉MT "这是你想要的，这是你得到的"。
长时间计算的典型情况，网络IO--MT调用DLL，DLL生成一个线程，在其中做一些事情。需要有一种方法说 "就是这样，已经计算好了"。没有它，我们就会不断地对EA进行调查，以了解一些情况。
我附议!
好的
我们都可以就一种开发环境的优点争论到底。但为了什么？我们都知道，没有一个发展系统是自给自足的，因为它解决的是具体问题。用任何其他语言或环境开发的任何其他插件组件都可以用来扩展其功能。我们只需要使其易于沟通。让我们不要走远：我们通过导入相同的Windows库......我们用它们来实现我们所缺少的功能。而且你不能说它纯粹是通过mql的方式实现的。)))因此，我们使用哪种外部应用程序来扩展能力和实现预期目标有什么区别？自己写的dll怎么会比Windows的差？
以下是一篇文章，例如：https://www.mql5.com/ru/articles/364
但这并不是要完全摆脱dll，这根本不会发生，因为MT有严格的自己的任务。无论你怎么看，这篇文章中都有系统库。是的，与自制库不同，这些库不需要与专家顾问或指标一起随身携带...
那么，是什么阻止你在工具的资源中加入编译dll 的可能性呢？
是的，你不能把它放在市场上，因为市场不允许使用dll，但这对你自己的发展会更方便。
我们都可以就一种开发环境的优点争论到底。但为了什么？我们都知道，没有一个发展系统是自给自足的，因为它解决的是具体问题。用任何其他语言或环境开发的任何其他插件组件都可以用来扩展其功能。我们只需要使其易于沟通。让我们不要走远：我们通过导入相同的Windows库......我们用它们来实现我们所缺少的功能。而且你不能说它纯粹是通过mql的方式实现的。)))因此，我们使用哪种外部应用程序来扩展能力和实现预期目标有什么区别？自己写的dll怎么会比Windows的差？
以下是一篇文章，例如：https://www.mql5.com/ru/articles/364
但这并不是要完全摆脱dll，这根本不会发生，因为MT有严格的自己的任务。在这篇文章中，无论你怎么看，系统库都是存在的。是的，与自制库不同，你不需要将这些库与专家顾问或指标一起携带...
那么，是什么阻止你在工具的资源中加入编译dll 的可能性呢？
是的，你不能把它放在市场上，因为市场不允许使用dll，但对于你自己的发展来说，这将是更方便的。
这些想法和帖子是10年前的事了。
如果我们谈论的是生态系统，那么我们应该直接关闭MT中任何进口产品 的使用。但他们并没有这样做。毕竟，他们决定使用图书馆的进口产品并不是出于某种原因。有一段时间，MT无法处理网络请求，在处理文件时也有限制......所有这些都通过导入库而得到扩展。这都是显而易见的，所有的系统都是这样工作的。 即使是现在，MQL也只能从沙盒中处理文件。并不是有人在挑战这种做法，这是开发商的政策，每个人都理解并支持它。如果你需要走出沙盒或使用注册表来存储数据，或数据库或映射......那么请使用库来实现这一目的。对吗？这一切都很有意义。该工具不需要数据库或其他任何东西......这一切都只是为了开发人员，这就是为什么有MQL语言，所以你可以实现任何功能的工具。而既然有了开发环境，MT本身就不再是一个东西了。))你只需要...))))
这类想法和帖子已经有10年了，但我们还在这里......
怎么还是这样呢？
所有互操作性的可能性已经存在了很长时间。DLL支持 甚至在2004年就被引入。
我们的语言在不断发展，变得更加强大和实用。而且这个生态系统比任何人的都要强大。