FiveTech Support Forums

Hello friends, I’d love to kick off a discussion about web and hybrid projects—especially in the context of Harbour, FiveWin, or dBASE. Whether you’re just experimenting, deep in development, or already running something in production, your insights could help others (and maybe even spark some collaborations!). Where do you stand?

Who’s actively working on web/hybrid projects (as extensions to desktop apps or standalone solutions)? Who already has something live in production (internally or publicly)? What stack/tech are you using? Who’s just getting started and looking for guidance? What’s holding you back? Key questions for the exchange:

Technical hurdles: What surprised you? (Session management, caching, deployment, security, performance?) Infrastructure: How do you handle hosting, scaling, or backups? Any tools/services you’d recommend? Harbour integration: How do you bridge Harbour logic with web tech?

Lessons learned: What would you do differently today? (Architecture, database design, UI/UX?) Practical tips: Libraries, frameworks, or templates that saved you time? Data handling: How do you manage large datasets—especially if you’re used to direct file analysis or simple folder-based organization?

Why this matters: This is a chance for beginners and veterans to learn from each other. Maybe we can even solve common pain points together! Bonus for advanced users:

How do you handle offline capabilities in hybrid apps? Any experience with AI integration (e.g., automation, data analysis)? Your turn!

Got code snippets, war stories, or best practices to share? See a topic missing? Let me know—I’ll update the list! Looking forward to your experiences, opinions, and debates—let’s make this a useful thread for all of us. Best regards, Otto PS: If you’ve got questions I didn’t cover, drop them below. The goal is to build a go-to resource for the community.

Dear Otto.

Where Are You?

Sorry, I am still nowhere, it means, stopped in desktop environment. But I am paying attention about all opportunities that are showing.

Best regards.

Dear Otto Who’s actively working on web/hybrid projects (as extensions to desktop apps or standalone solutions)? I'm Working with webBased Apps + Harbour Console DeskToop Programas + FiveWin desktop programs all over same dbf treated with ads server and on azzure cloud this escenario are inside your questions ? best regards Wilson

Hola a todos,

Después de una semana perdida les explico.

En las pruebas que estoy haciendo para desarrollar aplicaciones web contra DBF y a su vez poder mantener las de escritorio, pretendía que la aplicación web fuera lo más estándar posible a una aplicación web, entre ello usar codificación Utf8 (de hecho yo no la escogí, lo hizo la AI) y que en las de escritorio no tuviera que añadir absolutamente nada.

El uso de UTF8 provocaba que la grabación en los DBF no fuera la adecuada, en teoría es mejor grabar con codificación Ansi u OEM (si, ya tengo unos años).
Bien, pues le pedía a AI que realizara la conversión en el momento de lectura y de grabación, así toda la web funciona con UTF8, y en la de escritorio no deberá añadir nada extra en su lógica.

El caso es que para convertir los literales, a la AI se le ocurre crear 2 funciones específicas y convierte carácter a carácter.

Después de aplicar las funciones siempre había caracteres que no se mostraban correctamente; probaba con literales de 'áàéèíìóòúùçÇñÑ'.
Le pedí primero convertir a Ansi, después a Win1252 Latín1, hasta OEM.

En las 3 (Ansi, Win1252, OEM) funciones que AI creó para convertir a UTF8 se le escapó un detalle.

En el código de conversión carácter/carácter, tenía líneas de este tipo:

cRes := StrTran(cRes, Chr(160), Chr(195)+Chr(161)) // á
cRes := StrTran(cRes, Chr(130), Chr(195)+Chr(169)) // é
cRes := StrTran(cRes, Chr(161), Chr(195)+Chr(173)) // í
...
cRes := StrTran(cRes, Chr(173), Chr(194)+Chr(161)) // ¡
cRes := StrTran(cRes, Chr(168), Chr(194)+Chr(191)) // ¿

Substituía caracteres ya substituidos, por ejemplo el 161 y 173; era imposible que mostrará 'à', 'í' correctamente.

Hoy dormiré más contento.

Please see the speedtest sample and source code : https://forums.fivetechsupport.com/viewtopic.php?p=283556#p283556

Hi,

https://forums.fivetechsupport.com/viewtopic.php?p=283562#p283562

C.

Otto buena tarde..

A grandes rasgos estos son mis proyectos

1. App local tipo ERP en fivewin + xharbour (dbfcdx, ads , sqlrdd, mariaDb) : Clientes locales mas orientados a sistemas POS
2. Sincronizador via internet : Triangulación de App local (clientes pc) en bases de datos mysql en internet ( con app local en fivewin + Eagle + MYSQL)
3. App web para toma de pedidos, facturación y otros, sobre la base de datos anterior y con el sincronizador que alimenta a los clientes locales ( frontEnd en SENCHA TOUCH y BackEnd en PHP)
4. Centralización del App Local (item 1), en VPS WINDOWS / WEB ( Servidor de terminal server : TSPLUS ), como solucion temporal a requemimientos de trabajar WEB
5. App web tipo ERP : nueva base de datos, reglas mas orientadas a clientes no POS, solucion empresarial con respaldo en framework como angular, jakarta ee, node js, servidores jboss / glassFish , etc...
   para funcionar en servidores cloud tipo amazon, google , azure ( el cliente exige respaldo )
