Strategies to Boost Harbour MiniGUI Extended and Attract New Generations

[Marcos Jarrin]

Hello everyone,

In order for Harbour MiniGUI Extended to gain greater acceptance, especially among the new generations of programmers, it is essential to develop libraries and practical examples that facilitate its adoption. It is also key to leverage social media as a dissemination channel to showcase its potential and concrete use cases.

I am sharing with you a piece that you can use on your own social media to contribute to this initiative. For my part, I am working on creating libraries that I will publish on GitHub, with the aim of contributing to the ecosystem and giving Harbour the relevance it deserves within software development.

I look forward to your comments and contributions.

Sincerely,
Marcos Jarrín

[Geoffrey Keenan]

All,

I came to Harbour and MiniGui via Clipper.

In the Clipper world there were many books which clearly explained the language and its usage. They clearly explained the language  and also explained the limitations and at the end of each command reference was a list of related commands.

I have converted all my Clipper apps to Harbour and they run OK, but sometimes I accept they would be 'nicer' if in a GUI format, so my interest in HMG Extended (HMGE). 

My main problem with HMGE is that I have little understanding of the 'boundaries' of the windows language as I have no other prior usage nor understanding of coding in a windows environment. I have coded up several apps in HMGE and - usually after a a large amount of research and 'trial and error' they work OK in the end but almost every one has taken a huge effort on my part in getting it to work. Ny main point here is there is relatively little information in the HMG world which explains 'the Windows experience'. That topic seems to be taken for granted by many of the the users of HMGE.  

Sure there are quite a number of very simple examples in HMGE of how open up a basic simple window and display a message or click on a button or whatever. But there is no instructions or list of the limitations of opening windows, eg how many windows can be open at any time, if there is a child window then should the parent window be closed, how to build a menu system, explanations of the various commands to close a window and what their differences etc. 

 

What I am saying is that I want to read a book - preferably as a hardcopy - which outlines the language when coding in a windows environment and what are its limitations & uses etc.

Such a book would need to explain simple stuff like creating a Windows screen and then all the necessary jargon with options, menus, closing a screen etc. And explanations for same. Eg, the importance of closing down a window once it has been used and will never be re-used etc. I see nothing in the HMGE documentation which mentions this, it seems to be 'taken for granted'. 

 

Also there should be simple examples of menues for the user to select an action on a screen. All 'bread and butter' stuff for the routine windows programmer, but essential for the 'newbies' to the world of this programming in a Windows environment.

If anyone knows the name of a suitable reference book then please advise.

Geoffrey

--
Visit our website on https://www.hmgextended.com/ or https://www.hmgextended.org/
---
You received this message because you are subscribed to the Google Groups "Harbour Minigui" group.
To unsubscribe from this group and stop receiving emails from it, send an email to minigui-foru...@googlegroups.com.
To view this discussion, visit https://groups.google.com/d/msgid/minigui-forum/76c5ffd2-894d-4cac-ac5f-8e1d07d10875n%40googlegroups.com.

-- 
Geoffrey Keenan
g.k.fi...@gmail.com


                       /\   
          ----        /  \
         /    \      /    \ 
       /        \__ /      \
     /                       \
    /                         |
   /                           \
 /                              |
|  G O   A U S T R A L I A !   /
|                             |
|                             |
 \         / - -             /
   \ _ _ /       \          /
                   \ _ - _ /

                    ______
                    \     /
                     \   /
                      \_/

[Grigory Filatov]

Hi Geoffrey,

Thank you very much for your feedback!

I've prepared a small article with a technically precise, expanded analysis of the key takeaways on Harbour MiniGUI Extended Edition (HMG Extended) .

Key Takeaways of Harbour MiniGUI for Developers

1. Architectural Positioning: Bridging Legacy xBase and Modern GUI

Harbour MiniGUI operates as a GUI abstraction layer on top of the Harbour compiler, itself a modern continuation of the xBase/Clipper ecosystem.

* It enables stateful, event-driven Windows applications while preserving procedural xBase paradigms.
* This makes it uniquely suited for:

  * Legacy system modernization
  * Rapid internal business tooling
  * Line-of-business desktop apps

