FiveTech Support Forums

Hi,

How can I copy the contents of a variable to the clipboard so I can paste it into another application?

Thanks!

FW_CopyToClipboard(cText)

betoncu wrote:

FW_CopyToClipboard(cText)

Hi,

Error: Unresolved external '_HB_FUN_FW_COPYTOCLIPBOARD' referenced from D:\SISTEMAS\SINDF\OBJ\PROG08.OBJ

Thank you!

I think you have a missing lib. see C:\FWH\samples\misc\whatsapp.prg'

// C:\FWH\SAMPLES\CLIPB.PRG

#include "fivewin.ch"

FUNCTION Main()

   cCopiar()

RETURN NIL

FUNCTION cCopiar()

   LOCAL oCop, oDlg, oSay, cCop := SPACE(50)

   DEFINE DIALOG oDlg

   DEFINE ClipBoard oCop OF oDlg

   oCop:clear()

   oCop:SetText( "WARTIAGA01" )

   @ 10, 10 say oSay PROMPT cCop OF oDlg SIZE 40, 15 COLOR METRO_ORANGE PIXEL ;
      TRANSPARENT ADJUST

   oSay:SetText( oCop ) // TCLIPBOARD

   ACTIVATE DIALOG oDlg ON INIT( oSay:SetText( "WARTIAGA02" ) )

RETURN( .T. )

// FIN / END

Regards, saludos.

https://www.fivetechsupport.com/forums/viewtopic.php?t=43700

Regards, saludos.

karinha wrote:

Code: Select all Collapse

// C:\FWH\SAMPLES\CLIPB.PRG

#include "fivewin.ch"

FUNCTION Main()

   cCopiar()

RETURN NIL

FUNCTION cCopiar()

   LOCAL oCop, oDlg, oSay, cCop := SPACE(50)

   DEFINE DIALOG oDlg

   DEFINE ClipBoard oCop OF oDlg

   oCop:clear()

   oCop:SetText( "WARTIAGA01" )

   @ 10, 10 say oSay PROMPT cCop OF oDlg SIZE 40, 15 COLOR METRO_ORANGE PIXEL ;
      TRANSPARENT ADJUST

   oSay:SetText( oCop ) // TCLIPBOARD

   ACTIVATE DIALOG oDlg ON INIT( oSay:SetText( "WARTIAGA02" ) )

RETURN( .T. )

// FIN / END

Regards, saludos.

Thanks Karinha, but this only works for pasting within the same program; I need to paste it directly onto a website in my browser.

CTRL + V no sirve? Explique mejor porfa.

But since Harbour is open source, we cannot always rely on others to move things forward.
Quick hacks are often:
creative — they open unexpected paths.
exploratory — they reveal what’s possible.
energetic — they break stagnation.
playful — they spark joy and curiosity.
And that’s exactly what Harbour is missing right now: this playful, curious energy.
Most systems don’t die because of poor technology.
They die because of a lack of curiosity.
Pragmatism can ignite curiosity—but only if we act on it.
It starts with each of us.
Anyone can experiment, test an idea, and share it with the community.
And I’m convinced: The experienced Harbour maintainers will review it carefully.
If it makes sense and isn’t already implemented, they’ll integrate it.

#include "fivewin.ch"

function Main()
    SetClipboardText( "Text aus Harbour ohne hbwin.ch" )
    ? "Jetzt STRG+V im Browser testen"
 return nil
 
 
 #pragma BEGINDUMP
 
 #include <windows.h>
 #include "hbapi.h"
 
 HB_FUNC( SETCLIPBOARDTEXT )
 {
    const char * szText;
    HGLOBAL hMem;
    LPVOID pMem;
 
szText = hb_parc( 1 );
 
if( szText && OpenClipboard( NULL ) )
{
   EmptyClipboard();
 
   hMem = GlobalAlloc( GMEM_MOVEABLE, strlen( szText ) + 1 );
 
   if( hMem )
   {
      pMem = GlobalLock( hMem );
 
      memcpy( pMem, szText, strlen( szText ) + 1 );
 
      GlobalUnlock( hMem );
 
      SetClipboardData( CF_TEXT, hMem );
   }
 
   CloseClipboard();
}
 }
 
 #pragma ENDDUMP

Next step:

✅ STRICT PRODUCTION AUDIT PROMPT (Harbour + BEGINDUMP)

