FiveTech Support Forums

I have seen a significant increase on this forum, and received emails, of responses to questions, generated by AI. I would suggest that may be creating more problems than solutions.

I am converting a major app from Modal to MDI. I do review samples, but they in no way provide a clear explanation of how MDI works, and more specifically, how FiveWin handles various setups/commands, and what it expects in them.

I started with ChatGPT and asked very detailed questions. The answers I received seemed to be nice until I tried using them. I would give it code, and it would tell me how to modify it for MDI ... but often it was wrong. As soon as I tested it's response, and it failed, it gave me some name for the problem and corrected its example.

It was suggested I use Gemini instead. It was a bit better, but failed frequently to provide a working solution. It, too, always had some name for the type of error and suggested a different approach, putting all the blame on behaviors in FiveWin.

Of greater concern is that it did not keep the total code in place, but kept suggesting new changes to sections. That might be ok, but it continuously switched variable names with each revision, so I would always have to go back and figure out what they referenced. For example, oDlgInv ( named for a specific module to differentiate from others ), might be used in one response, and the next time it might be oDIn, or just oDlg. This was a consistent behavior. Also, it would take an object in a class ( ::oDlg ) and then create a LOCAL oDlg. This isn't the best practice, but the problem arises because it would consistently switch back and forth incorrectly. For example, one time it might have ::oDlg:hide(), then in the revision it might be oDlg:hide() and when that didn't work it might be back to ::oDlg:hide(). This often happened when it decided to re-write a whole section of code.

MY POINT: AI may be helpful, but with Five Win and Harbour, and especially changes made in more recent years, it is far from accurate. As individual developers, we can see what is going on as we interact with it, but when someone asks a question here on this forum, before we respond with any AI solution, we should always test that ourselves. Otherwise, we may be providing misleading guidance, and as a result, create a lot of frustration for those seeking help.

Before I ask any question, I've used all my other resources, including AI, the samples, our very limited ( and very old ) documentation, and even searched the topic on this forum. So if I ask a question, the answers that will help me will be the responses from people who understand the question, and have an actual solution they have used in their own programs, and they KNOW it works.

Thanks for considering this. As I near my 80th birthday this summer, I still love being creative and programming. My clients also appreciate what I provide. However, as we age, our brain has to work a whole lot harder to remember, and think through processes. It is good to do this, and keeps us more alert, but new skills can be challenging.

Tim

I asked Claude how good it was, and it noted "The training data is thin. FiveWin isn't widely documented on Stack Overflow, GitHub, or mainstream sites. Most Knowledge lives in forum threads, private source code, and the FiveWin samples folder. AI models ( including me) end up pattern-matching from xBase generics or hallucinating plausible looking but wrong method names and parameters.

MDI programming is a particularly bad case because: It's a nice pattern even in Windows development generally, FiveWin's MDI implementation has specific quirks around Window/TMDIFrame/TMDIClient relationships, Threading and window management edge cases are poorly documented publicly, and Version differences matter a lot and aren't well captured in training data.

In other words, AI assistance is based on older code ( June 2024 and before ), and really doesn't understand enough of the language to give actual answers. Instead, it guesses ( or as it put it, it hallucinates ).

Dear Tim,

The right way to use AI for FWH + Harbour coding is to provide AI many coding examples.

IMO, the best way currently to do this is:

1. Install google antigravity
2. Open antigravity and select the folder: FWH\samples
3. Ask antigravity for what you need
4. antigravity will review all FWH\samples and will generate proper FWH + Harbour code

Dear Tim,

first of all, thank you for sharing your thoughtful experience with AI and FiveWin — I very much appreciate your careful and responsible approach.

May I ask out of genuine curiosity: what motivates you to move your application from Modal to MDI at this stage? In much of the broader software world, many frameworks and applications have actually been moving from MDI toward SDI or tab-based interfaces.

Are there specific workflow advantages in your application that make MDI the better fit for your users?

