Clipboard और drag-and-drop कैसे काम करते हैं — business ऐप में OLE data transfer सही संभालना

“Excel से copy की table paste करने पर formatting बिखर जाती है। हम चाहते हैं कि table के रूप में paste हो।” “हमारे ऐप में copy की content Word में paste करने पर कुछ अजीब हो जाती है।” “हम फ़ाइलें drag-and-drop से लेना चाहते हैं।” — Business-ऐप changes पर consulting बातचीत में, copy-and-paste और drag-and-drop (D&D) के आसपास के अनुरोध नियमित हैं।

ठीक इसलिए कि ये “वे सुविधाएँ हैं जिन्हें सब स्वाभाविक मानते हैं”, वे वास्तव में कैसे काम करती हैं हैरानी से कम ज्ञात है। यदि clipboard को “वह डिब्बा जिसमें एक टुकड़ा data रखते हैं” सोचें, तो नहीं समझा सकते कि वही copy paste की जगह के अनुसार अलग results क्यों देती है, या source ऐप बंद करने के बाद paste क्यों रुक जाता है। वास्तविक clipboard वह mechanism है जो एक ही content कई formats में एक साथ रखता है, और paste करने वाले पक्ष को वह format चुनने देता है जिसे वह समझता है।

और drag-and-drop, मूल में, OLE data transfer है जो ठीक वही data representation जो clipboard का है (IDataObject), COM interface से सौंपता है। यानी, copy-and-paste और D&D भाई-बहन हैं: एक सही समझें तो दूसरा वहीं है।

यह लेख छोटे और मझोले उद्यमों के IT staff और Windows ऐप developers के लिए है। यह एक चित्र में बाँधता है कि clipboard formats कैसे काम करते हैं, paste करने वाले पक्ष और copy पक्ष की practices, clipboard देखने का सही तरीका, clipboard history, cloud sync, और RDP की admin policies, तथा OLE drag-and-drop की structure और जाल।

1. निष्कर्ष पहले

• Clipboard एक ही desktop (window station) के ऐप द्वारा साझा एकल क्षेत्र है, और वहाँ जो बैठता है वह “एक टुकड़ा data” नहीं बल्कि एक ही content कई formats में एक साथ है। RDP जैसा अलग session मूलतः अलग clipboard रखता है; redirection सुविधा दोनों को जोड़ती है। क्योंकि destination वह format चुनता है जिसे समझता है, वही copy paste की जगह के अनुसार अलग results देती है।¹²
• Text के लिए CF_UNICODETEXT इस्तेमाल करें। CF_TEXT ANSI और code-page dependent है, और Japanese सिस्टम पर mojibake का प्रजनन स्थल है। सिस्टम दोनों के बीच implicit conversion करता है, पर canonical पक्ष Unicode है।³
• फ़ाइलें CF_HDROP (paths की double-NUL-terminated array) के रूप में चलती हैं, और formatted text registered format “HTML Format” इस्तेमाल करता है। HTML Format असामान्य structure रखता है: byte offset के header वाला UTF-8 text।⁴⁵
• “Source ऐप बंद किया और paste बंद हो गया” का वास्तविक कारण delayed rendering है। यह mechanism payload नहीं, केवल “माँगे जाने पर बनाने” का वादा रखता है; यदि exit पर materialize करना छोड़ें (WM_RENDERALLFORMATS का उत्तर, या OLE के लिए OleFlushClipboard), paste रुक जाता है।²⁶
• Paste किए data को बाहर से untrusted input मानें। Microsoft स्वयं साफ़ कहता है कि “clipboard data विश्वसनीय नहीं। उसे सावधानी से parse करें”।⁷
• Clipboard देखने के लिए, AddClipboardFormatListener + WM_CLIPBOARDUPDATE एकमात्र विकल्प है। Polling इस्तेमाल न करें, और पुराना SetClipboardViewer (viewer chain) इस्तेमाल न करें। Secrets को history और sync से बाहर रखने वाले registered formats (ExcludeClipboardContentFromMonitorProcessing और साथी) भी दिए गए हैं।⁸¹
• Clipboard history (Win+V) और cloud sync IT-management चिंता हैं। उन्हें GPO / Intune (Policy CSP) से AllowClipboardHistory और AllowCrossDeviceClipboard से control कर सकते हैं, और RDP clipboard redirection की अपनी dedicated policy है।⁹¹⁰¹¹
• Drag-and-drop COM है। Clipboard जैसा वही IDataObject IDropSource (drag source) और IDropTarget (drop target) के बीच DoDragDrop loop से सौंपा जाता है। RegisterDragDrop को OleInitialize (STA) से initialization चाहिए।¹²¹³
• साधारण-privilege File Explorer से elevated ऐप पर drop नहीं कर सकते। UIPI (integrity level से message block) कारण है, और यह बाधा design समय जाननी चाहिए।¹⁴

नीचे इसे clipboard की बुनियाद से चलते हैं।

2. Clipboard वास्तव में क्या है — “एक टुकड़ा data” नहीं, “एक ही content कई formats में”

Clipboard एक सामान्य data-share mechanism है जिसे एक ही desktop साझा करने वाला हर ऐप पहुँच सकता है (अधिक सटीक, यह per window station है: अलग user session या RDP session प्रत्येक अपना clipboard रखते हैं। RDP पर copy-and-paste काम करता है क्योंकि redirection सुविधा दोनों को जोड़ती है — chapter 7)। पहला सिद्धांत यह है कि यह user-driven है: official design रुख है कि user की पीठ पीछे data न रखें न निकालें।¹

महत्वपूर्ण बिंदु यह है कि copy “एक टुकड़ा data” नहीं रखती। Copy करने वाली window clipboard खाली करती है और फिर कई formats पंक्ति में रखती है, एक ही content को अधिक सक्षम format से कम सक्षम तक व्यक्त करते हुए।² उदाहरण के लिए, spreadsheet में table copy करने पर, अवधारणात्मक रूप से clipboard पर एक साथ कुछ ऐसा होता है।

