错误、漏洞、问题 - 页 906

 
Renat:

一旦你成为一个程序员,你需要明白,是你开始用你的请求来消耗资源。调用昂贵的函数 绝不意味着你可以脱离 "资源实际如何被处理 "的问题。

最好的方法是在这里的论坛上发布完整的代码,问题区域将立即被检测出来。如果你不能在这里做,你可以在服务台做(代码在检查后将被删除)。

ps:当操作系统发出没有足够的内存时,我们从来没有问题,我们也从来没有因此而责怪微软。

同样,我将写下我以前放弃的东西。

是的,我知道有些公司对强迫产品销售和通过任何必要手段增加利润感兴趣。比如说,有卡特尔的阴谋。而微软,被认为是臭名昭著的周期性程序颠簸,以减缓其长期忍受的操作系统(这很可能是真的),几乎一直处于与硬件巨头勾结的状态,这些巨头也梦想着通过急于向Windows消费者出售其昂贵的新硬件来取代尚未在Unix-platforms或旧Windows上生活的、完全可用的旧硬件,来拧动他们的手。

MQ从来没有给我一种感觉,他们想用铁针捆住我,让我没有内衣穿。多年来,MT4和MT5都一直提供体面的响应性和可用性,特别是与那些相对较新的、无处不在的、不方便的.NET框架应用程序相比。所以这没有什么不对,这是我希望在未来看到的。重要的是要有关于新建筑的全面信息和关于改变后的最低要求等的附带信息,这样我们就知道在精神上、智力上和经济上要做什么准备。

另外,关于依赖性开发者对主要开发者的指责,微软并没有强迫任何人在没有选择的情况下升级。由于某些原因,你无法关闭自动更新。所以。

 
x100intraday:

我仍然会写下我之前避免写的东西。

你在创建一个服务台应用程序上花费的时间不会超过5分钟。也许你会在第二天收到一个明确的答复。

但你更愿意和雷纳特讨论微软反对用户的阴谋。

在这之后不要说你真的有问题;)

 
notused:

在悄悄更新到最新版本后,被删除的代理开始脱落。

有人在发送错误的数据。在这之前,代理在悄悄地崩溃(你只是没有注意到),因为除以零。 这个除以零 原则上不应该存在,所以我们没有相应的检查。这个人可能不是入侵者,所以我们在服务台等待他的请求。我们自己无法重现这个错误。

UPD

我突然看到日志中的一行字

expert file added: Experts\grider1.1.ex5. 18867 bytes loaded

这表明你的代理确实是作为一个远程代理使用的。所以你知道问题的来源。我想和服务员谈谈。

 

什么是

2012.12.19 21:33:50 核心01 2004.04.02 20:15:00 违反访问规定写到0x0000000000000009


在策略回溯测试中显示。

 
gpwr:

什么是

2012.12.19 21:33:50 核心01 2004.04.02 20:15:00 违反访问规定写到0x0000000000000009


在策略回溯测试中显示。

下午好。请给servicedesk写信,并附上专家(检查后将被删除),谢谢。指定构建号、操作系统、比特率和优化设置谢谢你。
 
Общайтесь с разработчиками через Сервисдеск!
Общайтесь с разработчиками через Сервисдеск!
  • www.mql5.com
Ваше сообщение сразу станет доступно нашим отделам тестирования, технической поддержки и разработчикам торговой платформы.
 
IvanIvanov:
向servicedesk发送信息 时出错
服务中出现了一个小插曲,现在正在工作。
 

雷纳特,嗯,我在32位版本上仍有问题,但我第一次有机会在x64版本的MT5上测试代码。这就是我所发现的......。

没有32位版本的终端产生的那些错误,但存在初始(即在我手动切换到其他时间段之前)绘制图形布局不完整的问题,以及一些对象的绑定点偶尔从极值移动,以及一个辅助指标的图形系列的移动。直到最后一刻,我还在为ServiceDesk准备一篇火热的演讲稿,但在运行了几十次终端(甚至包括几次完整的电脑重启)后,一切都奇迹般地稳定下来。我不知道也无法猜测这一切的逻辑,但我的印象是,在这几十次重启过程中,终端似乎 "加速 "了,并最终 "适应 "了操作系统和/或终端的指标。是的,这听起来很神秘,但从逻辑上讲不应该是这样的:唯一的 "调整"--是全面加载历史,缓存使用过的时间框架,终端选项的精细手动调整和...这似乎就是全部。但所有这些都是在第一次 启动时完成的,随后的终端运行在状态上与第二次没有区别(最后一次历史下载和在图表中添加新闻标志是不相关的,所以我们不考虑它们)。

我还是有点困惑,我想这些问题会在半意外的情况下显示出来,然后我会处理它们,但现在还不是很快,同时--计划中的代码优化。如果纯粹为自己测试代码会很有趣--在我再次消失之前让我知道。

 
你说的 "奇迹般地稳定下来 "是指整个故事被鼓吹起来吗?嗯,这是可以预料的--历史是根据需要被抽出来的,这可能需要时间。

看看历史目录,看到数百兆字节的历史数据。
 
Renat:
你说的 "奇迹般地稳定下来 "是指整个故事抽风了吗?因此,这是可以预料的--历史被抽调出来是必然的,它可能需要时间。

在历史目录中查看,看到数百兆的历史数据。

事实恰恰相反。在个人视觉控制下,所有的历史记录在第一次启动时就被下载,在下载结束时,用Home 键检查,并进入到1994年M1 的开头。然后我手动绕过我经常使用的时间段,以及那些与多时态指标相关的时间段,等待它们的形成,并重新加载终端。这就是全部。

进一步少量下载新的历史数据不会有任何主要影响,也就是说,理论上,在第一次运行结束时,或者为了可靠性,在第二次运行开始时,当保证非M1产生的时间段在HDD上安顿好后,终端可以被视为 "稳定"。但这是理论上的。出于某种原因,一切都在第十次重启时安定下来(我说的是指标的正常工作),尽管我强调,主要的故事在第一次重启时就已经加载,随后的重启原则上不应该使天气......。我甚至会反过来说:故事越大,从运行到运行,指标在某个特定的运行中无法吞噬它而失败的风险就越大,但事实上是反过来的:越往后,效果越好)。

因此,也许有一些隐藏的和不为人知的终端MT5+操作系统组合的用户进程,在操作环境中不是立即优化应用程序,而是经过一些N次调整。我很久没有修改自己的源代码了,关于它的编译--只有在新安装的 MT5 第一次启动时(在这项研究中,其构建总是相同的)。第一次运行后没有进行任何调整。这整个神秘的情况让我想起了Windows 中的"开始"菜单,经常被调用的应用程序在时间上变得可用(操作系统收集了统计数据,但它需要时间和对相同程序的一定数量的调用)。或者说,对磁盘文件进行碎片整理可以优化磁盘访问,使应用程序运行得更快,这些都是同样的事情。

我不倾向于相信你在MT5 中实现了类似的东西,否则你要么自己报告,要么早就在论坛上被抓到询问了。所以这一切都只是基于经验的未经证实的假设。