I would be very interested to understand your reasoning.

Kind regards, Otto

Hi all,
since the first time I used fiveWin (around 1995 or so) I have always used the MDI structure, this in my opinion gives notable advantages in the user experience, just a few examples:

• it allows the simultaneous opening of multiple browsers on different tables/windows, align the windows so as to make them visible at the same time and jump from one table to another;
• create parent-child-grandchild... structures with the windows and obtain effects such as scrolling on the parent table and all the child tables/windows are synchronized with each other, then stop scrolling and edit any of the tables without closing anything
• you may switch back to the browse while the editing window or a report preview or anything else is open;
• you can create and compare more than one report preview (from the same browse or not) without having to print them
• you can open more than one insert/editing window (on different tables) at the same time
  ... and so on, keeping all the windows visible and moveable at the same time, without having to manage boring dialogs that do not allow you to do anything else as long as they are open.

This is obviously not the best solution in absolute terms but it is the best for me and for the type of applications I develop.
Surely everyone will have their own good reasons for choosing one mode or the other according to their own style, but if necessary I can easily insert modal dialogs into my applications.
best regards,
Roberto

I to have always used MDI .. just a quick sample

DEFINE ICON oICO RESOURCE "ACUSTOMER"
DEFINE BITMAP oBMAP FILENAME (cDEFA+"\LOGO.BMP")    of oWind        // logo
DEFINE BITMAP oBMP  FILENAME (cDEFA+"\DAYCARE.BMP") of oWind

DEFINE WINDOW oWind                                          ;
   FROM 0,2 to 28,78                                         ;
   TITLE "Daycare Information Systems"                       ;
   MENU _BuildMenu( cDEFA,dEXE,cRDD,nSCR1,nSCR2 )            ;     

   ICON oICO                                                 ;
   MDI

   DEFINE BUTTONBAR oBar OF oWind SIZE 80,64 2010    // 80,58   80,64
  

   oBar:bClrGrad = { || { { 0.10,15724527,7303023 }, ;       // grey
       { 0.10,7303023,15724527 } } }

   DEFINE BUTTON oButt1 of oBar ACTION ( _ParnBrow( oWind )) ;
          RESOURCE "Employee" PROMPT "Parent-Child"+CRLF+"Fees-Receipts"
   oButt1:cToolTip := { " " + CRLF + "Parent Child Information","Fee Info Charges and Receipts", 1, CLR_BLACK, 14089979  }

   DEFINE BUTTON oButt3 of oBar ACTION ( _Rptmenu( oWind )   ) ;
          RESOURCE "report"     PROMPT "Reports"
   oButt3:cToolTip := { " " + CRLF + "Run Reports and Answer Questions", "Report Information", 1, CLR_BLACK, 14089979  }

   DEFINE BUTTON oButt4 of oBar ACTION (nil ) 

   DEFINE BUTTON oButt5 of oBar ACTION ( nil )  // hide this

   DEFINE BUTTON oButt6 of oBar ACTION ( _UTILmenu( oWIND ));
          RESOURCE "controlpanel" PROMPT "Control Panel"
   oButt6:cToolTip := { " " + CRLF + "System Information", "User Defined Tables", 1, CLR_BLACK, 14089979  }

   DEFINE BUTTON oButt7 of oBar ACTION (_WebHelp( dExe )) ;
          RESOURCE "palmetto" PROMPT "Created in South Carolina"
   oButt7:cToolTip := { " " + CRLF + "System Information", "Help and About", 1, CLR_BLACK, 14089979  }

   DEFINE BUTTON oButt8 of oBar ACTION (SHELLEXECUTE(nil,"open", "calc.exe",0,0,1)) ;
          RESOURCE "calculator" PROMPT "Calculator"
   oButt8:cToolTip := { " " + CRLF + "Bring Up the Calculator", "Calculator", 1, CLR_BLACK, 14089979  }

   DEFINE BUTTON oButt9 of oBar ACTION oWind:End();
          RESOURCE "exit" PROMPT "Quit"
   oButt9:cToolTip := { " " + CRLF + "Close this Program", "Quit", 1, CLR_BLACK, 14089979  }


   SET MESSAGE OF oWind        ;
       to xMessage CLOCK 2010

