Managing Chart Objects with a Shared MQL5 Collection

Summary

This installment describes refactoring a graphical library so that library objects have identifiable types and can track the chart objects they create. It introduces parent and child relationships: a graphical object can retain a pointer to its creator, while the parent keeps references to its objects. A shared collection is intended to hold both program-created objects and objects added manually through the trading terminal.

The collection periodically checks open charts for additions and deletions, then creates or removes corresponding library representations. The article adds type identifiers and timer settings, and presents a test in which graphical objects are added to multiple charts and deleted, with events reported in the journal. This is software architecture for chart-interface management rather than a trading method. It is groundwork for later library development; the account says not all graphical object types are ready, and defers further collection refinement and pointer handling.

Key ideas

• Library objects receive type identifiers so their kinds can be recognized.
• Graphical objects maintain links to their parent library objects, which track their children.
• A shared collection tracks objects created by code and objects added manually to charts.
• The collection monitors open charts for object creation and deletion.
• The test demonstrates journal messages for chart object changes, while further development remains planned.

Tags

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.