4th Dimension Learning Basics

Key Takeaways

• 4D’s built-in charting is a native part of the development environment, not a bolt-on — which changes how you plan reports, dashboards and data visualization from day one.
• FileMaker Pro historically shipped without a native charting engine, so developers there relied on calculation tricks or third-party plug-ins to draw graphs.
• Choosing a platform is rarely about one feature; charting is a useful lens for comparing total cost of ownership, workflow friction and long-term maintainability.
• The Chart Wizard approach — pick a type, pick a style, pick the data — reflects 4D’s broader design philosophy of exposing powerful features through guided, declarative tools.
• Understanding why a feature is built in versus bolted on helps you predict where you’ll spend your maintenance budget years later.

Why Charting Is a Useful Lens for Comparing Platforms

When people compare database and low-code platforms, they usually start with the obvious axes: the data model, the query language, the deployment story. Charting rarely makes the first page of the comparison. That is a mistake, because data visualization sits at the intersection of several things that matter a great deal over the life of an application: how much custom code you must write, how many third-party dependencies you accumulate, and how easily a non-specialist can produce a report without calling a developer.

The original 4th Dimension Learning Basics material made a pointed observation: FileMaker Pro (FMP) had no built-in charting function, while 4D included charting as part of its Standard Edition. That single contrast tells you something about the two products’ philosophies. One treats visualization as an add-on you assemble from plug-ins or elaborate workarounds; the other treats it as a first-class capability of the environment.

This article expands on that observation. It is not a head-to-head benchmark — it is a guide to thinking about charting, reporting and platform choice the way an experienced 4D developer would, with an eye on what actually costs you time and money after the initial build.

The Original Comparison: Built-In Versus Bolted-On

The core claim from the source material is worth restating precisely, because it is easy to lose in the retelling:

• FileMaker Pro had no built-in charting function. Developers who wanted charts either constructed them through elaborate calculation tricks or purchased plug-ins to do the work. Either path was more complex than the 4D equivalent.
• 4D shipped charting as part of the product. The workflow was to open the Chart Wizard, choose the chart kind, choose a style, and then select the data to be graphed.

That is the whole of the original comparison, and it is a fair one. The important nuance is what kind of complexity each path introduces. A plug-in is not inherently bad — the plug-in ecosystem around FileMaker has produced genuinely capable tools.

But a plug-in is a dependency. It has its own versioning, its own licensing, its own compatibility matrix against the host application, and its own support lifecycle. When the host platform ships a major update, you are at the mercy of the plug-in vendor’s release schedule.

A built-in feature has none of those external dependencies, but it has a different trade-off: you are limited to what the vendor chose to implement. If the built-in charting does not support the specific visualization you need, you are back to workarounds — just different ones.

So the honest framing is not “built-in good, plug-in bad.” It is:

Consideration	Built-in charting (4D-style)	Plug-in / workaround charting (FMP-style)
Initial setup	Guided wizard, no extra purchase	Install plug-in or write calculation logic
Licensing	Included with the edition	Often an additional cost
Dependency risk	Tied to host platform updates	Tied to both host and plug-in vendor
Customization ceiling	Bounded by vendor feature set	Potentially higher, if the plug-in is capable
Maintenance burden	Vendor-managed	Shared between you and the plug-in vendor
Skill required	Familiarity with the wizard	Deeper technical knowledge

The takeaway for a small-team builder is straightforward: count your dependencies. Every external component is something that can break independently of your own code.

How the 4D Chart Wizard Workflow Actually Feels

The source material describes the 4D charting flow in three steps, and it is worth unpacking because the simplicity is the point:

1. Select the Chart Wizard. You are not writing rendering code. You are invoking a guided tool.
2. Choose the chart kind and style. Bar, line, pie and similar families, plus the visual treatment.
3. Choose the data to be graphed. You point the chart at the data you want represented.

This declarative pattern — describe what you want, not how to draw it — is the same philosophy that runs through 4D’s form editor, its value lists, and its broader low-code surface. If you have built forms in 4D, the charting workflow will feel familiar: you are configuring, not programming.

For developers coming from a hand-coded charting background — think of the JavaScript charting libraries that dominate web development, such as D3.js or Chart.js — this can feel almost too easy. The trade-off is control.

A hand-coded chart can do anything; a wizard-driven chart does what the wizard offers. For the vast majority of business reporting — monthly sales by region, headcount by department, ticket volume over time — the wizard’s range is more than sufficient, and it gets you there in minutes rather than days.

The practical guidance: reach for the built-in tool first, and only escalate to custom rendering when you have a genuinely unusual visualization requirement. Most “we need a custom chart” requests turn out to be standard charts with unusual data, which is a query problem, not a rendering problem.

Charting as Part of a Larger Reporting Strategy

Charting does not exist in isolation. In any real business application, a chart is the visible tip of a pipeline that runs roughly like this:

• Data model — tables, fields, relations. If the underlying structure is wrong, no chart will save the report.
• Query / selection — which records, which time window, which grouping.
• Aggregation — sums, counts, averages, grouped by a category.
• Presentation — the chart type, labels, axes, colors.
• Distribution — on-screen, printed, exported, or embedded in a form.

The Chart Wizard addresses the last two stages. The first three are where the real engineering lives, and they are platform-agnostic. This is why a developer who understands relational design and aggregation will produce good reports on any platform, while a developer who does not will struggle even with the best built-in tools.