ACTIVATE WINDOW oWind                                         ;
   MAXIMIZED ;
   ON INIT  ( IF( nSCR1 < 1024, _ResMessage(nSCR1, nSCR2), ),_ChkOwner( oWind,cFirst)); // 560,230
   ON PAINT ( IF( xTEXT = "/NL", ,PalBmpDraw( hDC, 0,0, oBmp:hBitmap,  oBmp:hPalette, nSCR1, nSCR2 )),;
                    PalBmpDraw( hDC, _UpDown(), _RightLeft(), oBMAP:hBitmap, oBMAP:hPalette,305,191 ));
   VALID ( IIF( !lExitPgm, _ExitPgm( .T.,@lExitPgm ) , .F. ))

RETURN( NIL )

Otto wrote:

May I ask out of genuine curiosity: what motivates you to move your application from Modal to MDI at this stage? In much of the broader software world, many frameworks and applications have actually been moving from MDI toward SDI or tab-based interfaces.

Otto,

Son modas.
Cuando empecé programaba con DBaseIII+
Me dijeron "tu no progamas, esto no es un programa, no está compilado".
Pasaron los años, llegó internet a nuestras mesas y pude "leer" código Html; y recordé/pensé, "esto no es programar, no es un programa, no está compilado".
No te preocupes Otto, volverán.

Dear all,

after reading Tim’s experience and Antonio’s response, I believe this discussion highlights something important.

AI is not the real problem.

The real issue is structure.

FiveWin and Harbour contain decades of knowledge — but it is scattered: in forum posts in private codebases in sample folders in memory

AI struggles because the ecosystem is not centrally structured and versioned in a way that modern tools can consume.

And here comes my main point:

We must deliberately free Antonio from coordination work.

His time is far too valuable to be spent collecting fixes, reviewing forum snippets, and organizing patches.

He should focus on: architecture innovation modernization long-term direction

If we want AI assistance to improve, and if we want FiveWin to evolve, we need a coordination layer between the forum and Antonio.

A small “Sourcekeeper” role could:

collect and validate fixes prepare structured summaries maintain a verified patch archive document accepted and rejected changes

This is not about replacing anyone. It is about protecting the most valuable resource we have: focus.

AI will improve naturally when:

examples are structured patches are versioned changes are documented behavior differences between releases are clearly recorded

Right now, we rely on memory. We need process.

This discussion is not limited to FiveWin.

For Harbour-only users, structured coordination may be even more important.

We have seen fragmentation in the past — xHarbour and Harbour evolved separately for years. Over time, convergence becomes necessary again.

Without active source coordination, ecosystems drift apart.

What we need is not another fork. What we need is stewardship.

In simple terms:

We need someone who takes care of the source. Someone who watches consistency. Someone who tracks changes. Someone who keeps the codebase healthy and organized.

Not to control it — but to maintain it.

Source does not maintain itself.

If we agree that coordination work is necessary, then one conclusion follows naturally:

As a professional user group, we should consider how to support such coordination in a sustainable way.

Many of us build businesses on FiveWin and Harbour. We depend on stability. We depend on long-term evolution.

It is therefore reasonable to think about how the community can strengthen its own infrastructure.

This is not about obligation. It is about responsibility and long-term thinking.

And part of that responsibility, naturally, includes being willing to invest financially in the stability and future of the framework we depend on — through regular, predictable monthly contributions from all of us who benefit from it.

Sustainable coordination requires sustainable support.

Kind regards, Otto

Dear Otto,

FWH is kept in a Github private repository where all the patches, enhancements, new features, etc. are perfectly stored in proper order, with descriptions, examples, etc.