You are performing a forensic-grade production audit of Harbour + #pragma BEGINDUMP C code.

Assume:

The code runs in a long-lived Windows production process.

It may execute millions of times.

Memory pressure, API failures, and concurrency must be expected.

Zero tolerance for leaks or undefined behavior.

Do not summarize.
Perform a systematic low-level inspection.

1. Harbour VM & GC Analysis

Analyze:

Correctness of hb_xgrab, hb_xfree

Correct use of hb_retclen_buffer

Ownership transfer semantics

VM stack cleanliness after hb_vmDo

STATIC variable lifetime growth

Hidden references in hashes/arrays

Risk of unbounded structure accumulation

Interaction between C allocations and Harbour GC

Explicitly state:

Whether Harbour or C owns each allocation

Whether GC is guaranteed to collect it

If not: why not

1. C Memory Safety

Check ALL paths:

malloc/free symmetry

Early return leaks

Double-free scenarios

Heap leaks in error branches

Failure-safe cleanup patterns

File handles close coverage

Socket handle cleanup

WinAPI handle lifecycle

NULL checks before free

Cleanup on partial initialization failure

Enumerate every exit path and verify cleanup coverage.

1. Buffer & Integer Safety

Audit:

Fixed-size buffers

snprintf return handling

recv/send bounds

Possible truncation misuse

Off-by-one errors

Integer overflow in length calculations

Signed/unsigned conversion risks

Multiplication overflow in allocations

Implicit casting risks

Simulate extremely large input (multi-MB strings).

1. Ownership & Lifetime

For every pointer:

Who allocates?

Who frees?

When?

Can it outlive scope?

Is memory handed to Harbour still referenced?

Is memory freed while Harbour might still hold a pointer?

Is WinAPI expected to own the memory?

Is GlobalAlloc memory correctly released or transferred?

Explicitly model lifetime graph.

1. Concurrency & Guarding

Assume:

Re-entrancy

Multiple clipboard calls

Potential preemption

Windows API failures

Check:

OpenClipboard blocking behavior

CloseClipboard guarantee

Deadlock potential

Early-return clipboard lock risk

Resource starvation risk

Thread-safety of STATIC storage

Race conditions

1. Long-Running Stability Simulation

Simulate:

1,000,000 iterations

Sporadic API failures

Partial initialization failure loops

Answer:

Linear memory growth risk?

Fragmentation risk?

Handle exhaustion?

TIME_WAIT socket accumulation?

Hidden string growth?

Heap churn amplification?

Quantify risk patterns.

1. Windows Resource Audit

Check:

GDI leaks

HANDLE leaks

Clipboard global memory lifecycle

GlobalLock/Unlock symmetry

SetClipboardData ownership semantics

Failure cleanup if SetClipboardData fails

Risk of resource starvation

Proper Release on failure

1. Extreme Failure Cases

Model behavior under:

Extremely large input

Malformed input

GlobalLock failure

SetClipboardData failure

OpenClipboard failure

VM exception mid-operation

Interrupted process

Partial ownership transfer

Heap exhaustion

Explain EXACT consequences.

1. Required Output Format

At the end provide:

Memory Risk Rating (0–10)

Stability Risk Rating (0–10)

Concurrency Risk Rating (0–10)

Windows Resource Risk Rating (0–10)

List of concrete fix patches

List of rare edge-case undefined behaviors

Final verdict:

Production Ready

Needs Hardening

Unsafe for Long-Lived Process

Be extremely critical.
Assume production environment.

Here is a concise, professional forum-ready version in English:

After a thorough low-level review (including GC, memory ownership, WinAPI handling, and long-running stability), the remaining step is no longer technical analysis but engineering judgment.

AI can help identify potential risks, leaks, ownership ambiguities, and worst-case scenarios. However, it cannot decide whether the remaining risk level is acceptable for production.

At this point, a human expert must evaluate:

• Is ownership clearly defined and consistent?
• Are all cleanup paths verified?
• Is failure behavior predictable and acceptable?
• Can the team maintain and debug this code long-term?
• Is the residual risk understood and consciously accepted?

In long-lived processes (e.g., Harbour + #pragma BEGINDUMP + WinAPI integration), even small leaks or handle mismanagement can become critical over time.

So the final decision is not:
“Does it compile?”
but:
“Do we fully understand and accept the operational risk?”

If yes — build it in.
If not — harden it further.

That’s the real boundary between code review and engineering responsibility.