Paste करने वाला पक्ष इस सूची से वह format चुनता है जिसे समझता है और उसे निकालता है। Word में paste करें तो formatted table मिलती है; Notepad में paste करें तो tab-separated text — क्योंकि दोनों ने अलग format चुने। “Result paste की जगह पर निर्भर करता है” bug नहीं; इस design का सामान्य नतीजा है।

flowchart TB
    accTitle: वही copy paste की जगह के अनुसार अलग results क्यों देती है
    accDescr: Copy पक्ष एक ही content clipboard पर कई formats में रखता है, और paste करने वाला पक्ष वह format चुनता है जिसे समझता है, इसलिए Word को formatted table मिलती है और Notepad को tab-separated text
    copy["Copy: spreadsheet"] --> cb["Clipboard（कई formats）"]
    cb --> rich["अधिक rich formats"]
    cb --> plain["अधिक plain formats"]
    rich --> f1["ऐप-private"]
    rich --> f2["HTML Format"]
    plain --> f3["CSV"]
    plain --> f4["CF_UNICODETEXT"]
    f2 -->|"Word"| word["Formatted table"]
    f4 -->|"Notepad"| notepad["Tab-separated text"]

चित्र 1: वही copy destination के चुने format के अनुसार अलग results देती है; “बिखर जाता है” अक्सर format चुनाव की समस्या है।

उलटा कहें, शुरुआती शिकायतें — “formatting बिखर जाती है”, “कुछ अजीब paste होता है” — लगभग सब एक पक्ष के format चुनने, या दूसरे पक्ष के उन्हें देने, की समस्या पर आती हैं। Chapter 4 paste करने वाला पक्ष कवर करता है; chapter 5 copy पक्ष।

3. Standard formats और registered formats — CF_UNICODETEXT, CF_HDROP, HTML Format

3.1. Standard formats — text के लिए Unicode पक्ष इस्तेमाल करें

जो formats OS पहले से define करता है उन्हें standard formats कहते हैं। Business ऐप में लगातार दिखने वाले निम्नलिखित हैं।³

CF_TEXT और CF_UNICODETEXT सिस्टम द्वारा एक-दूसरे में implicit convert होते हैं (synthesized formats)। Character-code conversion CF_LOCALE से जुड़े code page इस्तेमाल करता है।³ उस conversion पर भरोसा करना वे characters गिराता है जिन्हें ANSI व्यक्त नहीं कर सकता (उदाहरण के लिए केवल-Unicode symbols और combining characters), इसलिए नियम है ऐप जो पढ़े और लिखे उसे CF_UNICODETEXT (.NET में DataFormats.UnicodeText) पर एक करें।

flowchart TB
    accTitle: CF_UNICODETEXT और CF_TEXT के बीच implicit conversion
    accDescr: ऐप केवल CF_UNICODETEXT पढ़ता और लिखता है; सिस्टम CF_LOCALE code page से implicit conversion कर CF_TEXT synthesize करता है। जो characters ANSI व्यक्त न कर सके वे उस conversion में गिरते हैं
    apprw["ऐप पढ़ता और लिखता है"] --> uni["CF_UNICODETEXT"]
    uni <-->|"CF_LOCALE conversion"| ansi["CF_TEXT（ANSI）"]
    ansi -.-> loss["अव्यक्त characters गिरते हैं"]

चित्र 2: ऐप Unicode पक्ष पर एक करे; ANSI conversion सिस्टम का है, और वहाँ characters गिर सकते हैं।

3.2. CF_HDROP — फ़ाइलें “paths की list” के रूप में चलती हैं

CF_HDROP वह है जो File Explorer में फ़ाइलें copy करने, या फ़ाइलें drag-and-drop करने पर इस्तेमाल होता है। Payload फ़ाइलें स्वयं नहीं; वह memory block है जो एक “double-NUL-terminated” array बिछाता है: DROPFILES structure header के बाद, NUL characters से अलग full-path strings, और अंत में खाली string। Header का pFiles path list का start offset है, और fWide कहता है कि strings Unicode हैं या नहीं।⁴

[DROPFILES header: pFiles=start offset of the path list, fWide=1(Unicode)]
C:\data\a.txt(NUL)C:\data\b.txt(NUL)(NUL)

Native code में उन्हें DragQueryFile से एक-एक निकालते हैं; .NET में DataFormats.FileDrop से string[] के रूप में पाते हैं। यह तथ्य कि “जो चलता है केवल paths हैं, फ़ाइलें स्वयं नहीं” chapter 8 और 9 के D&D में फिर महत्व रखेगा।

flowchart TB
    accTitle: CF_HDROP का memory-block layout
    accDescr: Global memory के प्रारंभ पर DROPFILES structure बैठती है; pFiles path list का start offset है और fWide कहता है Unicode है या नहीं। फिर full paths NUL-separated आते हैं, और block खाली string（double NUL）से खत्म होता है। जो चलता है केवल paths हैं, फ़ाइलें नहीं
    hdr["DROPFILES（pFiles / fWide）"] --> p1["C:\\data\\a.txt + NUL"]
    p1 --> p2["C:\\data\\b.txt + NUL"]
    p2 --> tail["खाली string（double NUL）"]
    hdr -.-> note["केवल paths चलते हैं, फ़ाइलें नहीं"]

चित्र 3: CF_HDROP फ़ाइलें नहीं ढोता; paths की list ढोता है। Import से पहले path validation chapter 9।

3.3. Registered formats — RegisterClipboardFormat और “HTML Format”

जिस data को standard formats व्यक्त न कर सकें, ऐप नाम चुनकर अपना format register कर सकता है। RegisterClipboardFormat को नाम दें तो format ID मिलता है; अलग ऐप से उसी नाम से registration वही ID लौटाता है, इसलिए नाम पर सहमत होने पर ऐप के बीच data साझा कर सकते हैं।¹ अपने ऐप suite में structured data सौंपते समय ऐसा नाम इस्तेमाल करें जो न टकराए, जैसे KomuraSoft.Report.RowData।