Currently we are using AI more and more to provide tech support to these forums using DeepWiki and Gemini. Up to now both have proven to be able to solve real issues.

We are also using Antigravity to solve tech issues and bugs fixing. This past weekend Antigravity completed UTF8 and BIG5 Chinese support for FWH. This is really outstading.

AI is providing us tech help as if it were a full dedicated developer. Its productivity is really impressive.

This shift is not just saving us time; it's allowing us to tackle complex features that were previously backlogged. I truly believe we are entering a new era for FWH development where the synergy between our core logic and these AI tools will benefit all our users.

What are your thoughts on this direction? I'd love to hear your take on how we are evolving.

Otto,

My focus is always on my clients, and over the years, to protect them I used MODAL programming. Now they are evolving in their willingness to follow proper procedures, and they can benefit by being able to keep open multiple parts of the application, especially since many now use dual monitors. On one they will display the full workorder processing while on the other they would like to do things like inventory management and accounting, switching back and forth between the two while not having to exit their "work in progress".

Antonio,

I have been working interactively with Gemini, and that has allowed me to learn because it actually instructs me on the "why" for whatever it suggests.

I did as you suggested and loaded Antigravity. I provided it the FWH samples AND access to my complete source code directory for my program, plus I loaded the Method I was working on ( and it decided to pull the full class ). The results were a disaster. It kept making changes, at one point taking away the MDI coding I was wanting to implement. I let it do it's thing and it went downhill even though it had everything it needed. In fact, it had access to the .rc file, told me it couldn't find a couple of resources, and they were clearly present. I realize I will have to study it more, and work with it, but it sure wasn't successful with what I'm trying to do.

So I went back to Gemini, and I told it what happened and asked why. ( Gemini is Google, Antigravity is Google ... surely they know each other ). This is the response I got:

t sounds like "Antigravity" (likely an AI tool or automated assistant trained on FWH samples) tried to apply "standard" FiveWin samples to your complex, data-driven Class. The problem is that samples are usually single-file procedures, while your code is a sophisticated MDI Class.

So, I went back to my last revisions with Gemini, and looked more closely at my code. Based on the concepts I was taught by Gemini, I spotted and resolved the remaining errors. HOWEVER, neither AI tool was on track to find the problem. Both were suggesting solutions that just didn't work.

This has always been one of my concerns with the samples. They are small bits of logic but we don't see larger examples of coding that show the complete handling of an application. Also, many can be distracting because they are quite old and the functions they call may well have changed. In addition to samples, I suspect Antigravity would also need access to source, but even then, how well can it handle complex, fully integrated, application coding with tens of thousands of lines of code, and complex business logic?

Dear Tim,

You’ve hit the nail on the head. Your experience is a perfect "reality check" for where AI stands today.

While AI is an incredible assistant, it is not a silver bullet that can magically solve complex architectural problems yet. We have to understand that we are in a transition phase where these tools are constantly evolving.

It’s a collaborator, not a replacement: Sometimes it provides brilliant insights, and other times it gets lost, "hallucinates," or loses track of the global context—especially in large, integrated systems like an MDI Class.

The "Sample" Trap: As you noted, AI often tries to apply "snippet logic" to "enterprise reality." It lacks the bird's-eye view of your business logic and the specific nuances of legacy vs. modern functions.

Part of the process: These errors and frustrations are part of the learning curve. The fact that you were able to spot the errors using the concepts Gemini taught you proves the ideal workflow: AI for instruction, but Human Intelligence for the final execution.

It will keep getting better, but for now, your expertise is what keeps the project on the rails.

That was the point I was making in my original post. AI is a tool, and it can be helpful, but we must be very cautious in accepting all that it provides.

I believe in time this will change. I encounter people every day that thinks it is 100% accurate all the time, even though it warns us it can make mistakes.