Insight:
HMG Extended is not just a GUI toolkit—it’s a migration strategy. It minimizes cognitive load for Clipper developers by avoiding paradigm shifts (e.g., OOP-heavy frameworks like .NET or JavaFX).

---

2. Declarative UI via Command-Based Syntax

The document highlights MiniGUI’s DEFINE / ACTIVATE model, which is effectively a domain-specific language (DSL) for UI construction.

Characteristics:

* Declarative control placement (@ row, col)
* Inline event binding (ACTION)
* Automatic message loop handling


DEFINE WINDOW oWnd TITLE "My Application" MAIN
   @ 50, 50 BUTTON oBtn CAPTION "Click Me" ACTION MsgInfo("Button clicked!")
END WINDOW
ACTIVATE WINDOW oWnd

Developer Implications:

* Reduces boilerplate compared to WinAPI or even frameworks like MFC
* Improves readability and maintainability
* Encourages rapid prototyping

Insight:
This model trades flexibility for productivity—but in enterprise CRUD scenarios, that trade-off is highly favorable.

---

3. Rich Control Ecosystem with Practical Focus

MiniGUI provides a broad but pragmatic set of controls, emphasizing business application needs rather than visual novelty.

Notable Categories:

* Input: GET, ComboBox, CheckBox
* Structural: Panel, Tab, Group
* Data-centric: TSBrowse (critical component)
* Feedback: ProgressBar, StatusBar

Strategic Importance of TSBrowse:

* Acts as a data grid abstraction
* Supports:

  * Row navigation
  * Inline editing
  * Event hooks

Insight:
TSBrowse is effectively the centerpiece of data-driven UI design in HMG, comparable to DataGridView in .NET—but lighter and more customizable.

---

4. Reusability and Modularity Patterns

The document touches on macros, encapsulation, and external configs. These map to broader software engineering principles:

Key Patterns:

* Macro-driven configuration

  * Avoids hardcoding UI constants

* Factory-style control creation

  * Reusable UI builders

* Separation of concerns

  * UI definitions vs business logic

Advanced Practice:

* Externalizing UI definitions (JSON/XML) enables:

  * Dynamic UI rendering
  * Runtime customization
  * Multi-tenant UI variation

Insight:
While HMG is not inherently MVC, developers can approximate layered architectures with disciplined separation.

---

5. Event-Driven Programming Model

MiniGUI uses a callback-based event model, primarily through:

* ACTION
* ON EVENT

Example:


@ 50, 50 BUTTON oBtn CAPTION "Submit" ACTION SubmitForm()

Capabilities:

* UI interaction handling
* Menu command routing
* Window lifecycle events

Limitations:

* No native async/await model
* Requires manual state management

Insight:
The event model is simple but can become tightly coupled in large systems unless structured with dispatcher patterns or controller layers.

---

6. Database Integration as a First-Class Use Case

Database connectivity is not an add-on—it is core to the framework’s design philosophy.

Example:

oCon := HB_MYSQLCONNECT("localhost", "root", "password", "customers_db")

Capabilities:

* Direct SQL execution
* Binding to UI controls (especially TSBrowse)
* Real-time UI updates

Best Practices:

* Use connection pooling
* Limit result sets (pagination)
* Optimize queries

Insight:
HMG encourages a 2-tier architecture (UI + DB) rather than layered service architectures. This is efficient but may limit scalability in distributed systems.

---

7. Performance Optimization Strategies

The document correctly identifies practical optimization techniques:

Critical Areas:

* Grid rendering (TSBrowse)
* Database I/O
* UI responsiveness

Techniques:

* Pagination for large datasets
* Efficient SQL (projection + indexing)
* Connection reuse

Additional Advanced Considerations:

* Lazy loading in grids
* Event throttling (for UI-heavy interactions)
* Memory management for large arrays

Insight:
Performance bottlenecks in HMG apps are typically data-bound, not UI-bound.

---

8. Extensibility and Advanced Customization

HMG Extended supports deeper customization beyond default capabilities.

Extension Vectors:

* Custom controls
* Theming (colors, fonts)
* Timer-based updates
* External libraries (e.g., enhanced TSBrowse)