प्रतिनिधि registered format “HTML Format” है, formatted text के लिए (RTF के साथ, दो प्रमुख rich-text formats में से एक)। Payload UTF-8 text है, पर असामान्य structure है: byte offset गिनाने वाला header आगे जुड़ा होता है।⁵

Version:0.9
StartHTML:<byte offset of the start of the whole HTML>
EndHTML:<byte offset of the end of the whole HTML>
StartFragment:<byte offset of the start of the fragment>
EndFragment:<byte offset of the end of the fragment>
<html><body>
<!--StartFragment--><b>bold</b> fragment text<!--EndFragment-->
</body></html>

हर offset data के प्रारंभ से byte position है, header स्वयं सहित; सामान्य practice है निश्चित चौड़ाई reserve करना (उदाहरण के लिए 10 अंक) और body बनाने के बाद मापे मान वापस लिखना। StartFragment/EndFragment “user ने वास्तव में चुना fragment” का प्रारंभ और अंत bytes में चिह्नित करते हैं (characters में नहीं)। Japanese सहित UTF-8 में, character count और byte count अलग हो जाती हैं, इसलिए यदि यह offset गणना गलत हो, दूसरे ऐप में paste प्रारंभ या अंत गिरा देता है। यदि HTML Format स्वयं बनाएँ, header को UTF-8 में encode करने के बाद मापी byte positions से भरना चाहिए।⁵

flowchart TB
    accTitle: HTML Format header offsets से कैसे संबंधित है
    accDescr: Header के StartHTML और EndHTML पूरे HTML की ओर इशारा करते हैं, और StartFragment तथा EndFragment user द्वारा चुने fragment की ओर, दोनों data के प्रारंभ से byte positions हैं। UTF-8 में character count और byte count अलग होती हैं, इसलिए header को encode के बाद मापी byte positions से भरें
    header["Header（byte offsets）"] --> html["पूरा HTML"]
    html --> frag["चुना fragment"]
    header -.-> byte["Offsets UTF-8 बाद bytes हैं"]

चित्र 4: HTML Format offsets characters नहीं bytes हैं; UTF-8 में encode के बाद मापें, वरना paste कट जाता है।

CSV (.NET में DataFormats.CommaSeparatedValue) tabular data के लिए भी सामान्य इस्तेमाल होता है। Excel के साथ interop के लिए, HTML Format (formatting सहित), CSV (केवल मान), और CF_UNICODETEXT (tab-separated) एक साथ देने का अर्थ है एक ही paste का destination नहीं चुनना पड़ता।

4. Paste करने वाले पक्ष की practices — format priority और validation

4.1. Rich format से नीचे देखें

Clipboard पर formats उस क्रम में पंक्तिबद्ध हैं जिस क्रम में copy पक्ष ने उन्हें रखा (यानी अधिक expressive से कम तक)। Paste करने वाले पक्ष की baseline है जिन formats को संभाल सकते हैं उनमें से सबसे अधिक जानकारी वाले से देखना। Win32 में या तो EnumClipboardFormats से गिनें और पहला पहचाना format इस्तेमाल करें, या अपनी priority list GetPriorityClipboardFormat को दें और उसे चुनने दें।²

.NET में शाखा कुछ ऐसी दिखती है।

// Pasting a table: look from rich to plain
var data = Clipboard.GetDataObject();
if (data is null) return;

// Advertising a format does not guarantee the payload is a string. Use this
// branch only when the type also checks out; otherwise fall through to the next candidate
if (data.GetDataPresent(DataFormats.Html)
    && data.GetData(DataFormats.Html) is string html)
{
    // Validate the HTML Format header, then import as a table
}
else if (data.GetDataPresent(DataFormats.CommaSeparatedValue))
{
    // Import as CSV
}
else if (data.GetDataPresent(DataFormats.UnicodeText))
{
    // Import as tab-separated text
}

यही शुरुआती शिकायत का उत्तर है, “Excel table paste बिखर जाता है”। केवल plain text पढ़ने वाला ऐप table structure कभी नहीं पाता। Format list कितनी नीचे तक स्वीकार करें यह paste करने वाले पक्ष का design decision है।

flowchart TB
    accTitle: Rich format से नीचे देखने वाली paste की शाखा
    accDescr: यदि HTML Format मौजूद हो और payload भी string हो, table के रूप में import करें; अन्यथा CSV आज़माएँ; यदि वह भी न हो, tab-separated text पर गिरें। यदि कोई candidate मौजूद न हो, अस्वीकार करें
    startsel["Paste शुरू"] --> h{"HTML Format + string?"}
    h -->|"हाँ"| useh["Header validate → table"]
    h -->|"नहीं"| c{"CSV मौजूद?"}
    c -->|"हाँ"| usec["CSV के रूप में import"]
    c -->|"नहीं"| t{"UnicodeText?"}
    t -->|"हाँ"| uset["Tab-separated text"]
    t -->|"नहीं"| giveup["अस्वीकार"]

चित्र 5: Paste करने वाला पक्ष rich से plain तक देखता है; केवल plain text पढ़ें तो table structure कभी नहीं आती।

4.2. Paste किया data बाहरी input है

आसानी से छूटता है, पर clipboard content बाहर का data है, और नहीं जानते किस ऐप ने रखा। Microsoft OLE clipboard document में भी चेताता है कि “clipboard data विश्वसनीय नहीं। ऐप में इस्तेमाल से पहले सावधानी से parse करें”।⁷