6. Proyecto para migrar la app local a version web, sin perder nada de la lógica y la orientación de sistema POS ( clientes con recursos económicos y tecnológicos limitados),
   que puedan trabajar en la intranet o servidores web de bajo costo.
   Nota : aquí es donde entra temas como HIX / MOD_HARBOUR / frontEnd ligero o reutilizar componentes de angular ( la idea es que sean un proceso rápido,
   y que se pueda reutilizar gran parte de la lógica que ya esta orientada a trabajar con dbf o sql desconectados sobre objetos locales json - TarrayData ) ,
   al final es para que el cliente no sienta el cambio de ambiente

Saludos

JONSSON RUSSI

Carles wrote:

Hi,
https://forums.fivetechsupport.com/viewtopic.php?p=283562#p283562
C.

He tomado en cuenta lo que explica Carles pero en la aplicación aún se han detectado casos (para mi raros, producto de mi desconocimiento).
Le he preguntado a AI que me dijera por que algunos formularios se guardan bien y otros no.
(Recuerden, cuando leo de DBF convierto HB_StrToUTF8() y cuando voy a grabar HB_UTF8ToStr(); por tanto todo lo relacionado con www estará en UTF8)

Respuesta de AI:
(Sobre el uso de URLSearchParams)

Lo que hace este proceso es:

Recopila los datos: Toma todos los campos del formulario (FormData).
Serializa: Los transforma en una sola cadena de texto con el formato clave=valor separados por &.
Codifica (Encoding): Esta es la parte crítica. Convierte todos los caracteres especiales (espacios, acentos, ñ, etc.) a un formato seguro para URL (Percent-encoding).
Por defecto, URLSearchParams siempre utiliza UTF-8.
Ejemplo: La letra ñ se convierte en %C3%B1.
¿Por qué es relevante para tu problema?

Cuando envías estos datos con fetch, el servidor recibe una cadena codificada explícitamente en UTF-8. Si main.prg (a través de UPost) ya decodifica automáticamente esos caracteres a UTF-8, y luego aplicas otra vez Hb_UTF8ToStr (que intenta convertir de UTF-8 a ANSI), el proceso debería ser correcto siempre y cuando la cadena original sea realmente UTF-8 puro.

La diferencia con el formulario nativo (el de Nuevo Usuario) es que el navegador gestiona el envío de forma más transparente, negociando la codificación directamente con las cabeceras de la página. Aunque ambos suelen usar UTF-8 hoy en día, el uso de JavaScript intermedio (URLSearchParams) añade una capa estricta de codificación que podría estar interactuando mal con cómo Harbour decodifica inicialmente la petición POST antes de que tú llegues a tocar los datos.

De manera que le he dicho que "...cambiar el fetch por un envío nativo...", y ha resuelto mi problema.
Que es bueno o malo, no lo sé (sólo estoy probando y aprendiendo 'cosas') pero parece que llego al final del problema de la visualización/grabación de caracteres acentuados y consigo que los DBF trabajen bien con la app de escritorio.

Hello Jonsson,

This is my personal view, based on hands-on experience with a very similar setup.

Up to now, our software has mainly been deployed as a terminal server solution, including mobile handheld devices via RDP. This works reliably and is well established in daily operations. The newer components are now deliberately moving towards the web: each customer hosts their own web server, secured individually via cloudflared, without central dependencies.

From today’s perspective, I strongly recommend a clear separation of responsibilities. On the frontend side, I use Apache to handle web concerns such as routing, security, and web standards. The frontend itself is built with plain HTML, JavaScript, and CSS.

Behind that sits a dedicated backend layer responsible for data access and business logic. This backend can be implemented in different ways depending on the project: it may be a Harbour-based server, a custom microservice (as in my case), or even something like mod_harbour. The important part is not the tool, but the role it plays.

Once this separation is in place, the full web ecosystem becomes accessible, without forcing any specific frameworks. The backend remains focused on what it does best: stable business rules, controlled data access, and predictable performance. In short: web standards on the outside – proven backend logic on the inside.

In this model, existing DBF-based systems can continue to be used directly by the backend layer. Functionally, this behaves like a lightweight successor to classic database servers, but in a much leaner and easier-to-maintain form. No complex installations, no additional licensing models, and full control over data and logic.

From a community perspective, I believe it is important that we, as long-time developers, do not isolate ourselves from the broader web world. When working with web standards, requirements such as logging, backup strategies, workers, background jobs, and monitoring naturally emerge – and this is exactly where a strong backend architecture proves its value.

Finally, I think we need to actively challenge the myth that HTML and JavaScript in the frontend are cryptic or unmanageable. In practice, they are often simpler than many of the systems we built in the past. Complexity usually comes from the layers of frameworks placed on top. When working consciously with plain HTML, JavaScript, and CSS, the entry barrier is surprisingly low.

We are not beginners – we are experienced developers. We should allow ourselves to combine proven knowledge with modern standards and openly discuss what truly makes sense, and what does not.

Best regards, Otto

Carlos, form submit is a valid and robust solution for server-centric applications. It is not compatible with a client-side application that manages its own views and state. Replacing fetch with a plain HTML form submit only works if the application is server-rendered and a full page reload is acceptable. Both approaches are correct — but they are not interchangeable. Best regards, Otto

Otto wrote:

Carlos,
form submit is a valid and robust solution for server-centric applications.
It is not compatible with a client-side application that manages its own views and state.
Replacing fetch with a plain HTML form submit only works if the application is server-rendered and a full page reload is acceptable.
Both approaches are correct — but they are not interchangeable.
Best regards,
Otto

Thank you very much Otto.