Real-Time Features:

* Polling via timers
* Event-triggered UI refresh

Insight:
While not inherently reactive, HMG can simulate reactive UI patterns through timers and event orchestration.

---

9. Strategic Use Cases

Based on the document, HMG is best suited for:

Ideal Scenarios:

* Legacy Clipper migration
* Internal enterprise tools
* Database-heavy desktop apps
* Rapid application development (RAD)

Less Suitable For:

* Highly interactive modern UX (animations, fluid UI)
* Cross-platform desktop apps
* Web-first architectures

---

10. Core Strengths vs Trade-offs

Strengths:

* Extremely fast development cycle
* Low learning curve (for xBase developers)
* Tight DB integration
* Lightweight runtime

Trade-offs:

* Windows-only ecosystem
* Limited modern UI paradigms
* Manual architecture discipline required

---

Final Synthesis

Harbour MiniGUI Extended is best understood as a productivity-first RAD framework for database-driven desktop applications, optimized for developers with xBase lineage.

Its real power lies in:

* Simplicity of UI definition
* Tight coupling with data workflows
* Ease of modernization from legacy systems

However, extracting long-term value requires:

* Enforcing modular design patterns
* Managing event complexity
* Optimizing database interactions

---

Explanation of the term

MVC (Model–View–Controller) is an architectural pattern that separates an application into three distinct layers:

1. Model

* Handles data and business logic
* Interacts with databases, validation, and rules
* Example: fetching or updating customer records

2. View

* Handles UI/presentation
* Displays data to the user
* Example: windows, forms, grids in HMG

3. Controller

* Handles input and coordination
* Receives user actions, calls the Model, updates the View
* Example: button click -> save data -> refresh grid

---

In one line:

MVC separates data, UI, and logic to improve maintainability, scalability, and clarity.

Below is a practical, production-oriented MVC-style architecture template for Harbour MiniGUI Extended (HMG Extended). This is not native to HMG, so the design enforces separation manually using conventions, modules, and disciplined event routing.

---

1. High-Level MVC Mapping in HMG

HMG is inherently event-driven and procedural, so MVC must be *layered on top*:

| Layer          | Responsibility                                    |
| -------------- | ------------------------------------------------- |
| Model          | Data access, business rules, validation           |
| View           | HMG UI definitions (WINDOW, CONTROLS)             |
| Controller     | Event routing, orchestration between View ↔ Model |

---

2. Recommended Project Structure

/app
   main.prg

/controllers
   customer_controller.prg
   order_controller.prg

/models
   customer_model.prg
   db_connection.prg

/views
   customer_view.prg
   shared_controls.prg

/services (optional but recommended)
   validation_service.prg
   logging_service.prg

/config
   app_config.prg

/lib
   helpers.prg

---

3. Bootstrapping (Entry Point)

main.prg

FUNCTION Main()
   InitApp()
   ShowCustomerScreen()
RETURN NIL

app_config.prg

FUNCTION InitApp()
   PUBLIC g_oDb
   g_oDb := ConnectDatabase()
RETURN NIL

---

4. Model Layer (Data + Business Logic)

models/customer_model.prg

FUNCTION Customer_GetAll()
   LOCAL aData := {}

   // Query database
   aData := DB_Query("SELECT id, name, email FROM customers")

RETURN aData

FUNCTION Customer_Save(cName, cEmail)
   IF Empty(cName)
      RETURN .F.
   ENDIF

   DB_Exec("INSERT INTO customers (name, email) VALUES (?, ?)", {cName, cEmail})

RETURN .T.

models/db_connection.prg

FUNCTION ConnectDatabase()
   RETURN HB_MYSQLCONNECT("localhost", "root", "password", "app_db")

---

5. View Layer (UI Definition Only)

Principles:

* No business logic
* Only UI + event bindings
* Delegate all actions to Controller

---

views/customer_view.prg