• Validate करें कि HTML Format header offsets buffer के बाहर न इशारा करें (टूटे header निकालने वाले ऐप मौजूद हैं)।
• जिन्हें number, date, या code के रूप में import करें वे screen input जैसी ही validation से गुज़रें।
• विशाल data के विरुद्ध बचाव लगाएँ। भले कोई सैकड़ों-megabyte image या लाखों पंक्तियाँ text paste करे, UI block न करें, और सीमा पार होने पर अस्वीकार करें। सावधानी: .NET का GetData, जिस क्षण बुलाते हैं, पूरा payload managed string में materialize करता है (और delayed rendering उसके भाग के रूप में चलती है), इसलिए GetData के बाद size जाँच बचाव नहीं। Win32 में, GetClipboardData द्वारा लौटे HGLOBAL पर GlobalSize जाँचना “managed string के रूप में conversion और parsing में आगे न बढ़ें” के चरण पर बचाव देता है, पर delayed-rendering format के लिए GetClipboardData स्वयं rendering शुरू करता है, इसलिए copy-source पक्ष पर materialization फिर भी नहीं रोक सकते। UI जमने से बचाने के लिए, लाना UI thread से हटाएँ (और तब भी, क्योंकि .NET का Clipboard STA माँगता है, Task.Run thread-pool thread (MTA) पर नहीं, STA set dedicated thread पर करें — खंड 5.1)।

यह विचार कि “बाहर से आने वाला मान, path जो भी हो, इस्तेमाल से पहले validate होता है” वही है जो “QR code के decode मान को ज्यों का त्यों कभी इस्तेमाल न करें” में रखा गया है। यह धारणा कि paste सुरक्षित है क्योंकि यह user action है, दुर्घटनाएँ कैसे शुरू होती हैं।

flowchart TB
    accTitle: Paste किए data को इस्तेमाल से पहले validate करें
    accDescr: Clipboard से लिया data format-present, payload-type, size-limit, और content validation से उसी क्रम में गुज़रता है; कोई भी fail हो तो अस्वीकार करें या अगले candidate format पर गिरें
    present["Format मौजूद?"] --> type["Payload type ठीक?"]
    type --> size["Size सीमा में?"]
    size --> content["Content validate करें"]
    content --> ok["Import"]
    type -.->|"गलत type"| rej["अस्वीकार / अगला format"]
    size -.->|"बहुत बड़ा"| rej
    content -.->|"अमान्य"| rej

चित्र 6: Paste बाहरी input है; format, type, size और content validation न पास करें तो स्वीकार न करें।

5. Copy पक्ष की practices — कई formats एक साथ देना, और delayed rendering

5.1. कई formats एक साथ रखें

Copy पक्ष की practice 4.1 की उलटी है: rich format और plain format एक साथ दें। WinForms/WPF DataObject से कुछ पंक्तियों में लिख सकते हैं।¹⁵

// WinForms (System.Windows.Forms). WPF is the same shape with System.Windows DataObject/Clipboard
var data = new DataObject();
data.SetData(DataFormats.Html, htmlFormatText);       // HTML Format string including the header
data.SetData(DataFormats.CommaSeparatedValue, csv);   // CSV
data.SetData(DataFormats.UnicodeText, plainText);     // Plain text
Clipboard.SetDataObject(data, copy: true);            // copy:true = keep after the app exits

दो notes। पहला, .NET का Clipboard class केवल STA thread से इस्तेमाल हो सकता है।¹⁵ WinForms/WPF UI thread [STAThread] के कारण STA है, इसलिए सामान्यतः समस्या नहीं, पर background thread से छूना fail होता है (STA/MTA की बुनियाद “COM STA/MTA की बुनियाद” में है)। दूसरा, copy: true का अर्थ अगले उपखंड की delayed rendering से जुड़ा है।

5.2. Delayed rendering — “source बंद करें और paste बंद” क्यों

हर बार कई formats में बड़ा payload बनाना बर्बादी है, इसलिए clipboard में delayed rendering नामक mechanism है। SetClipboardData को data handle के रूप में NULL दें तो, payload के बजाय केवल “माँगे जाने पर बनाने” का वादा register होता है; जब कोई वह format माँगे, copy source पर WM_RENDERFORMAT आता है, और तभी data बनता है।²

इस design का नतीजा शुरुआती “source ऐप बंद किया और paste बंद हो गया” है। निकलने से पहले, copy source WM_RENDERALLFORMATS पाता है और हर अभी-unrendered format materialize करने का जिम्मेदार है; बिना किए निकलें तो format खो जाता है।²

flowchart TB
    accTitle: Delayed rendering और बंद-कर-paste विफलता क्यों होती है
    accDescr: Copy source NULL handle से केवल वादा register करता है, और माँग पर WM_RENDERFORMAT से materialize करता है। Exit पर हर format WM_RENDERALLFORMATS से materialize करने का जिम्मेदार है; वह छोड़ें तो format खो जाता है
    promise["SetClipboardData NULL = वादा"] --> req["Paste करने वाला पक्ष माँगता है"]
    req --> render["WM_RENDERFORMAT → अभी बनाएँ"]
    promise --> quit["Copy source निकलने वाला है"]
    quit -->|"RENDERALLFORMATS"| ok["Exit बाद paste काम करता है"]
    quit -->|"Materialize छोड़ें"| lost["बंद बाद format खोया"]

चित्र 7: Delayed rendering वादा रखती है; exit पर materialization छोड़ें तो paste मर जाता है।

OLE clipboard पर (OleSetClipboard से IDataObject रखने वाली शैली), यह संबंध और भी स्पष्ट है। Clipboard केवल data object का pointer रखता है, और ऐप exit पर OleFlushClipboard call करना data clipboard पर materialize करता है, इसलिए exit के बाद भी paste काम करता है।⁶ .NET का Clipboard.SetDataObject(data, copy: true) यही “exit के बाद रखें” व्यवहार specify करता है।

Excel में बड़ी range copy कर निकलने की कोशिश करने पर संकेत “There is a large amount of information on the Clipboard. Do you want to be able to paste this information into another program later?” ठीक इसी materialization (flush) को चलाना है या नहीं की पुष्टि है। यदि अपने ऐप में delayed rendering इस्तेमाल करें, याद रखें कि exit-समय materialization उसी सेट का भाग है। Delayed rendering performance optimization है, और क्योंकि render request message processing के भीतर synchronous चलता है, बनने में लंबा लगने वाले data का UI जमने का समझौता है।²

6. Clipboard देखने की practices — listener, retry, और history exclusion

6.1. AddClipboardFormatListener इस्तेमाल करें

