Discussing the article: "MQL5 Trading Tools (Part 40): Adding SQLite Persistence and Per-Timeframe Visibility to the Canvas Drawing Layer"
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Check out the new article: MQL5 Trading Tools (Part 40): Adding SQLite Persistence and Per-Timeframe Visibility to the Canvas Drawing Layer.
We add SQLite persistence to the canvas tools, saving every drawing and the entire UI session per symbol, then restoring them on startup so the workspace resumes exactly where you left it. The article builds versioned object serialization, a load/save lifecycle with dirty writes, and a timeframe-visibility editor that drives render-time filtering. The toolkit also runs as an indicator, so it can sit alongside other indicators or an Expert Advisor.
Persistence comes down to two questions: what state matters, and where do we keep it. Three kinds of state matter here. There are the drawn objects themselves; their geometry, their styles, and now the timeframe mask that says where each one shows. There is the per-tool style memory that remembers how we last configured each tool. And there is the interface session; the theme, the sidebar's position and height, both ribbons' last placements, the pinned set, the active tool, and the current selection. Lose any of these, and the workspace feels like it forgot us between sessions.
For where to keep it, we reach for MQL5 SQLite, which MetaTrader 5 ships with built-in, so we get a real database with no external dependency. We lay it out as two simple stores: one that holds the drawn objects keyed per symbol, so each chart restores only its own marks, and one key-value store for the interface session. Rather than freeze each object as a rigid binary blob, we serialize it to a versioned text payload, so the format can grow in later parts without breaking the rows already written. To keep the writes cheap, we mark the state dirty only when something actually changes, flush when the activity settles, and again on shutdown, and read everything back once on startup.
The visibility side is a smaller idea sitting on the same foundation. Basically, we extended what we built; we felt we could control this from the main terminal window, but for better control, we brought it to our side. We give every object a mask of the periods it should appear on, the render pass skips any object whose mask excludes the current chart period, and a dedicated tab lets us edit that mask per object. Converting the program to an indicator lets it run alongside other tools instead of occupying the single Expert Advisor slot. This matters more once the chart becomes a durable, shared workspace. So, we can now attach it alongside other utility tools, indicators, and Expert Advisors. In a nutshell, here is what we intend to achieve.
Author: Allan Munene Mutiiria