Right now I'm finding Gemini very instructional because any time it suggests a new path, it actually provides a clear explanation of what might be causing problems. It is by closely examining code that we may spot the issues even when AI cannot.

When I started converting my databases and functions to classes ( data objects ), once I got an understanding of how it all actually worked, and how to code with the errors, it became easy to then convert all of my code quickly. I expect the same to be the case with this MDI conversion.

Tim

Dear Tim, I’ve always worked by breaking complexity into manageable parts—whether it’s code, documents, or even physical books. During my studies, I’d literally cut 1,000-page textbooks into individual chapters: table of contents + Chapter 1, Chapter 2, etc. Suddenly, I had thin, focused “books” I could study in parallel. Harbourino applies this same logic to code—but it started long before code, with text and structure. The name “Harbourino” comes from this idea: “Harbour” (the language) + “-ino” (small, like “libretto” or “espresso”). It’s about making things small, focused, and modular—just like cutting a thick book into thin, usable chapters. And it works for anything:

Text (originally, for structuring documents). FiveWin/Harbour code (splitting monolithic .prg files into logical units). HTML/PHP (turning sprawling forms into modular “chapters”). Even AI prompts (breaking tasks into clear, testable steps).

How Harbourino “Works Like a Book”

Physical Separation Just as I’d cut a book into chapters, Harbourino splits code into single-page files (NASA’s rule: If it doesn’t fit on one page, it’s too complex). Example: KERN.har, ALLGEMEIN.har, PERSOENLICH.har → Each is a “chapter” you can debug, print, or hand to someone else.

Logical Flow Like a book’s table of contents, Harbourino uses clear includes and placeholders:

$- include KERN.har -$ $- include PERSOENLICH.har -$

The order matters, but each part stands alone.

Parallel Work With books, I could study Chapter 3 while someone else read Chapter 7. With Harbourino, you can develop MITREISENDE.har while I work on STATISTIK.har—no conflicts.

Standardized “Syntax” Books use headings, footnotes, and styles. Harbourino uses:

$-> FIELD id=NAME; label=Name; type=text; -&

→ One definition, reusable everywhere (like a glossary in a textbook).

No Monoliths A 1,000-page book is useless if you can’t open it. A 1,000-line .prg file is the same. Harbourino enforces: One function, one page, one purpose.

Why This Matters for FiveWin/Harbour (and Beyond)

FiveWin/Harbour: Instead of one giant .prg, you get small, testable units that compile together. Web Forms: 100 fields become 100 lines of structured definitions, not 1,000 lines of spaghetti HTML. Legacy Code: Wrap old procedures in Harbourino “chapters” and modernize incrementally. Teamwork: Hand someone MARKETING.har without exposing the whole codebase.

The core idea? If it’s too big to hold in your hand (or your head), make it smaller. Harbourino is just a tool to do that—whether for code, text, or even process documentation. Best regards, Otto

Otto,

When I first started with dBase II, in 1982, the style of the time was to think in modules. Thus, the concept of Functions ... create a small process, and use that to connect with other called small processes to obtain the solutions you want.

In the DOS days, many of us in the dBase, and then Clipper, communities focused on that extensively. People independently developed ( and sold ) functions all designed for specific purposes. People like Tom Rettig, Greg Lief, John Spence, and so many others, developed the small modules that could be called to handle tasks, and used rather universally.

My "program" grew out of that ... it was always modular. Even when Windows came along, it transformed in that way. Later, with the guidance of James Bott, I refined, and condensed, it even further into classes, and OOPS structure.

I think this is a lot like what you are presenting here. Now with MDI, I'm taking groups of those modules and giving them even more independence and flexibility.

TIm

Buena noche..

Link de interes para desarrolladores ..

https://www.mentorestech.com/resource-blog-content/openspec-como-implementar-spec-driven-development-con-ia-sin-perder-control-ni-calidad

https://gigazine.net/gsc_news/en/20251026-openspec/

JONSSON RUSSI