“Barcode-reader मान या line-of-business सिस्टम से copy पकड़कर स्वतः import करना चाहते हैं” जैसी आवश्यकताएँ clipboard changes देखने की माँग करती हैं। ऐतिहासिक रूप से तीन विधियाँ हैं; आज सही उत्तर एक है।⁸

flowchart TB
    accTitle: Clipboard देखने का flow
    accDescr: Handle बनने पर AddClipboardFormatListener से register करें, और WM_CLIPBOARDUPDATE आता है चाहे जिस ऐप ने copy की। Retry से पढ़ें, और handle नष्ट होने पर RemoveClipboardFormatListener से symmetric unregister करें
    created["AddClipboardFormatListener"] --> wait["Wait"]
    anyapp["कोई ऐप copy करता है"] --> notify["WM_CLIPBOARDUPDATE"]
    wait --> notify
    notify --> readtry["Retry से पढ़ें（6.2）"]
    readtry --> wait
    destroyed["RemoveClipboardFormatListener"] -.->|"Unregister"| created

चित्र 8: Clipboard देखना listener + retry है; polling और पुरानी viewer chain इस्तेमाल न करें।

// Minimal WinForms implementation
public partial class MainForm : Form
{
    [DllImport("user32.dll", SetLastError = true)]
    static extern bool AddClipboardFormatListener(IntPtr hwnd);
    [DllImport("user32.dll", SetLastError = true)]
    static extern bool RemoveClipboardFormatListener(IntPtr hwnd);
    const int WM_CLIPBOARDUPDATE = 0x031D;

    protected override void OnHandleCreated(EventArgs e)
    {
        base.OnHandleCreated(e);
        AddClipboardFormatListener(Handle);
    }

    protected override void OnHandleDestroyed(EventArgs e)
    {
        // Unregister symmetrically to match handle destruction / recreation
        RemoveClipboardFormatListener(Handle);
        base.OnHandleDestroyed(e);
    }

    protected override void WndProc(ref Message m)
    {
        if (m.Msg == WM_CLIPBOARDUPDATE)
        {
            // Read Clipboard.GetDataObject() here and import if the format is one you need
        }
        base.WndProc(ref m);
    }
}

6.2. जब खोल न सकें तो retry करें

एक समय में केवल एक window clipboard खोल सकती है; जब दूसरा process खुला रखे, OpenClipboard fail होता है।² WM_CLIPBOARDUPDATE के तुरंत बाद, copy source या दूसरा viewer अक्सर अभी काम कर रहा होता है, इसलिए अस्थायी पढ़ने की विफलता सामान्य घटना है। हमेशा कुछ retries छोटी wait (दसियों milliseconds) के साथ लगाएँ। ध्यान दें कि retry count और interval specify करने वाले .NET Clipboard overloads केवल लिखने वाले पक्ष, SetDataObject पर मौजूद हैं। पढ़ने वाले पक्ष (GetDataObject और साथी) पर समकक्ष नहीं, इसलिए catch-wait-retry स्वयं लिखें — WinForms पर ExternalException, WPF पर COMException।

flowchart TB
    accTitle: Clipboard-पढ़ने का retry flow
    accDescr: एक समय में केवल एक window clipboard खोल सकती है, इसलिए change notification के तुरंत बाद पढ़ना दूसरे process से race कर fail हो सकता है। Exception पर दसियों ms wait कर retry करें; सीमा लगे तो इस बार छोड़ें और अगले update पर लें
    upd["WM_CLIPBOARDUPDATE"] --> tryread["पढ़ने का प्रयास"]
    tryread -->|"सफलता"| useok["Import（अ. 4 जाँच）"]
    tryread -->|"उपयोग में"| waitretry["दसियों ms wait"]
    waitretry -->|"Retry"| tryread
    waitretry -->|"सीमा"| giveup2["इस बार छोड़ें"]

चित्र 9: Notification के तुरंत बाद पढ़ना fail होना सामान्य है; छोटी wait वाला retry रखें।

6.3. History और sync से बाहर रखें — secrets संभालने वाली copy सुविधाओं की देखभाल

Windows में clipboard history (Win+V) और device-across sync (cloud clipboard) हैं, और ऐप द्वारा रखी content default पर दोनों के दायरे में है। Password या account number जैसे secrets copy सुविधा पर रखने वाला ऐप वह registered format भी रखता है जो content को history और sync से exclude करता है।¹

• ExcludeClipboardContentFromMonitorProcessing: इसे रखें तो उस copy की content न history में आती है न sync में।
• CanIncludeInClipboardHistory (DWORD 0): केवल history दबाएँ।
• CanUploadToCloudClipboard (DWORD 0): केवल device-across sync दबाएँ।

Password manager द्वारा copy password Win+V पर न रहने का कारण यही mechanism है। नाम RegisterClipboardFormat को देकर format ID पाते हैं और साधारण data के साथ set करते हैं, इसलिए secrets संभालने वाले किसी भी business ऐप में लागू करने योग्य है।

7. IT की दृष्टि से clipboard — history, cloud sync, और RDP control

Development से थोड़ा हटकर, यहाँ वे बिंदु हैं जो administrator के लिए महत्व रखते हैं। Clipboard history हाल की copies जमा करता है, और cloud clipboard उसी Microsoft account / Microsoft Entra account से sign-in devices पार copy sync करता है।¹⁰ जितना सुविधाजनक, उतना अवशेष और फैलाव भी पैदा करता है: line-of-business सिस्टम से copy व्यक्तिगत जानकारी history में जमा होती है, और काम PC पर copy content व्यक्तिगत PC पर sync होती है।

संगठन में इसे control करने वाली दो policies निम्नलिखित हैं।

दोनों Windows 10 version 1809 से उपलब्ध हैं; disable करें तो Settings ऐप में matching वस्तुएँ धूसर हो जाती हैं, और policy तुरंत प्रभावी होती है।⁹¹⁰