FUNCTION ShowCustomerScreen()

   DEFINE WINDOW oWnd TITLE "Customers" MAIN

      @ 10,10 GRID oGrid ;
         WIDTH 400 HEIGHT 200 ;
         HEADERS {"ID", "Name", "Email"} ;
         ITEMS {} ;
         VALUE 1

      @ 220,10 BUTTON oBtnLoad CAPTION "Load" ;
         ACTION CustomerController_Load(oGrid)

      @ 220,100 BUTTON oBtnAdd CAPTION "Add" ;
         ACTION CustomerController_Add()

   END WINDOW

   ACTIVATE WINDOW oWnd

RETURN NIL

---

6. Controller Layer (Core Orchestration)

Responsibilities:

* Handle UI events
* Call Model functions
* Update View

---

controllers/customer_controller.prg

FUNCTION CustomerController_Load(oGrid)
   LOCAL aData

   aData := Customer_GetAll()

   oGrid:DeleteAllItems()
   AEVAL(aData, {|row| oGrid:AddItem(row)})

RETURN NIL

FUNCTION CustomerController_Add()
   LOCAL cName := InputBox("Enter Name")
   LOCAL cEmail := InputBox("Enter Email")

   IF Customer_Save(cName, cEmail)
      MsgInfo("Customer saved")
   ELSE
      MsgStop("Validation failed")
   ENDIF

RETURN NIL

---

7. Service Layer (Optional but Strongly Recommended)

Used for cross-cutting concerns.

services/validation_service.prg

FUNCTION ValidateEmail(cEmail)
   RETURN "@" $ cEmail

Use in Controller:

IF !ValidateEmail(cEmail)
   MsgStop("Invalid email")
   RETURN NIL
ENDIF

---

8. Event Routing Pattern (Critical for Scalability)

Avoid this ❌:

ACTION Customer_Save(...)

Prefer this ✅:

ACTION CustomerController_Add()

Why:

* Keeps View decoupled
* Centralizes logic
* Easier debugging and testing

---

9. State Management Strategy

HMG lacks built-in state containers, so use:

Option A: PUBLIC variables (simple apps)

PUBLIC g_aCustomers

Option B: Controller-managed state (preferred)

STATIC s_aCustomers := {}

Option C: Context object (advanced)

FUNCTION AppContext()
   STATIC oCtx := {=>}
RETURN oCtx

---

10. Advanced Pattern: View Refresh Decoupling

Instead of directly manipulating controls everywhere:

Controller:

FUNCTION CustomerController_Refresh(oGrid)
   LOCAL aData := Customer_GetAll()
   UpdateGrid(oGrid, aData)
RETURN NIL

Helper:

FUNCTION UpdateGrid(oGrid, aData)
   oGrid:DeleteAllItems()
   AEVAL(aData, {|row| oGrid:AddItem(row)})
RETURN NIL

---

11. Error Handling Strategy

Centralize error handling:

FUNCTION SafeExecute(bBlock)
   BEGIN SEQUENCE
      Eval(bBlock)
   RECOVER
      MsgStop("Unexpected error occurred")
   END SEQUENCE
RETURN NIL

Usage:

SafeExecute({|| CustomerController_Load(oGrid)})

---

12. Scaling the Architecture

For larger systems:

Introduce:

* Repository layer (wrap DB access)
* DTOs (data transfer arrays/objects)
* Module-based controllers

---

13. Common Anti-Patterns to Avoid

❌ Mixing SQL inside Views
❌ Business logic inside ACTION blocks
❌ Direct control manipulation from Models
❌ Global variable overuse
❌ Monolithic .prg files

---

14. Minimal MVC Flow (Execution Trace)

1. User clicks button
2. View triggers:

   ACTION CustomerController_Load(oGrid)

3. Controller:

   * Calls Model → fetch data
   * Updates View (grid)

4. Model:

   * Executes SQL
   * Returns structured data

---

Final Takeaway

In HMG Extended, MVC is convention-driven, not framework-enforced.

To make it work effectively:

* Treat Controllers as the brain
* Keep Views dumb
* Keep Models pure and reusable
* Introduce Services for cross-cutting logic

This structure transforms HMG from a simple RAD tool into a maintainable, scalable desktop application platform.

Hope this is helpful.

Best regards,

Grigory

воскресенье, 22 марта 2026 г. в 01:03:49 UTC+1, Geoff K: