Architecture
Five projects, one engine. The IDE authors, the hosts render, and BeepDM owns every piece of behavior.
The five projects
| Project | Role |
|---|---|
TheTechIdea.Beep.Forms.IDE | Visual Studio extension — the Object Navigator. Design-time authoring: create blocks, wire triggers/LOVs/validations, build the form menu, and generate the registrations into your form's designer file. |
TheTechIdea.Beep.Forms.WinForms | WinForms runtime controls (WinFormFormHost, block/field hosts, status bar) to host a BeepDM form on a WinForms form. |
TheTechIdea.Beep.Forms.Wpf | WPF runtime controls (BeepWpfForms, block/field hosts, status bar, LOV/alert dialogs) — the WPF equivalent, no WinForms, no System.Drawing. |
TheTechIdea.Beep.Forms.Examples.WinForms | Runnable WinForms demo app (Order Entry, Order Detail) with a headless --selftest switch. |
TheTechIdea.Beep.Forms.Examples.WPF | The same demo, on WPF, with its own --selftest switch. |
Beep.Forms.slnx opens all five together. This repo does not build standalone — it needs sibling repos checked out next to it under The-Tech-Idea/: BeepDM (engine + contracts), Beep.Winform (WinForms base controls + the shared Vis.Modules), Beep.WPF (WPF base controls), and Beep.Shared.
The engine owns everything; the UI is a thin layer
All form/block/item/trigger/LOV/validation/menu/master-detail behavior lives in BeepDM (DataManagementEngine / DataManagementModels). Neither the runtime hosts nor the IDE ever create engine objects or duplicate engine state — everything is reached only through public interfaces: IUnitofWorksManager, IDMEEditor, IBeepFormsHost, IBlockView.
The IDE authors, it never runs behavior: it writes registrations into the target project's .Designer.cs / .xaml.cs via DesignerCodeGenerator, into marker regions, and reads them back with the same regex/marker contract on the next open. The runtime hosts only render controls from a block definition and forward every user action — navigation, query-by-example, CRUD, menu clicks — straight to the engine.
The control libraries in .WinForms and .Wpf are extracts, not copies, of Beep.Winform.Data.Integrated / Beep.Wpf.Data.Integrated — only the Forms-specific controls were lifted out. App-shell services (routing, dialog manager, catalogs) were deliberately left behind; those belong to the host application, not to Beep.Forms.
Root namespaces are intentionally kept as the pre-extraction names — TheTechIdea.Beep.Winform.Data.Integrated.* / TheTechIdea.Beep.Wpf.Data.Integrated.* — so generated designer code keeps resolving. Assembly name and root namespace are deliberately not the same string; that's not a packaging mistake.
Payments — never in-process
If an app built on Beep.Forms ever needs to charge or check out a customer, integrate with the Beep.DoitAll Payments API over HTTP. Beep.DoitAll is a separate SaaS — it is never embedded in-process — and no vendor payment SDK is hand-rolled directly against.
See the Beep.DoitAll repo's docs/payments/EXTERNAL-API-INTEGRATION-GUIDE.md for endpoints, auth, and setup steps.
Platform independence is a hard rule
WPF takes zero System.Windows.Forms / System.Drawing references — one narrow, explicit exception: SimpleItem from the shared Vis.Modules layer. A WinForms-only feature needs an explicit WPF counterpart, or a tracked, documented deferral — it is never silently WinForms-only.
Application logic returns IErrorsInfo and reports through DMEEditor.AddLogMessage(...) rather than throwing — consistent across both runtime hosts.
The Oracle-naming legal boundary
Beep.Forms is deliberately Oracle Forms-style, not an Oracle Forms clone, and the naming boundary is a real, enforced rule — not a formality:
- Functional names that describe behavior are fine:
WhenValidateItem,PreInsert,ExecuteQuery. - Oracle's literal artifacts are not reproduced: its
FRM-nnnnnerror codes and.fmb/.fmx/.pll/.olbbinary file formats. BeepDM never parses Oracle's binary formats and uses its ownBEEP-error codes. - "Oracle Forms-compatible" is used only as descriptive, comparative language — never as a claim of file- or binary-level compatibility.