दूसरा नियमित RDP (Remote Desktop) clipboard redirection है। Default पर, local PC और remote session के बीच copy-and-paste काम करता है, इसलिए यह server से secrets निकालने का path बन सकता है। “Do not allow clipboard redirection” policy (registry मान fDisableClip) दोनों दिशाएँ रोक सकती है।¹¹ हाल के Windows Server / Windows 11 releases ने महीन policies भी जोड़ी हैं, जैसे server-से-client दिशा को केवल text तक सीमित करना। पूरी तरह restrict करें या चरणों में सीमित करें यह operations और security का संतुलन है।

flowchart TB
    accTitle: Clipboard content फैल सकने वाले paths, और control बिंदु
    accDescr: Copy content default पर history और cloud sync के दायरे में है, और RDP पर redirection से दूसरे session तक जाती है। हर path policy से control हो सकता है, और ऐप पक्ष exclusion format से स्वयं को history और sync से बाहर रख सकता है
    cb["Clipboard"] --> hist["History（Win+V）"]
    cb --> cloud["Cloud sync"]
    cb --> rdp["RDP redirection"]
    hist -.-> p1["AllowClipboardHistory"]
    cloud -.-> p2["AllowCrossDeviceClipboard"]
    rdp -.-> p3["fDisableClip"]
    cb -.-> p4["ऐप exclusion format（6.3）"]

चित्र 10: History, cloud sync और RDP default पर खुले हैं; secrets संभालने वाले वातावरण में जानबूझकर तय करें।

8. Drag-and-drop COM है — IDataObject + IDropSource + IDropTarget

8.1. Clipboard जैसा वही data, ढोने का अलग तरीका

OLE drag-and-drop निम्नलिखित तीन भूमिकाओं से चलता है।¹²

Drag source DoDragDrop बुलाता है, drag loop शुरू होता है, और जब mouse drop-target window में प्रवेश करे वह IDropTarget सूचित होता है; drop पर, IDataObject सौंपा जाता है। Official document यह भी कहता है कि “D&D ठीक वही functionality देता है जो clipboard copy-and-paste। यदि ऐप पहले से copy-and-paste लागू करता हो, जोड़ छोटा है”।¹² यानी, chapter 2 से 5 में बनाया multi-format DataObject ज्यों का त्यों D&D payload बन जाता है।

flowchart TB
    accTitle: OLE drag-and-drop का flow
    accDescr: Drag source IDataObject payload में रखता है और DoDragDrop से drag loop शुरू करता है; drop target का IDropTarget DragEnter और DragOver में accept/reject घोषित करता है, और Drop पर IDataObject से format चुनकर निकालता है
    src["IDataObject + IDropSource"] -->|"DoDragDrop"| loop["Drag loop"]
    loop -->|"Mouse प्रवेश"| enter["DragEnter/Over: Effect"]
    enter -->|"बटन ऊपर"| drop["IDropTarget.Drop"]
    drop --> data["Format चुनें और निकालें"]

चित्र 11: D&D clipboard जैसा वही IDataObject ढोता है; copy-and-paste हो तो जोड़ छोटा है।

8.2. OleInitialize (STA) आवश्यक है

जो window drop target बनेगी वह RegisterDragDrop से register होती है, और यहाँ classic जाल है। यदि COM CoInitialize/CoInitializeEx से initialize किया, RegisterDragDrop हमेशा E_OUTOFMEMORY से fail होता है; OleInitialize से initialization करना चाहिए।¹³ OleInitialize COM को STA के रूप में initialize करता है, क्योंकि D&D window और message pump की STA दुनिया में जड़ी सुविधा है। Calling thread को message pump भी चलाना चाहिए; छोड़ें तो drag के दौरान अन्य ऐप hang होते हैं।¹³ यहाँ की पृष्ठभूमि ठीक “COM STA/MTA की बुनियाद” की threading-model चर्चा है।

WinForms/WPF ऐप में framework OLE initialization और interface implementation संभालता है, इसलिए developer को केवल events लिखने होते हैं।

// WinForms: accept dropped files
listView1.AllowDrop = true;
listView1.DragEnter += (s, e) =>
{
    // Also check that the source allows Copy (some sources only allow Move/Link)
    e.Effect = e.Data.GetDataPresent(DataFormats.FileDrop)
            && (e.AllowedEffect & DragDropEffects.Copy) == DragDropEffects.Copy
        ? DragDropEffects.Copy      // Accept: receive as a copy
        : DragDropEffects.None;     // Do not accept
};
listView1.DragDrop += (s, e) =>
{
    // Drag data is also untrusted input. Even if it advertises FileDrop, the payload
    // can be null or a different type, and GetData itself can fail
    object data;
    try { data = e.Data.GetData(DataFormats.FileDrop); }
    catch (COMException) { return; }
    if (data is not string[] paths) return;
    foreach (var path in paths)
    {
        // Validate the path before importing (Section 9.3)
    }
};

रूप WPF में वही है: element पर AllowDrop="True" और DragOver/Drop events से पाते हैं, और path array e.Data.GetData(DataFormats.FileDrop) से निकालते हैं। हर DragEnter/DragOver पर accept/reject (Effect) घोषित करना IDropTarget practice है; छोड़ें तो वह bug मिलता है जहाँ cursor “अनुमति नहीं” पर रहता है और कभी नहीं बदलता।

9. D&D के जाल — elevation, Move, और path validation

9.1. Administrator के रूप में elevated ऐप पर drop नहीं कर सकते

File Explorer से “Run as administrator” से चलाए ऐप पर फ़ाइल drop करें और कुछ न हो — यह implementation bug नहीं, OS व्यवहार है। UIPI (User Interface Privilege Isolation) निम्न-integrity process से उच्च-integrity window तक messages default पर रोकता है, इसलिए साधारण-privilege (medium-integrity) File Explorer से drop notifications elevated ऐप तक पहुँचती ही नहीं।¹⁴

