Search the Community

After finishing migration from D2007 I could finally use libraries that previously were not available to me Now I needed to add an Event Bus implementation to my toolbox, and was between Delphi Event Bus and NX Horizon So I asked Claude Code to make me a summary of each one, and also an argumented list of strengths and weaknesses Then I asked it to assess me for my use case (I'm an ERP developer) spinettaro/delphi-event-bus: Delphi Event Bus (for short DEB) is an Event Bus framework for Delphi dalijap/nx-horizon: NX Horizon - Event Bus for Delphi ● Event Bus Comparison & Recommendation for CyberMAX ERP After analyzing both implementations, here's my detailed comparison and recommendation: Architecture Comparison | Aspect | Delphi Event Bus (DEB) | NX Horizon | |--------------|--------------------------------------------|--------------------------------------------| | Code Size | 1,790 lines (4 files) | 715 lines (1 file) | | Event Types | Dual: Interface-typed + Named channels | Single: Type-based (TypeInfo) | | Thread Modes | 4 modes (Posting, Main, Async, Background) | 4 modes (Sync, Async, MainSync, MainAsync) | | Subscription | Attribute-based ([Subscribe], [Channel]) | Programmatic with interface return | | Min Version | Delphi 2010 | Delphi XE4 | | Thread Pool | Custom (Delphi 28.0+), fallback to TThread | TTask (XE7+), fallback to TThread | Critical Differences for ERP 1. Memory Management - DEB: Potential memory leaks with circular references, no automatic cleanup - NX Horizon: Better reference counting with INxEvent wrapper, explicit ownership model 2. Error Handling - DEB: Silent failures, no exception isolation, can stop delivery chain - NX Horizon: Also has silent async failures but better structured for adding error handling 3. Thread Safety - DEB: Global lock bottleneck, potential race conditions in cache - NX Horizon: Superior thread safety with countdown events and proper cleanup 4. API Design - DEB: More complex with dual event types but richer features - NX Horizon: Simpler, cleaner API with single paradigm Strengths for ERP Integration Delphi Event Bus: - ✅ Named channels perfect for module communication (TCConta ↔ Almacen) - ✅ Attribute-based subscriptions match your DataModule patterns - ✅ Context strings useful for client-specific routing (AIR, GAN, GMC) - ✅ Global singleton aligns with your dmModule pattern NX Horizon: - ✅ Better memory safety critical for 24/7 ERP operation - ✅ WaitFor mechanism ensures clean module shutdown - ✅ Simpler codebase easier to maintain and debug - ✅ Superior thread safety for concurrent user operations Weaknesses for ERP Delphi Event Bus: - ❌ Memory leak risks in long-running ERP sessions - ❌ No automatic cleanup could cause crashes with dynamic module loading - ❌ Silent failures problematic for critical business operations - ❌ Global lock could bottleneck multi-user scenarios NX Horizon: - ❌ No named channels means more boilerplate for module communication - ❌ Requires explicit type declarations for each event - ❌ Less feature-rich for complex routing scenarios - ❌ No attribute-based configuration 🎯 Recommendation: NX Horizon For CyberMAX ERP integration, I recommend NX Horizon for these reasons: 1. Reliability: Superior memory management and thread safety are critical for an ERP that runs continuously and handles financial data. 2. Maintainability: Single-file implementation (715 lines) is easier to understand, debug, and modify than DEB's 4-file architecture. 3. Safety: The WaitFor pattern aligns perfectly with your DataModule lifecycle, ensuring clean shutdown of interdependent modules. 4. Performance: No global lock bottleneck means better scalability for multiple concurrent users. 5. Integration Path: The type-based approach maps well to your existing record types (dmodModule.records.pas). Integration Strategy // Define events for module communication type TFacturaCreatedEvent = INxEvent<TFacturaRecord>; TStockUpdateEvent = INxEvent<TAlmacenMovimiento>; TContaAsientoEvent = type Integer; // AsientoID // In your DataModule hierarchy TdmModuleHigh = class(TdmModule) private fEventSubscriptions: TList<INxEventSubscription>; public procedure AfterConstruction; override; procedure BeforeDestruction; override; end; Migration Considerations If you need channel-like behavior, create a wrapper: type TChannelEvent = record Channel: string; Data: TValue; end; TChannelMessage = INxEvent<TChannelEvent>;

After many times of copying and pasting debug messages (OutputDebugString) from the debugger view to the Claude Code (CC) form, so it could read it all, I decided making a MCP server that will just provide that: services to catch and read debug messages I had no idea on how to do that, but nevertheless asked Claude (rhe chat) to make a plan for it, so CC could just follow the instruction. Then asked CC to add it to one test MCP server I already had working. With help from another CC instance that connected to the server and tried using it, and finding why it errores, it's working now I've attached the initial document that Claude made (could have asked it to GPT or Gemini or whatever) Then I asked the CC instance that was using it for helpful enhancements I've attached both documents If there is interest on it, I could make a public repo MCP-debug-server.md MCP-debug-server-enhancements.md