Hey Developers! 👋
If you work with Rocket Uniface, you know how powerful ProcScript is for building business applications quickly. But let’s be honest—sometimes you hit a wall. Maybe you need to perform a heavy statistical calculation that takes ages, or you have to interface with a specific piece of hardware or a legacy system that just doesn't speak "Uniface."
That's where 3GL integration (Third Generation Language) comes in. It’s the bridge that lets you combine the rapid development of Uniface with the raw performance and flexibility of languages like C or C++.
In this post, I want to share why you might need this and how it generally works (specifically around Uniface 10.4).
Why bother with 3GL? 🤷♂️
Uniface is fantastic, but it's a 4GL (Fourth Generation Language). It abstracts a lot of complexity, which is great for productivity but can be a limitation for low-level tasks.
Here are the main scenarios where dropping down to 3GL makes sense:
- Complex Calculations: ProcScript isn't designed for number-crunching. A compiled C function can calculate complex algorithms or scientific data exponentially faster.
- Call-Outs & Call-Ins:
- Call-Out: You are in Uniface and need to run a specific C function (e.g., for a checksum calculation).
- Call-In: You have a C/C++ application and need to trigger a Uniface report or form.
- Custom Connectivity: Sometimes you need to talk to a database or API that Uniface doesn't support out of the box. You can write your own "glue code."
- Custom Widgets: If the standard Uniface widgets don't cut it, you can build your own UI components (User-Defined Widgets) using 3GL.
The Magic Ingredient: CRG (Component Request Glue) 🧩
To make Uniface and 3GL talk to each other, they need a translator. In the Uniface world, this is often referred to as CRG or the Component Request Glue.
Think of it as a middleware layer. When Uniface wants to call a C function, it doesn't just jump into the memory address. It goes through a defined interface that handles data conversion (e.g., converting a Uniface string to a C char*) and memory management.
Key Concept: h3gl.h
If you are writing C code to interact with Uniface, your best friend is the h3gl.h header file. This file contains all the definitions and function prototypes you need to interact with the Uniface kernel. It ensures your data types align correctly across different platforms.
A Simple Example Scenario: The "Call-Out" 📞
Imagine you have a C function calc_complex_tax in a DLL (or shared object on Linux).
1. The 3GL Side (C/C++):
You write your function and ensure it matches the signature expected by Uniface. You compile this into a shared library.
#include "h3gl.h"
void calc_complex_tax( char *input_amount, char *output_tax ) {
// ... perform heavy math here ...
// convert result back to string for Uniface
}
2. The Uniface Side (ProcScript):
You declare this function in Uniface so it knows where to find it. Then, you just call it like any other ProcScript command:
activate "MY_MATH_LIB".calc_complex_tax(AMOUNT, TAX_RESULT)
Note: This is a simplified view. In reality, you need to handle data types and the signature in the Uniface signature editor.
Things to Watch Out For ⚠️
- Dependencies: If your 3GL DLL depends on other libraries, make sure they are in the system path (
PATHorLD_LIBRARY_PATH). Tools like "Dependency Walker" are lifesavers here. - Memory Management: 3GL languages like C require manual memory management. If you mess up pointers, you can crash the entire Uniface application (the famous "segmentation fault").
- Platform Differences: A DLL compiled for Windows won't work on Linux. You need to recompile your 3GL code for every OS you support.
Summary
Integrating 3GL into Uniface isn't something you do every day, but it's a superpower to have in your back pocket. It allows you to extend your application's capabilities beyond the standard toolset, whether for performance, connectivity, or custom UI needs.
Have you ever had to write a C-extension for a Uniface app? Let me know in the comments! 👇
Happy Coding! 🚀
Top comments (0)