我的方法。核心是引擎。 - 页 24 1...171819202122232425262728293031...184 新评论 Vitalii Ananev 2018.12.07 17:05 #231 Реter Konow:对。 携带应用程序GUI的引擎只是执行控件（按钮、输入栏等）的机械功能。 按键、复选框、文本输入和其他用户行为。 直接从 被传递给开发者的应用程序。 该应用程序可以将其数据转移到字段和表格。 一切都通过一个简单的连接文件完成。哦，那就是另一回事了。 Реter Konow 2018.12.07 18:24 #232 Yuriy Asaulenko:.NET-dlls现在已经进入MT。用C-sharp制作MT的GUI已不再困难，而且功能更多。因 为在任何情况下，所有的事件都是在MT-ticks上发生的，那么按钮也是如此。好吧，分析工作，我认为，DLL比Peter更容易。 在一般情况下，发动机彼得，如果有人有用，这将是唯一的市场销售商，其中DLL nizizzo。首先，当你说 "完全没有困难 "时，你在撒谎。你可以很容易地在C#中创建一个GUI，但要把它连接到一个MQL-应用程序？ 给我看一个这种联系的例子。这至少是一个令人毛骨悚然的拐杖。你必须通过DLL来完成一切。发送事件，接收事件... 通过DLL开发一个夏普GUI 与MT应用程序的连接需要多少精力和时间？ 面对我的解决方案的简单性，谁会去做呢？ 我已经有了一个连接界面。 连接问题是半个小时（如果有几个窗口）。一切都非常简单。没有DLL。 所以这，是一个 "垂死 "的想法。 Yuriy Asaulenko 2018.12.07 18:29 #233 Реter Konow:首先，当你说 "这没什么大不了的 "时，你在撒谎。用C#做一个GUI很容易，但要把它连接到MQL-应用 上呢？ 给我看一个这种联系的例子。这至少是一个令人毛骨悚然的拐杖。你必须通过DLL来完成一切。发送事件，接收事件... 在没有DLL的情况下，开发一个带有MT应用程序的夏普GUI界面 需要多少努力和时间？ 面对我的解决方案的简单性，谁会去做呢？我已经有了一个连接界面。连接问题是半个小时（如果有几个窗口）。一切都非常简单。没有DLL。 所以这，是一个 "垂死 "的想法。一切都是一样的。完全没有并发症。你调用什么函数，应用程序或DLL都没有区别。你看到调用函数 的复杂性了吗？ Реter Konow 2018.12.07 18:35 #234 Yuriy Asaulenko:一切都是一样的。没有并发症。你调用哪个函数并没有什么区别--应用程序或DLL。你认为在调用功能 方面有困难吗？不，这是关于参数值必须同步的内存。该内存必须在文件中或在DLL中的共享应用程序内存中（或其他地方）。 但这不是主要的问题。 将军。 每个开发者都必须想出自己的接口，以便与 夏普的GUI连接。 而且，当我已经拥有一切工作时，为什么还需要这样做呢？ Yuriy Asaulenko 2018.12.07 18:37 #235 Реter Konow:不，是关于参数值应该同步的内存。该内存必须在一个文件中或在DLL中的共享应用程序内存中（或其他地方）。 但这不是主要的问题。 将军。 每个开发者都必须想出自己的接口，以便与 夏普的GUI连接。 如果我已经有了一切工作，为什么还要这样做呢？你太夸张了）。 Реter Konow 2018.12.07 18:41 #236 Yuriy Asaulenko:你太夸张了）。一点也不。我知道这种情况。我已经通过一个用C++编写的DLL在一个MT程序和一个Sharpe程序之间做了接口。可怕的屁股疼痛。你必须同时使用visual studio和MT来工作。然后并行地运行应用程序。 但最主要的是，没有人开发出一种应用部分的互动格式。因此，每个人都会自己苦恼。 Yuriy Asaulenko 2018.12.07 18:45 #237 Реter Konow:一滴都没有。我知道这种情况。我已经通过一个用C++编写的DLL在一个MT程序和一个Sharpe程序之间做了接口。这是一个可怕的痛苦的屁股。你必须同时使用visual studio和MT来工作。然后并行地运行应用程序。 但最主要的是，没有人开发出一种应用部分的互动格式。因此，每个人都将靠自己的力量奋斗。DLL是一个标准的Windows工具。DLLs的互操作性从DOS时代就开始发展和使用了。那里根本就没有问题。 Реter Konow 2018.12.07 18:50 #238 Yuriy Asaulenko:DLL是一个标准的Windows工具。从DOS时代开始，与DLL的互操作性已经被开发并广泛使用了很长时间。那里根本就没有问题。夏普与DLL的互动已经开发完成。而ICL应用程序通过DLL与夏普的互动对程序员来说是一个个人麻烦。 他需要组织共享内存，并根据读取标志来进行他的函数调用。 因此，他需要无休止地 访问位于DLL或文件中的共享内存。毕竟，没有从夏普通过DLL到MT的回调。 Yuriy Asaulenko 2018.12.07 18:56 #239 Реter Konow:与夏普方面的DLL的交互作用被解决了。而MKL应用程序通过DLL与Sharpe的互动，对程序员来说是一个个人麻烦。 他需要组织共享内存，并根据读取标志来进行他的函数调用。 因此，他需要无休止地 访问位于DLL或文件中的共享内存。毕竟，没有从夏普通过DLL到MT的回调。你在MT中也没有回调。一切都由MT的预定义事件完成，一劳永逸。 你仍然会向DLL发送终端事件，你在哪里处理它们并不重要，在MT还是在DLL中。 Реter Konow 2018.12.07 18:59 #240 即使人们想象ICL应用程序对来自夏普的信息进行不断的验证并不是一件烦人的事，开发一种交互格式也是一项非常浩大的任务。 这项任务包括以下内容。 1.想出了一个共享内存组织。 2.落实三方的互动。 3.三方面的同步测试（夏普、DLL、MT应用）。 非常耗费时间。 在我的案例中，用户得到了文件并填写了它。而且连接是有效的。 1...171819202122232425262728293031...184 新评论 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
对。
携带应用程序GUI的引擎只是执行控件（按钮、输入栏等）的机械功能。
按键、复选框、文本输入和其他用户行为。 直接从 被传递给开发者的应用程序。
该应用程序可以将其数据转移到字段和表格。
一切都通过一个简单的连接文件完成。
哦，那就是另一回事了。
.NET-dlls现在已经进入MT。用C-sharp制作MT的GUI已不再困难，而且功能更多。因 为在任何情况下，所有的事件都是在MT-ticks上发生的，那么按钮也是如此。好吧，分析工作，我认为，DLL比Peter更容易。
在一般情况下，发动机彼得，如果有人有用，这将是唯一的市场销售商，其中DLL nizizzo。
首先，当你说 "完全没有困难 "时，你在撒谎。你可以很容易地在C#中创建一个GUI，但要把它连接到一个MQL-应用程序？
给我看一个这种联系的例子。这至少是一个令人毛骨悚然的拐杖。你必须通过DLL来完成一切。发送事件，接收事件...
通过DLL开发一个夏普GUI 与MT应用程序的连接需要多少精力和时间？
面对我的解决方案的简单性，谁会去做呢？ 我已经有了一个连接界面。 连接问题是半个小时（如果有几个窗口）。一切都非常简单。没有DLL。
所以这，是一个 "垂死 "的想法。
首先，当你说 "这没什么大不了的 "时，你在撒谎。用C#做一个GUI很容易，但要把它连接到MQL-应用 上呢？
给我看一个这种联系的例子。这至少是一个令人毛骨悚然的拐杖。你必须通过DLL来完成一切。发送事件，接收事件...
在没有DLL的情况下，开发一个带有MT应用程序的夏普GUI界面 需要多少努力和时间？
面对我的解决方案的简单性，谁会去做呢？我已经有了一个连接界面。连接问题是半个小时（如果有几个窗口）。一切都非常简单。没有DLL。
所以这，是一个 "垂死 "的想法。
一切都是一样的。完全没有并发症。你调用什么函数，应用程序或DLL都没有区别。你看到调用函数 的复杂性了吗？
一切都是一样的。没有并发症。你调用哪个函数并没有什么区别--应用程序或DLL。你认为在调用功能 方面有困难吗？
不，这是关于参数值必须同步的内存。该内存必须在文件中或在DLL中的共享应用程序内存中（或其他地方）。
但这不是主要的问题。
将军。
每个开发者都必须想出自己的接口，以便与 夏普的GUI连接。
而且，当我已经拥有一切工作时，为什么还需要这样做呢？
不，是关于参数值应该同步的内存。该内存必须在一个文件中或在DLL中的共享应用程序内存中（或其他地方）。
但这不是主要的问题。
将军。
每个开发者都必须想出自己的接口，以便与 夏普的GUI连接。
如果我已经有了一切工作，为什么还要这样做呢？
你太夸张了）。
你太夸张了）。
一点也不。我知道这种情况。我已经通过一个用C++编写的DLL在一个MT程序和一个Sharpe程序之间做了接口。可怕的屁股疼痛。你必须同时使用visual studio和MT来工作。然后并行地运行应用程序。
但最主要的是，没有人开发出一种应用部分的互动格式。因此，每个人都会自己苦恼。
一滴都没有。我知道这种情况。我已经通过一个用C++编写的DLL在一个MT程序和一个Sharpe程序之间做了接口。这是一个可怕的痛苦的屁股。你必须同时使用visual studio和MT来工作。然后并行地运行应用程序。
但最主要的是，没有人开发出一种应用部分的互动格式。因此，每个人都将靠自己的力量奋斗。
DLL是一个标准的Windows工具。DLLs的互操作性从DOS时代就开始发展和使用了。那里根本就没有问题。
DLL是一个标准的Windows工具。从DOS时代开始，与DLL的互操作性已经被开发并广泛使用了很长时间。那里根本就没有问题。
夏普与DLL的互动已经开发完成。而ICL应用程序通过DLL与夏普的互动对程序员来说是一个个人麻烦。
他需要组织共享内存，并根据读取标志来进行他的函数调用。
因此，他需要无休止地 访问位于DLL或文件中的共享内存。毕竟，没有从夏普通过DLL到MT的回调。
与夏普方面的DLL的交互作用被解决了。而MKL应用程序通过DLL与Sharpe的互动，对程序员来说是一个个人麻烦。
他需要组织共享内存，并根据读取标志来进行他的函数调用。
因此，他需要无休止地 访问位于DLL或文件中的共享内存。毕竟，没有从夏普通过DLL到MT的回调。
你在MT中也没有回调。一切都由MT的预定义事件完成，一劳永逸。
你仍然会向DLL发送终端事件，你在哪里处理它们并不重要，在MT还是在DLL中。
即使人们想象ICL应用程序对来自夏普的信息进行不断的验证并不是一件烦人的事，开发一种交互格式也是一项非常浩大的任务。
这项任务包括以下内容。
1.想出了一个共享内存组织。
2.落实三方的互动。
3.三方面的同步测试（夏普、DLL、MT应用）。
非常耗费时间。
在我的案例中，用户得到了文件并填写了它。而且连接是有效的。