FiveTech Support Forums

Dear friends,

I'm starting a separate topic because I believe this – the migration path of old desktop applications – is the biggest challenge many of us are facing here.

You often have no idea how much work it really involves until you're in the middle of it.

Especially we, who have invested in grown systems over the years, have often become perfectionists through our experience – always looking for the best, most elegant, most stable solution.

But that's not always possible here. We don't have the time to rebuild everything perfectly.

And to be honest: the options aren't that numerous. I only know two, maybe three serious paths – and none of them comes without compromise.

What helps us is open exchange. Because this isn't a project you just "do" – it's something you really have to carry.

And it takes more than just technology: it takes a clear definition of goals, so you don't get stuck in the details along the way. Where do I want to go – functionally, organizationally, strategically?

The technical implementation is usually solvable – but making the right decisions at the right moment, that's the real art.

And I think the theoretical discussion about paths, concepts, and architectures also deserves more space.

Maybe we can even develop shared building blocks – like a solid customer management module that many could build upon.

At their core, almost all administrative programs have a similar structure:

Browser + CRUD functionality.

If you approach this cleanly once, you can reuse a lot – and ease the burden on each other.

What makes things even more difficult:

We are a community that has formed around a specific language and platform. For a long time, this was our shared home – and in many ways, still is.

But times have changed. Our programs now have to move to the web, whether we like it or not. And that's exactly why we must be allowed to talk about migration – especially here, where the most experience is gathered.

Sometimes it feels a bit like someone shops at a megastore or supermarket, then switches the bag for a neutral one – and buys a little something at the local store to keep up appearances.

But that helps no one.

It sometimes feels like someone’s keeping a leftover warm on the stove, even though the main meal is being served somewhere else.

We have a powerful tool in FiveWin and Harbour – one that can be adapted to almost any situation, if we continue to develop it together, contribute, and test.

But that only works if we don’t pretend everything is still the way it used to be.

Openness, collaboration, and the courage to change – that’s the foundation.

Thanks again – I’m continuing to read along with interest.

Best regards,

Otto

As part of my migration efforts, I’ve started launching reports directly via HTML forms on the web – without traditional desktop dialogs. I call this approach Web JSON Bypassing. The report parameters are passed as a .req file in JSON format and read by the existing desktop program using JSONDecode().

The assignment goes directly to the report objects – completely without a user interface. The advantage: the same logic runs on both desktop and mobile without having to write duplicate code. To speed up implementation, I use an AI-based prompt template that automatically generates both the HTML form and the JSON mapping. This brings real benefits, especially for frequently used reports in the field or on mobile devices – without having to overhaul the entire system.

Best regards,
Otto

Here you can see how the actions requested from the phone are executed on the server. It's actually amazing how quickly the desktop xReport.exe is opened, the query executed, and the program closed again. The JPG is then displayed on the phone, and the print job prints the previously generated PDF. Here shown as an example using Fineprint.