FiveTech Support Forums

A practical insight about dialogs — learned the hard way

I think this is an important realization, especially for anyone coming from FiveWin / Clipper / desktop UI backgrounds and now building web UIs.

This is not web theory, not UX fashion, and not framework-dependent.
It is simply about understanding what kind of dialog you are dealing with — something we already did correctly for decades in FiveWin.

What caused confusion for us was not bad code, but mixing different dialog semantics under one mental model.

So instead of inventing new terms, it helps to name and classify dialog types the same way we implicitly always did.

Below is a clean, structured way to think about dialogs that immediately answers questions like:

• Should ESC close this?
• Should clicking outside close this?
• Do we need cleanup?
• Can data be lost?

1️⃣ Dialog types (classic desktop thinking)

We don’t need new terminology.
We just need to acknowledge three fundamentally different dialog categories.

🟢 Type A — Decision dialogs (Confirm / Yes–No)

FiveWin equivalent

IF MsgYesNo( "Really delete?" )
   // perform action
ENDIF

Characteristics

• No intermediate state
• No data is modified before the decision
• Cancel means: nothing happened
• The result is strictly binary

Control rules

• ESC = No
• Clicking outside = No
• Close button (X) = No
• “Cancel” button = No

➡️ All exits are equivalent
➡️ No cleanup required

This is the safest and simplest dialog type.

🔴 Type B — State dialogs (Edit dialogs / forms)

FiveWin equivalent

IF DlgEdit()
   // commit changes
ELSE
   // discard or validate
ENDIF

or explicitly:

ACTIVATE DIALOG oDlg ;
   ON ESCAPE NIL   // ESC must NOT auto-close

Characteristics

• An intermediate state exists
• Temporary values live inside the dialog
• User interaction is ongoing (input, drag, resize, etc.)
• Closing the dialog may cause data loss

Control rules

• ESC must be blocked or explicitly handled

• Clicking outside must NOT close

• Closing is allowed only via explicit buttons:

• Save

• Cancel

• Delete

➡️ Closing must be intentional
➡️ Cleanup is required

This is the most complex dialog type — and the one most often mishandled on the web.

🟡 Type C — Information dialogs (Info / Alert)

FiveWin equivalent

MsgInfo( "Information" )

Characteristics

• Purely informational
• No state
• No decision

Control rules

• ESC closes
• Clicking anywhere closes
• No cleanup
• No logic

This is just a message — nothing more.

2️⃣ Why this classification matters

Once dialogs are clearly categorized, a lot of recurring discussions simply disappear.

Questions like:

“Should ESC close this dialog?”
“Should clicking outside cancel?”
“Do we need extra flags here?”

All collapse into one simple counter-question:

What dialog type is this?

That’s it.

No framework debate.
No subjective UX opinions.
No special cases.

3️⃣ The real source of problems

Many issues arise when Type B dialogs are treated like Type A dialogs just because they “look like modals”.

On the web, everything is often called a “modal”, but not every modal is a confirm dialog.

A complex edit form with temporary state is not a confirm dialog — even if it visually resembles one.

FiveWin always made this distinction explicit.
On the web, it is often lost.

4️⃣ Why this approach is valuable

This simple classification:

• Ends endless discussions
• Prevents accidental data loss
• Eliminates random ESC handling
• Requires no framework
• Maps 1:1 to decades of desktop experience
• Is mechanically enforceable

It is not new.
It is simply remembering what already worked.

5️⃣ Internal cheat sheet

Final thought

This insight helped us stop fighting symptoms and start fixing the real issue:
mixing dialog semantics.

Once dialogs are classified correctly, the implementation becomes obvious — regardless of whether you are using FiveWin, JavaScript, or anything else.

Sometimes progress is not about learning something new, but about recognizing what you already knew — and trusting it again.