文章 "精通日志记录（第九部分）：实现构造器模式并添加默认配置"
您是否考虑过添加运行时停止日志？当然，开发人员在 EA 中进行处理是很正常的。
TerminalInfoString(TERMINAL_LANGUAGE);
根据以下代码，日志的默认错误输出语言可恢复为用户的终端语言
Spoxus Spoxus 生产 代码，如果我们关闭了某些日志，它就不应该被编译到最终的 ex5 文件中。
为此，您可以在专家中使用一个变量或 IP 地址来存储所需的级别值，并将其传递给处理程序即可。下面是一个例子。
//+------------------------------------------------------------------+ //| 进口| //+------------------------------------------------------------------+ #include <Logify/Logify.mqh> CLogify Logify; //+------------------------------------------------------------------+ //| 输入| //+------------------------------------------------------------------+ input ENUM_LOG_LEVEL InpLogLevel = LOG_LEVEL_INFO; // 日志级别 //+------------------------------------------------------------------+ //| 专家初始化函数| //+------------------------------------------------------------------+ int OnInit() { Logify.EnsureDefaultHandler(); Logify.GetHandler(0).SetLevel(InpLogLevel); Logify.Debug("RSI indicator value calculated: 72.56", "Indicators", "Period: 14"); Logify.Info("Buy order sent successfully", "Order Management", "Symbol: EURUSD, Volume: 0.1"); Logify.Error("Failed to send sell order", 10016,"Order Management"); //--- return(INIT_SUCCEEDED); } //+------------------------------------------------------------------+
这将只显示严重程度大于或等于处理程序中定义的严重程度的信息。
这是我见过的最好的文章--我喜欢！
Spoxus Spoxus 生产 代码，如果我们关闭了某些日志，它就不应该被编译到最终的 ex5 文件中。
joaopedrodev#:
要做到这一点，可以在专家中使用一个变量或 IP 地址来存储所需的级别值，然后将其传递给处理程序即可。下面是一个例子。
这将只显示严重程度大于或等于处理程序中定义的严重程度的信息。
作者展示了如何在运行时更改级别，而无需修改代码。
我认为他只是想只显示一个级别的日志。他必须像下面这样修改代码：
//--- E.G. void CLogifyHandlerComment::Emit(MqlLogifyModel &data) { //--- 检查日志级别是否允许 if(data.level != this.GetLevel()) // 将'<'改为'！=' { return; } //-- 保持历史记录的轮班日志 for(int i = m_config.size-1; i > 0; i--) { m_cache[i] = m_cache[i-1]; } m_cache[0] = data; //--- 生成完整的注释 string comment = BuildHeader(); comment += FormatLogLines(); comment += BuildFooter(); //--- 显示在图表上 Comment(comment); }
新文章 精通日志记录（第九部分）：实现构造器模式并添加默认配置已发布：
我在各类个人与专业项目中使用 Logify 后很快发现，该库的核心问题并非在于自身的稳定性或功能完整性，而是配置环节过于繁琐。Logify 是一款用于管理 EA 日志的高效工具，内置多类处理器、多级别日志控制、自定义格式、多语言支持等丰富功能。但这些功能的使用，要求用户为每一个处理器、格式化器和参数逐一手动配置。对于小型项目而言，这种方式或许尚能接受；但随着 EA 及项目数量的增加，该操作会迅速沦为重复、繁琐且极易出错的工作。
试想，你需要在每个 EA 中重复复制一套套复杂的配置：为注释、控制台、文件、数据库创建专属处理器；为每个处理器设定最低日志级别；为错误消息、调试信息、告警信息等定义专属格式。这些步骤虽必不可少，却会产生冗长、冗余且可读性差的代码，严重影响开发效率和节奏。这种上手阶段的复杂性会形成使用门槛，甚至可能导致开发者放弃使用 Logify—— 即便该库在运行阶段的日志管理能力堪称完美。
这一问题促使我思考：如何在保留库的灵活性与可定制性的前提下，简化配置流程，降低用户使用成本？正是在此刻，为 Logify 创建一个构造器的想法应运而生。这是一个允许以流畅、链式的方式组装整个配置的类，它通过直观的方法创建具有合理默认模式的处理器，并允许快速进行局部调整。我们的目标是把原本数十行的配置代码，简化为寥寥数行方法调用 —— 就像编写一份清晰的 “需求清单”，而非手动完成繁琐的组装工作。
在本文中，我将展示我是如何实现这些改进的。我会介绍构造器，解释其设计思路与使用方法，并通过实际示例演示如何配置 Logify。
作者：joaopedrodev