A useful discipline: before you open the Chart Wizard, write down in plain language what question the chart answers. “Which product lines grew fastest last quarter?” is a question. “A bar chart of the sales table” is not. The question determines the grouping, the time window and the chart type. Skipping this step is the most common reason a chart gets rebuilt three times.

Choosing Between Built-In and Third-Party Visualization

If you are evaluating 4D against another platform, or deciding whether to extend 4D’s native charting, use a structured decision process rather than a feature checklist.

Decide in favor of built-in charting when:

• Your visualizations are conventional business charts (bar, line, pie, area).
• You value a short path from data to a finished report.
• You want to avoid per-seat or per-server plug-in licensing.
• Your team includes citizen developers who are not programmers.
• You want the chart to survive platform upgrades without vendor coordination.

Consider third-party or custom visualization when:

• You need chart types the built-in tool does not offer (specialized statistical or geographic plots, for example).
• You need pixel-level control over rendering for a customer-facing product.
• You are embedding charts in a web or mobile front end with its own rendering stack.
• You have a specific accessibility or branding requirement the wizard cannot meet.

Regardless of which you choose, watch for:

• Dependency count. Each external library is a future upgrade risk.
• Data volume. Charts that render instantly on test data can crawl on production data. Aggregate in the query, not in the chart.
• Refresh behavior. Decide whether a chart reflects live data or a snapshot, and make that explicit to users.
• Consistency. Ten charts built ten different ways is a maintenance nightmare. Standardize on one approach per application.

The Broader 4D Learning Path

Charting is one chapter in a larger story. The 4th Dimension Learning Basics contents page situates it alongside topics that every 4D developer eventually needs:

• System requirements — what the platform needs to run.
• Program structures — how 4D organizes code and objects.
• Networking differences — how multi-user deployments behave.
• Differences in runtimes — the distinction between development and deployed environments.
• Compiler — moving from interpreted to compiled execution.
• Web hosting — exposing 4D data to the web.
• Data charting — the subject of this article.
• Plug-ins — extending the platform.
• Tools and utilities — the surrounding ecosystem.
• Resources and other 4D URLs — where to keep learning.

Notice that charting sits between web hosting and plug-ins. That placement is meaningful: charting is a presentation concern that often meets the web, and it is the feature most likely to tempt you toward plug-ins. Understanding it in that context — as one node in a network of capabilities — is more useful than learning it in isolation.

For developers building a learning plan, a sensible order is: data model first, then forms and value lists, then queries and selections, then reporting and charting, then deployment and networking. Charting is a reward for getting the earlier layers right, not a substitute for them.

Practical Habits That Make Charting Easier

A few habits separate developers who produce good reports quickly from those who fight their tools:

• Model for reporting, not just for storage. If you know you will report by month, store a proper date field rather than parsing a text string later.
• Name things for humans. A field called inv_total_net is easier to chart correctly than one called f17.
• Keep a chart library. Save your standard chart configurations so a new report starts from a known-good template.
• Test with realistic data volumes. A chart that works on fifty records may not work on fifty thousand.
• Document the question each chart answers. Future maintainers — including you — will thank you.

These habits are platform-neutral, which is exactly why they are worth internalizing. The specific tool — 4D’s Chart Wizard, a FileMaker plug-in, or a JavaScript library — will change. The discipline of turning a business question into a clean data pipeline will not.

Frequently Asked Questions

Does 4D include charting, or is it an extra-cost add-on?

In the era described by the original 4th Dimension Learning Basics material, charting was built into 4D and included with the Standard Edition, rather than sold separately. That contrasts with FileMaker Pro at the time, which had no built-in charting function and required either elaborate workarounds or purchased plug-ins. Always confirm the current feature set and edition packaging with the vendor, since product tiers change over time.

How does the 4D Chart Wizard work?

The workflow is deliberately simple: you select the Chart Wizard, choose the kind of chart you want and its style, and then select the data to be graphed. It is a declarative, guided process rather than a programming task, which makes it accessible to developers who are not full-time programmers. The trade-off is that you are working within the range of chart types and options the wizard provides.

Why would a developer prefer built-in charting over a plug-in?

The main reasons are dependency management and cost. A built-in feature is maintained by the platform vendor and moves with platform upgrades, while a plug-in adds a second vendor, a second licensing arrangement and a second compatibility matrix. Built-in charting also tends to be faster to use for conventional business charts, because there is no installation or configuration step.

When should I use a third-party or custom charting solution instead?

When your visualization needs fall outside what the built-in tool offers — specialized statistical plots, geographic maps, or pixel-level control for a customer-facing product, for example. Custom rendering also makes sense when you are embedding charts in a web or mobile front end that has its own rendering stack. The key is to treat it as a deliberate trade-off, not a default.

Is charting a good reason to choose one database platform over another?

It is one input among many, and rarely the deciding one on its own. Data modeling, query capability, deployment options, licensing and the availability of skilled developers usually matter more. That said, charting is a useful proxy for a platform’s overall philosophy: whether it favors guided, built-in tools or an assemble-it-yourself ecosystem. That philosophy will affect your maintenance burden for years.

What should I learn before tackling charting in 4D?

Get comfortable with the data model, forms and value lists first, then queries and record selections. Charting sits at the presentation end of a pipeline that starts with table design and aggregation, so weaknesses earlier in the chain will show up as bad charts. Once the data layer is sound, the Chart Wizard becomes a quick and pleasant step rather than a source of frustration.