flowchart TB
    accTitle: UIPI elevated ऐप पर drop कैसे रोकता है
    accDescr: Medium-integrity File Explorer से उच्च-integrity elevated ऐप तक drop notifications UIPI default पर रोकता है और पहुँचती नहीं। UI साधारण privilege पर रखें और privilege काम अलग करें, तो drop पहुँचता है
    explorer["Explorer（medium）"] -->|"Drop notification"| uipi{"UIPI"}
    uipi -->|"रोका"| elevated["Elevated ऐप: drop नहीं"]
    uipi -->|"गुज़रता"| normal["साधारण UI: drop पहुँचता है"]
    normal -.->|"Privilege काम सौंपें"| broker["अलग elevated process"]

चित्र 12: Elevated ऐप पर drop UIPI रोकता है; UI साधारण privilege पर रखें तो drop आता है।

ChangeWindowMessageFilterEx से WM_DROPFILES जैसे specific messages individually allow देने वाला उपाय जाना-माना है,¹⁴ पर जो वह गुज़रने देता है वह पुरानी (WM_DROPFILES) drop notification है; OLE D&D समग्र हल नहीं करता। Practical मार्गदर्शन स्पष्ट है: ऐप को हमेशा elevated चलाने वाला design छोड़ें। केवल elevation चाहिए वाला काम अलग process में अलग करें, और UI स्वयं साधारण privilege पर रह D&D पा सकता है (isolation design “Windows ऐप में "केवल Administrator privilege चाहिए वाले काम" को ठोस रूप से अलग कैसे करें” में विस्तार से है)।

9.2. DragDropEffects का अर्थ — Move वह अनुबंध है कि “original चला जाता है”

DragDropEffects पर Copy/Move/Link सजावट नहीं; वे drag source और drop target के बीच अनुबंध हैं। Drag source DoDragDrop में अनुमति effects का सेट घोषित करता है, drop target वास्तविक effect चुनता है, और जब Move सफल हो, drag source data (फ़ाइल) मिटाता है — यही practice है। यदि पाने वाला पक्ष बिना सोचे Move लौटाए, वह दुर्घटना मिलती है “drop किया और original फ़ाइल गायब हो गई”। Business ऐप के import इस्तेमाल के लिए, पाने वाला पक्ष Copy बताना सुरक्षित default है।

flowchart TB
    accTitle: DragDropEffects अनुबंध — Move original मिटाता है
    accDescr: Drag source DoDragDrop में अनुमति effects का सेट घोषित करता है, और drop target वास्तविक effect चुनता है। Move सफल होने पर source फ़ाइल मिटाता है, इसलिए import के लिए पाने वाला पक्ष Copy बताए
    srcdecl["Source: अनुमति effects"] --> tgtsel["Target: Effect चुनें"]
    tgtsel -->|"Copy"| copyok["Original रहता है（import）"]
    tgtsel -->|"Move"| moveact["Source फ़ाइल मिटाता है"]

चित्र 13: Import पर पाने वाला पक्ष Copy बताए; Move original फ़ाइल मिटाने का अनुबंध है।

9.3. Drop किए path का validation

CF_HDROP/FileDrop में जो चलता है केवल path है (खंड 3.2)। Import से पहले, paste जैसी ही untrusted-input validation से गुज़ारें।

• फ़ाइल या folder: विनिर्देश के रूप में तय करें कि पूरा folder drop होने पर क्या होता है (recursive import, या अस्वीकार)।
• OneDrive placeholder: Path मौजूद हो सकता है जबकि फ़ाइल body local न हो — on-demand फ़ाइल। खोलते ही download शुरू होता है, और offline fail होता है। व्यवहार और उपाय “OneDrive "Files On-Demand" और business ऐप” में हैं।
• लंबे paths और असामान्य paths: MAX_PATH से अधिक path, network (UNC) path, और removable media पर path तभी स्वीकार करें जब पुष्टि हो कि आगे की processing उन्हें संभाल सकती है।
• संख्या और कुल size: ताकि हज़ारों फ़ाइलें drop करने से UI न जमे, import async करें और सीमा तथा progress display लगाएँ।

10. सारांश

• Clipboard वह mechanism है जो एक ही desktop (window station) के भीतर साझा एकल क्षेत्र में एक ही content कई formats में एक साथ रखता है। Paste करने वाला पक्ष format चुनता है, इसलिए वही copy अलग results देती है।
• Text CF_UNICODETEXT है, फ़ाइलें CF_HDROP, और formatted text registered format HTML Format (byte-offset header + UTF-8)।
• Paste करने वाला पक्ष rich से plain तक देखता है और payload को बाहरी input मानता है। Copy पक्ष कई formats एक साथ देता है, और यदि delayed rendering इस्तेमाल करे तो exit-समय materialization (WM_RENDERALLFORMATS / OleFlushClipboard) भी लागू करता है।
• देखना AddClipboardFormatListener + WM_CLIPBOARDUPDATE है। OpenClipboard race के लिए retry तैयार रखें, और secrets को ExcludeClipboardContentFromMonitorProcessing और साथी से history तथा sync से बाहर रखें।
• IT clipboard history, cloud sync, और RDP redirection GPO / Intune से control कर सकता है। Default सबके लिए अनुमति है, इसलिए secrets संभालने वाले वातावरण में जानबूझकर तय करें।
• D&D COM है: IDropSource/IDropTarget clipboard जैसा वही IDataObject सौंपते हैं। RegisterDragDrop को OleInitialize (STA) चाहिए।
• Elevated ऐप पर drop UIPI रोकता है। DragDropEffects पर Move वह अनुबंध है कि “original चला जाता है”; drop किए path को import से पहले validate करें।

Copy-and-paste और D&D user के लिए वायु जैसी सुविधाएँ होनी चाहिए। ठीक इसलिए “paste नहीं कर सकता”, “बिखर जाता है”, और “गायब हो गया” अनुभव इतना चोट पहुँचाते हैं — और जो ऐप कई formats देता और drop सही संभालता है वह रोज़ के operations को स्वयं सहज बनाता है। आशा है जब तय करें कि पहले क्या ठीक करें, यह उपयोगी सामग्री हो।

संबंधित लेख

