我的方法。核心是引擎。 - 页 26 1...192021222324252627282930313233...184 新评论 Igor Makanu 2018.12.08 07:31 #251 Koldun Zloy:GUI构造器是为一个特定的图形库制作的。如果有一个用于MQL的GUI构建器，它就会在这里。我在某处看到一篇文章，似乎是在hubre的某处，好像是 "为Python创建一个GUI构造器"，所以我想，也许有人看到过一个多平台的GUI，我可以在那里添加自己的代码 但如果我想从头开始写一个构造函数，我宁愿使用MQL。 Реter Konow 2018.12.08 07:44 #252 Igor Makanu:1.我从来没有用夏普开发过，我没有兴趣，但大约5年前，我用Delphi将.dll与按钮和表格连接起来，工作起来没有问题，甚至整个Delphi项目在一天内就准备好了，我甚至花了半天时间试图找到标准表格不工作的原因，但当我通过调用系统窗口连接它时，一切工作正常，但那时MT4非常慢，现在它滞后了，飞起来了 我在连接.dll时没有问题，用标准的mutexes进行同步--启动一个线程连接到终端，就这样，然后一切都会自己进行--在.dll中单独的一个表格，单独的MT没有人在等人。 SZS: 请注意，Delphi创建一个.dll是相当不实际的，但手头的东西（当时我正坐在上面）我用了）) 2.但是对于要点，我不明白为什么他们不能使用MT工具包中的标准类，如果能统一图形创建的过程，那就很酷了，也许这将是一个通用的包含，你可以注释不必要的按钮/对话框等。1.这是一种非常、非常业余的看问题的方式（无意冒犯）。在一天内完成的项目不是一个项目。这是个小任务。 想象一下，你创建了一个由10个窗口组成的应用程序，其中有大的数据表格、设置窗口和对话框。你在Delphi中绘制它们。然后你创建一个DLL。然后你把它连接到你的MT项目。 你的MT程序需要通过共享内存连接到Delphi GUI。将函数连接到控件，将数据连接到表格单元。你需要组织好应用程序两部分的复杂互动，并正确地思考它。 你需要在GUI和MT应用两部分之间同步操作和交换参数值。 再次强调：如果你的应用程序是大而严肃的（表格、设置窗口、对话框、古老的列表等），通过DLL创建一个单一的、连贯的、高效的两部分工作是一项非常严肃的任务。我已经做过了，我知道我在说什么。 而你说的是一些可以在一天内完成的小任务。这并不严重。 2）你可以在很久以前使用标准库。但问题是所需的努力和你将得到的结果。它们是什么？我知道Anatoly用标准库作为跳板来创建他自己的库。但如果标准库也能工作，他为什么要这样做呢？答案很简单--他实现了质量更高的一切，并且超越了标准库。但是，只有通过降低使用难度才能实现大规模分发。使用越简单，--用户就越多（当然，质量也会提高）。 Igor Makanu 2018.12.08 08:13 #253 Реter Konow:1.这是一种非常、非常业余的看问题的方式（无意冒犯）。在一天内完成的项目不是一个项目。这是个小任务。想象一下，你创建了一个由10个窗口组成的应用程序，其中有大的数据表格、设置窗口和对话框。你在Delphi中绘制它们。然后你创建一个DLL。然后你把它连接到你的MT项目。你的MT程序需要通过共享内存连接到Delphi GUI。将函数连接到控件，将数据连接到表格单元。你需要组织好应用程序两部分的复杂互动，并正确地思考它。你需要在GUI和MT应用两部分之间同步操作和交换参数值。再次强调：如果你的应用程序是大而严肃的（表格、设置窗口、对话框、古老的列表等），通过DLL创建一个单一的、连贯的、高效的两部分工作是一项非常严肃的任务。我已经做过了，我知道我在说什么。而你说的是一些可以在一天内完成的小任务。这并不严重。你有什么不满的地方？你只是不明白，MT和.dll之间的数据交换和世界一样古老。 我正在制作一个.dll，因为以前MT中没有像样的图形，我想要按钮和一个面板。 桌子？- 绘制好表格，控制？- draw....你就是不能把任务分开，在同一个Delphi中，有许多现成的组件，既可用于创建 数据库的数据库，也可用于与之工作。 也就是说，从MT你只需要数据本身，其余的将由第三方程序来做，你可以把你的话当做耳旁风，但在同一个Delphi中写工作的数据库，与输出的表格、图表等工作一天；) 什么是MT中的数据？=它只是一个勾和条，没有必要在一个.dll中 "赛跑"--只需将所有东西一次性转储到一个文件中，然后在第三方程序中处理该文件 SZS: 最近有人在论坛上写道，现代IT公司看重的是那些不彻底了解自己工作的代码的员工，而是那些尽快能完成大量任务的员工，即需要能把别人的工作整合到自己的任务中，而不是每次都要从头开始建立!我不知道你的主要职业，我从来没有当过程序员，但我一直在相关领域工作，很长一段时间从事工业控制器、ACS和ACS的维护工作，不得不做添加程序解决方案，并与开发人员互动，所以我不得不进入所有现成的软件解决方案 - 在这里你不能从头开始写一切))))，工业 "铁 "的制造商使用专门的编程系统，其中C，其中SCADA，和汇编，而且每一次必须能够阅读别人的代码;) 你建议在你的 "引擎 "的基础上，创造出有条件的可操作的设计，而这些设计不能被程序员进一步修改？ Реter Konow 2018.12.08 08:56 #254 Igor Makanu:有什么难言之隐？你只是不明白，MT和.dll之间的数据交换和世界一样古老。 我做了.dll，因为以前MT中没有像样的图形，我想要按钮和面板。 桌子？- 绘制好表格，控制？- draw....你就是不能把任务分开，在同一个Delphi中，有许多现成的组件，既可用于创建数据库的数据库，也可用于与它们一起工作 也就是说，从MT你只需要数据，其余的将由第三方程序来做，你可以相信你的话，但在同一个Delphi中写工作与数据库，与输出的表格，图表等工作一天；) ZS：MT中的数据是什么？=它只是一个刻度线和条形图，没有必要通过.dll来 "比赛 "历史记录--只需将所有内容一次性转储到一个文件中，然后在第三方程序中处理该文件。如果你只取从MT进入的数据，并通过DLL将其传递给用Delphi或C++或C#编写的应用程序，那么这当然是可能的。 然后，交易应用程序将完全用不同的编程语言编写。 也就是说，时间序列、测试器、优化、合成器 和其他许多东西必须用另一种语言创建。 你为什么需要MQL呢？将数据直接提供给第三方应用程序，并将平台作为事件和订单的发送者就足够了。就这样了。但MQL作为交易系统语言的优势将丧失。 你为什么需要MQL？ 因为MQL是一种为编写交易应用程序而开发的应用语言。这是它的主要优势。它很轻，很简单。它为程序员提供了很多现成的解决方案。他们把它们拿去使用。 程序员有一个选择。 完全用任何第三方语言（C++、C#、Delphi......等）编写交易程序，并连接MT作为数据源和订单发送器。(在这种情况下，如果你想使用它，你需要重新创建平台工具包）。编写一个 "双头 "应用程序，它将使用平台工具包和MQL，但用另一种语言实现GUI并连接到MT应用程序。(如果申请是认真的，那就很麻烦了）。 用MQL编写整个应用程序，并使用该平台的所有优势和好处。(在这种情况下，有一个创建GUI的问题）。 显然，最可取的选择是使用MQL和MT，因为它们具有优势--测试、优化、研究（合成）、指标、方便的功能、时间序列。+ 论坛上的技术语言支持。 但这种理想有一个严重的缺陷：创建复杂应用程序的能力有限，因为很难创建高质量的图形用户界面。 这最后一个问题我基本 解决了。 因此，当涉及到实践，你开始写一个严肃的申请时，你肯定会选择MT。其他许多人也会如此。 Реter Konow 2018.12.08 09:10 #255 Igor Makanu:... 你是否建议在你的 "引擎 "的基础上创建一个有条件可行的设计，不能由程序员进一步修改？引擎是那个GUI的 "载体"，它在我的构造器中被创建。它不需要被修改。只有把它连接到应用程序，创建的GUI才会工作。 Yury Kulikov 2018.12.08 09:24 #256 Реter Konow:再次强调：如果应用程序是大型的、严肃的（表格、设置窗口、对话框、古老的列表等......），通过DLL创建一个单一的、连贯的、有效的两部分操作是一项非常严肃的任务。我已经做过了，我知道我在说什么。Retag Konow:在MQL中完全编写一个应用程序，并使用其所有的好处和平台的优势。(在这种情况下，创建GUI就有问题）。谁能创建一个大型复杂的应用程序，谁就一定会使用gui库。如果开发者开发他的应用程序并决定添加动画，例如，他应该怎么做？他应该找你问，还是应该打破一切，从头开始建立？ 你怎么会认为GUI的创建有问题。看看市场，有许多带有GUI的应用程序。 Реter Konow 2018.12.08 09:33 #257 Yury Kulikov:1.谁能创建一个大型复杂的应用程序，谁就一定会使用gui库。 2.如果在开发他的应用程序时，他决定，比如说，增加动画，那么开发者应该怎么做？为你搜索并询问，还是打破一切，从头开始建立？3）你又是怎么想到GUI的创建存在问题的。看看市场，有很多带有GUI的应用程序。1.GUI库是一个为严肃的程序员设计的库。由于使用困难，它不能被大规模生产。这 有什么意义呢？只是我们中的一些人会仔细研究图书馆并创建复杂的应用程序，而另一些人则无法做到？ 2.让开发者在他的应用程序中创建动画。这与我有什么关系？他可以独立于GUI和引擎来调用这个动画，或者将他的动画的调用链接到一些按钮上。 3）只有少数人的GUI值得关注。你，阿纳托利，也许还有其他人......。其余的没有达到丝毫严肃的程度。 Yury Kulikov 2018.12.08 09:48 #258 Реter Konow: 3.只有少数人的GUI是值得注意的。我不会如此断然。而且我说的不是gui库开发，我说的是gui应用。市场上有很多，有些使用自己的开发，有些使用标准库，有些使用Anatoly的库。 Georgiy Merts 2018.12.08 09:50 #259 Реter Konow:1.这就是问题的关键。 GUI库是为严肃的程序员设计的。由于使用困难，它不能被大规模推广。这 有什么意义呢？有些人会翻阅图书馆并创建复杂的应用程序，有些人则无法做到？2.让开发者在他的应用程序中创建动画。这与我有什么关系？他可以独立于GUI和引擎来调用这个动画，或者将他的动画的调用与一些按钮联系起来。3）只有少数人的GUI值得关注。你，阿纳托利，也许还有其他人......。其余的都没有达到哪怕是最严重的程度。彼得，我认为你的主要问题是在项目的 定位上。 它可能只对那些在编程方面有相当好的经验的参与者感兴趣，但同时--更喜欢交换手。 你认为有很多这样的人吗？ 看--所有批评你的设计的人都是没有经常从事 "手工 "交易的人。最多是--不时地。而且，由于他们不把你的项目看成是 "手工 "商人--他们把它看成是程序员。而且，可以理解的是，他们找到了很多非常可疑的解决方案。 在我看来，你现在的问题应该是找到这个利基（在我看来，是一个非常狭窄的利基）：喜欢交易手的程序员。 Maxim Kuznetsov 2018.12.08 09:53 #260 Igor Makanu:我想我在某个地方看到了一篇文章，比如在hubra上，叫做 "为Python创建一个GUI构建器"，所以我想也许有人已经看到了一个多平台的GUI，在那里我可以添加自己的代码如果我想从头开始写一个构造函数，我宁愿使用MQL。现代GUI构造器（那些 "把按钮铺到表单上 "的构造器）是一个相当有技术含量的东西，把MQL元素附加到它们身上看起来并不美妙。 在中间形式（项目 文件等）中，几乎所有的都有描述布局和元素之间关系的XML。 目标平台的代码生成实际上是XSLT转换，任何认为自己是网络开发者的人都可以做到：-) 以EasyAndFast（https://www.mql5.com/ru/code/19703）为例，因为它是基于对象的，并且拥有所有必要的组件。(并顺便公开和记录，不像在这个线程中)，，并简单地写一个翻译器。 没有gui-mql的建设者，不是因为它是巨型复杂的，而只是因为它没有需求。 EasyAndFastGUI - библиотека для создания графических интерфейсов www.mql5.com Библиотека EasyAndFastGUI дает возможность создавать графические интерфейсы для своих MQL-программ. 1...192021222324252627282930313233...184 新评论 原因: 取消 您错过了交易机会： 免费交易应用程序 8,000+信号可供复制 探索金融市场的经济新闻 注册 登录 拉丁字符（不带空格） 密码将被发送至该邮箱 发生错误 使用 Google 登录 您同意网站政策和使用条款 如果您没有帐号，请注册 可以使用cookies登录MQL5.com网站。 请在您的浏览器中启用必要的设置，否则您将无法登录。 忘记您的登录名/密码？ 使用 Google 登录
GUI构造器是为一个特定的图形库制作的。如果有一个用于MQL的GUI构建器，它就会在这里。
我在某处看到一篇文章，似乎是在hubre的某处，好像是 "为Python创建一个GUI构造器"，所以我想，也许有人看到过一个多平台的GUI，我可以在那里添加自己的代码
但如果我想从头开始写一个构造函数，我宁愿使用MQL。
1.我从来没有用夏普开发过，我没有兴趣，但大约5年前，我用Delphi将.dll与按钮和表格连接起来，工作起来没有问题，甚至整个Delphi项目在一天内就准备好了，我甚至花了半天时间试图找到标准表格不工作的原因，但当我通过调用系统窗口连接它时，一切工作正常，但那时MT4非常慢，现在它滞后了，飞起来了
我在连接.dll时没有问题，用标准的mutexes进行同步--启动一个线程连接到终端，就这样，然后一切都会自己进行--在.dll中单独的一个表格，单独的MT没有人在等人。
SZS: 请注意，Delphi创建一个.dll是相当不实际的，但手头的东西（当时我正坐在上面）我用了）)
2.但是对于要点，我不明白为什么他们不能使用MT工具包中的标准类，如果能统一图形创建的过程，那就很酷了，也许这将是一个通用的包含，你可以注释不必要的按钮/对话框等。
1.这是一种非常、非常业余的看问题的方式（无意冒犯）。在一天内完成的项目不是一个项目。这是个小任务。
想象一下，你创建了一个由10个窗口组成的应用程序，其中有大的数据表格、设置窗口和对话框。你在Delphi中绘制它们。然后你创建一个DLL。然后你把它连接到你的MT项目。
你的MT程序需要通过共享内存连接到Delphi GUI。将函数连接到控件，将数据连接到表格单元。你需要组织好应用程序两部分的复杂互动，并正确地思考它。
你需要在GUI和MT应用两部分之间同步操作和交换参数值。
再次强调：如果你的应用程序是大而严肃的（表格、设置窗口、对话框、古老的列表等），通过DLL创建一个单一的、连贯的、高效的两部分工作是一项非常严肃的任务。我已经做过了，我知道我在说什么。
而你说的是一些可以在一天内完成的小任务。这并不严重。
2）你可以在很久以前使用标准库。但问题是所需的努力和你将得到的结果。它们是什么？我知道Anatoly用标准库作为跳板来创建他自己的库。但如果标准库也能工作，他为什么要这样做呢？答案很简单--他实现了质量更高的一切，并且超越了标准库。但是，只有通过降低使用难度才能实现大规模分发。使用越简单，--用户就越多（当然，质量也会提高）。
1.这是一种非常、非常业余的看问题的方式（无意冒犯）。在一天内完成的项目不是一个项目。这是个小任务。
想象一下，你创建了一个由10个窗口组成的应用程序，其中有大的数据表格、设置窗口和对话框。你在Delphi中绘制它们。然后你创建一个DLL。然后你把它连接到你的MT项目。
你的MT程序需要通过共享内存连接到Delphi GUI。将函数连接到控件，将数据连接到表格单元。你需要组织好应用程序两部分的复杂互动，并正确地思考它。
你需要在GUI和MT应用两部分之间同步操作和交换参数值。
再次强调：如果你的应用程序是大而严肃的（表格、设置窗口、对话框、古老的列表等），通过DLL创建一个单一的、连贯的、高效的两部分工作是一项非常严肃的任务。我已经做过了，我知道我在说什么。
而你说的是一些可以在一天内完成的小任务。这并不严重。
你有什么不满的地方？你只是不明白，MT和.dll之间的数据交换和世界一样古老。
我正在制作一个.dll，因为以前MT中没有像样的图形，我想要按钮和一个面板。
桌子？- 绘制好表格，控制？- draw....你就是不能把任务分开，在同一个Delphi中，有许多现成的组件，既可用于创建 数据库的数据库，也可用于与之工作。
也就是说，从MT你只需要数据本身，其余的将由第三方程序来做，你可以把你的话当做耳旁风，但在同一个Delphi中写工作的数据库，与输出的表格、图表等工作一天；)
什么是MT中的数据？=它只是一个勾和条，没有必要在一个.dll中 "赛跑"--只需将所有东西一次性转储到一个文件中，然后在第三方程序中处理该文件
SZS: 最近有人在论坛上写道，现代IT公司看重的是那些不彻底了解自己工作的代码的员工，而是那些尽快能完成大量任务的员工，即需要能把别人的工作整合到自己的任务中，而不是每次都要从头开始建立!我不知道你的主要职业，我从来没有当过程序员，但我一直在相关领域工作，很长一段时间从事工业控制器、ACS和ACS的维护工作，不得不做添加程序解决方案，并与开发人员互动，所以我不得不进入所有现成的软件解决方案 - 在这里你不能从头开始写一切))))，工业 "铁 "的制造商使用专门的编程系统，其中C，其中SCADA，和汇编，而且每一次必须能够阅读别人的代码;)
你建议在你的 "引擎 "的基础上，创造出有条件的可操作的设计，而这些设计不能被程序员进一步修改？
有什么难言之隐？你只是不明白，MT和.dll之间的数据交换和世界一样古老。
我做了.dll，因为以前MT中没有像样的图形，我想要按钮和面板。
桌子？- 绘制好表格，控制？- draw....你就是不能把任务分开，在同一个Delphi中，有许多现成的组件，既可用于创建数据库的数据库，也可用于与它们一起工作
也就是说，从MT你只需要数据，其余的将由第三方程序来做，你可以相信你的话，但在同一个Delphi中写工作与数据库，与输出的表格，图表等工作一天；)
ZS：MT中的数据是什么？=它只是一个刻度线和条形图，没有必要通过.dll来 "比赛 "历史记录--只需将所有内容一次性转储到一个文件中，然后在第三方程序中处理该文件。
如果你只取从MT进入的数据，并通过DLL将其传递给用Delphi或C++或C#编写的应用程序，那么这当然是可能的。 然后，交易应用程序将完全用不同的编程语言编写。
也就是说，时间序列、测试器、优化、合成器 和其他许多东西必须用另一种语言创建。
你为什么需要MQL呢？将数据直接提供给第三方应用程序，并将平台作为事件和订单的发送者就足够了。就这样了。但MQL作为交易系统语言的优势将丧失。
你为什么需要MQL？
因为MQL是一种为编写交易应用程序而开发的应用语言。这是它的主要优势。它很轻，很简单。它为程序员提供了很多现成的解决方案。他们把它们拿去使用。
程序员有一个选择。
显然，最可取的选择是使用MQL和MT，因为它们具有优势--测试、优化、研究（合成）、指标、方便的功能、时间序列。+ 论坛上的技术语言支持。
但这种理想有一个严重的缺陷：创建复杂应用程序的能力有限，因为很难创建高质量的图形用户界面。
这最后一个问题我基本 解决了。
因此，当涉及到实践，你开始写一个严肃的申请时，你肯定会选择MT。其他许多人也会如此。
...
你是否建议在你的 "引擎 "的基础上创建一个有条件可行的设计，不能由程序员进一步修改？
引擎是那个GUI的 "载体"，它在我的构造器中被创建。它不需要被修改。只有把它连接到应用程序，创建的GUI才会工作。
再次强调：如果应用程序是大型的、严肃的（表格、设置窗口、对话框、古老的列表等......），通过DLL创建一个单一的、连贯的、有效的两部分操作是一项非常严肃的任务。我已经做过了，我知道我在说什么。
谁能创建一个大型复杂的应用程序，谁就一定会使用gui库。如果开发者开发他的应用程序并决定添加动画，例如，他应该怎么做？他应该找你问，还是应该打破一切，从头开始建立？
你怎么会认为GUI的创建有问题。看看市场，有许多带有GUI的应用程序。
1.谁能创建一个大型复杂的应用程序，谁就一定会使用gui库。
2.如果在开发他的应用程序时，他决定，比如说，增加动画，那么开发者应该怎么做？为你搜索并询问，还是打破一切，从头开始建立？
3）你又是怎么想到GUI的创建存在问题的。看看市场，有很多带有GUI的应用程序。
1.GUI库是一个为严肃的程序员设计的库。由于使用困难，它不能被大规模生产。这 有什么意义呢？只是我们中的一些人会仔细研究图书馆并创建复杂的应用程序，而另一些人则无法做到？
2.让开发者在他的应用程序中创建动画。这与我有什么关系？他可以独立于GUI和引擎来调用这个动画，或者将他的动画的调用链接到一些按钮上。
3）只有少数人的GUI值得关注。你，阿纳托利，也许还有其他人......。其余的没有达到丝毫严肃的程度。
3.只有少数人的GUI是值得注意的。
我不会如此断然。而且我说的不是gui库开发，我说的是gui应用。市场上有很多，有些使用自己的开发，有些使用标准库，有些使用Anatoly的库。
1.这就是问题的关键。 GUI库是为严肃的程序员设计的。由于使用困难，它不能被大规模推广。这 有什么意义呢？有些人会翻阅图书馆并创建复杂的应用程序，有些人则无法做到？
2.让开发者在他的应用程序中创建动画。这与我有什么关系？他可以独立于GUI和引擎来调用这个动画，或者将他的动画的调用与一些按钮联系起来。
3）只有少数人的GUI值得关注。你，阿纳托利，也许还有其他人......。其余的都没有达到哪怕是最严重的程度。
彼得，我认为你的主要问题是在项目的 定位上。
它可能只对那些在编程方面有相当好的经验的参与者感兴趣，但同时--更喜欢交换手。
你认为有很多这样的人吗？
看--所有批评你的设计的人都是没有经常从事 "手工 "交易的人。最多是--不时地。而且，由于他们不把你的项目看成是 "手工 "商人--他们把它看成是程序员。而且，可以理解的是，他们找到了很多非常可疑的解决方案。
在我看来，你现在的问题应该是找到这个利基（在我看来，是一个非常狭窄的利基）：喜欢交易手的程序员。
我想我在某个地方看到了一篇文章，比如在hubra上，叫做 "为Python创建一个GUI构建器"，所以我想也许有人已经看到了一个多平台的GUI，在那里我可以添加自己的代码
如果我想从头开始写一个构造函数，我宁愿使用MQL。
现代GUI构造器（那些 "把按钮铺到表单上 "的构造器）是一个相当有技术含量的东西，把MQL元素附加到它们身上看起来并不美妙。
在中间形式（项目 文件等）中，几乎所有的都有描述布局和元素之间关系的XML。
目标平台的代码生成实际上是XSLT转换，任何认为自己是网络开发者的人都可以做到：-)
以EasyAndFast（https://www.mql5.com/ru/code/19703）为例，因为它是基于对象的，并且拥有所有必要的组件。(并顺便公开和记录，不像在这个线程中)，
，并简单地写一个翻译器。
没有gui-mql的建设者，不是因为它是巨型复杂的，而只是因为它没有需求。