• COM / ActiveX / OCX क्या हैं? — अंतर और संबंध समझाए गए
• COM STA/MTA की बुनियाद — threading model और hang से बचना
• आज Windows shell integration — context menu, file association, और Windows 11 में क्या बदला
• C# Excel COM automation के बाद EXCEL.EXE process क्यों रहते हैं — reference release pattern और प्रतिस्थापन decision
• Windows ऐप UX design — उपयोग वातावरण के अनुसार priorities
• OneDrive “Files On-Demand” और business ऐप — placeholders कौन सी धारणाएँ तोड़ते हैं और उनसे कैसे निपटें

संबंधित consulting क्षेत्र

KomuraSoft LLC business ऐप में copy-and-paste और drag-and-drop support का design और implementation संभालता है (कई formats देना, Excel interop, drop फ़ाइलें import करना), “paste करने पर बिखर जाता है” या “copy गायब हो जाती है” जैसी समस्याओं की root-cause investigation, clipboard देखने वाला input automation, तथा confidential data को history और sync से बाहर रखने वाली implementation। COM और OLE की निचली layers वाले मामले symptoms अलग करने से शुरू करने पर भी स्वागत योग्य हैं।

• Windows ऐप विकास
• COM कॉम्पोनेंट विकास
• तकनीकी परामर्श और डिज़ाइन समीक्षा
• संपर्क करें

संदर्भ लिंक

संबंधित लेख

निकटवर्ती विषयों में गहराई से जाने के लिए समान टैग वाले नवीनतम लेख।

संबंधित विषय

ये पृष्ठ विषय को सेवाओं और निर्णयों के व्यापक संदर्भ में रखते हैं।

इस विषय से जुड़ी सेवाएँ

यह लेख निम्नलिखित सेवाओं से सीधे जुड़ा है।

अक्सर पूछे जाने वाले प्रश्न

इस लेख के विषय पर परामर्श में अक्सर पूछे जाने वाले प्रश्न।

Excel से copy की table मेरे ऐप में paste करने पर formatting क्यों बिखर जाती है?

Clipboard "एक टुकड़ा data" नहीं रखता। एक ही content कई formats में एक साथ रखी जाती है (source ऐप का private format, HTML Format, CSV, Unicode text, आदि), और destination ऐप वह format चुनता है जिसे समझता है और उसे निकालता है। जब formatting बिखरती है, typical कारण है कि destination केवल plain text (CF_UNICODETEXT) पढ़ रहा है। यदि table structure भी चाहिए, paste करने वाले पक्ष को HTML Format या CSV priority देने वाला लागू करें। इसके विपरीत, यदि चाहते हैं कि अन्य ऐप आपके ऐप से की गई copy सही paste करें, copy समय rich format और plain format दोनों दें।

जिस ऐप से copy किया उसे बंद करने के बाद paste क्यों बंद हो जाता है?

क्योंकि source delayed rendering इस्तेमाल कर रहा है। बड़े data संभालने वाले ऐप copy समय payload नहीं रखते; clipboard पर केवल वादा register करते हैं कि "माँगे जाने पर बनाएँगे"। यदि source तब बिना WM_RENDERALLFORMATS का उत्तर दे data materialize किए निकले, जो formats अभी render नहीं हुए वे खो जाते हैं। OLE clipboard (IDataObject) इस्तेमाल करने वाला ऐप exit पर OleFlushClipboard call कर data materialize करके exit के बाद भी paste चालू रख सकता है।

मेरा ऐप clipboard changes कैसे देख सकता है?

वर्तमान recommended विधि है अपनी window AddClipboardFormatListener से listener register करना और हर बार content बदलने पर आने वाला WM_CLIPBOARDUPDATE message handle करना। Timer पर content poll करना काम बर्बाद करता है और updates चूक सकता है, और SetClipboardViewer पर आधारित पुरानी viewer chain केवल backward compatibility के लिए रखी है, क्योंकि chain के एक ऐप का bug पूरी chain तोड़ देता है। ध्यान दें कि पढ़ने पर OpenClipboard fail हो सकता है क्योंकि दूसरा process clipboard पकड़े है, इसलिए स्थिर पढ़ना हो तो छोटी wait वाला retry लागू करें।

क्या password जैसे secrets clipboard history (Win+V) से बाहर रखने का तरीका है?

दो levers हैं, एक ऐप पक्ष पर और एक policy पक्ष पर। ऐप पक्ष पर, copy करते समय registered format ExcludeClipboardContentFromMonitorProcessing भी रखें तो वह content न history में आती है न device-across sync में। प्रत्येक को स्वतंत्र control भी कर सकते हैं CanIncludeInClipboardHistory (केवल history) और CanUploadToCloudClipboard (केवल sync) से। यही mechanism password managers इस्तेमाल करते हैं। यदि पूरे संगठन के लिए बंद करना चाहें, Group Policy या Intune (Policy CSP) से AllowClipboardHistory और AllowCrossDeviceClipboard से history और cloud sync स्वयं disable कर सकते हैं।

Administrator के रूप में चल रहे ऐप पर फ़ाइल drag-and-drop क्यों नहीं कर सकता?

क्योंकि UIPI (User Interface Privilege Isolation) नामक security mechanism निम्न-integrity process से उच्च-integrity window तक messages पहुँचाना रोकता है। File Explorer साधारण privilege (medium integrity) पर चलता है, इसलिए drag-and-drop notifications ऊँचे ऐप की window तक पहुँचती ही नहीं। ChangeWindowMessageFilterEx से WM_DROPFILES जैसे messages individually allow देने वाला उपाय जाना-माना है, पर वह केवल पुरानी drop notification पर लागू होता है। असली fix ऐप को हमेशा elevated चलाने वाला design छोड़ना है, और केवल elevation चाहिए वाला काम अलग process में अलग करना।

लेखक की प्रोफ़ाइल

लेख के लेखक का परिचय पृष्ठ।

Go Komura

KomuraSoft LLC के प्रतिनिधि

Windows सॉफ़्टवेयर विकास, तकनीकी परामर्श और बग जाँच में विशेषज्ञ, विशेष रूप से मौजूदा सिस्टम वाली परियोजनाओं और पुनरुत्पादन में कठिन बग में।