Author: Donald J Kenney Contact: DonaldKenney@gmail.com
Copyright 2020-9, Donald Kenney (Donald.Kenney@GMail.com). Unless otherwise stated, permission is hereby granted to use any materials on these pages under the V2.5 Creative Commons License
This is Version 1.200 of this document, released 2009-03-13
(November 2020) This FAQ came about as a result of my frustration with trying to use the Clipboard in Linux applications. Unlike Windows where I thought that the Clipboard generally works consistently, or at least comprehensibly in most programs, I found that clipboard usage in Linux was somewhat problematic for text and often absent (or broken?) for non-text objects. My initial hope was that I would uncover a straightforward, central capability that I could tune to my preferences.
What I found is that the Clipboard in GUI OSes is a distributed capability whose implementation is mostly up to individual program authors. I also found that the documentation on the clipboard was scattered and sometimes reflects misunderstandings based on the way the clipboard is presented to the user which may not be the way it actually works.
But there is good news as well. The more I understood about the clipboard, the better it worked for me. I'm not sure why, but I'm now using Linux for most things and the clipboard mostly works fine.
I'm not 100% sure that everything in this FAQ is correct and would welcome corrections and comments.
Assuming that the application supports the Clipboard (most do), the most likely reason is that the PASTEing program doesn't support any formats(styles,flavors) that the COPYing/CUTing program does. Or possibly that the two programs call the mutual comprehensible formats by different names. Short of modifying the programs, there isn't much that can be done about this other than possibly finding an intermediate program that can PASTE from the COPYing program and then COPY the data in a format supported by the program that wants to PASTE the data.
Another possibility is that some programs have internal inconsistencies in clipboard handling. An example I see occasionally in Windows software is that highlighted text can be cut/copied to the clipboard by keyboard actions (Ctrl-C and/or Shift-Del, etc), but not by Edit Menu actions. This usually applies to dialog boxes, but sometimes to text viewing windows as well.
First, you may have tried to copy to the clipboard with Control-C. Many console programs read the keyboard directly and interpret Control-C as an ASCII EOT character -- frequently used as an exit or unconditional break code. Even if clipboard copy works, the Clipboard supported by most Linux programs is part of the X11 Display system. Console programs will typically copy to the gpm clipboard which is a different entity and is not visible in other consoles. The solution is to run the console program in a window in a GUI environment (Some programs may not run in such a window) and, if necessary, use the menu bar to COPY the data.
This happens if program termination does not include provision for passing off clipboard data to a clipboard manager. The underlying issue is that in many OSes including Windows, the global memory space used to hold the clipboard data is owned by the program that CUT or COPYed to the buffer. If the global data in the 'clipboard' were not released or ownership transferred upon program termination, the memory would be locked up until the next system boot (i.e. would 'leak'). The solution would be to not terminate the source program. Another would possibly be to use a Clipboard Manager that copies data to a true global clipboard once a COPY/CUT operation has taken place.
This is primarily a problem in Unix which uses a lazy (deferred) Clipboard model. The solution is to run a clipboard manager like Klipper. Klipper may slow graphics heavy programs down when cutting and pasting. (In Windows and on the Macintosh, the equivalent to Klipper will be running whether you want it to or not).
The Lazy Data Model is an approach to computer clipboards that defers actual data transfers until a PASTE operation is requested. The model has substantial performance and resource usage advantages over copying data to a global buffer immediately when COPY or CUT are requested. See Section 4.1
In general, this occurs when there are misunderstandings about what character sets and conventions are used by the COPYing and PASTEing programs. As with failure to Paste the best solution is probably to try to PASTE to an intermediate program that handles text differently and COPY from there. Obviously, this is a trial and error process.
PASTE SPECIAL is a PASTE operation sometimes available in Windows Programs. If the Clipboard has data in several formats, PASTE SPECIAL may allow the user to select which is to be used. Without PASTE SPECIAL, the choice of formats will be made automatically.
PASTE AND MATCH STYLE is a Macintosh PASTEing option that attempts to match the format of PASTEd text to the format of the material where the PASTE is being performed.
Mostly it does. The biggest difference is that Windows uses an immediate data transfer model whereas Unix uses a deferred model. The immediate model uses more resources and slows the computer, but retains clipboard data if the source program is terminated. To put Unix (Linux) into an immediate mode, simply start the KDE clipboard manager program klipper. It is possible to start klipper when X-Windows is started. Typically this is done by adding an appropriate klipper.desktop file to the desktop program's autostart file. Other problems are presumably due to bugs. There are plenty of clipboard bugs in applications for all OSes if you watch carefully.
A computer clipboard is a software tool that allows computer users to copy or move information from one place to another using what appears to be an anonymous, universally accessible, storage area. There are alternatives. Drag and drop allows objects to be copied or moved if both the source and destination can be made visible. OLE allows programs to recruit other processes to provide objects that appear to be under the control of the program and therefore look like they have been moved. Files and pipes allow data to be moved between cooperating programs.
Some clipboards are text only. Others support moving formatted text, images, links, and other non-text objects. Windows, for example, allows files to be copied or cut to the clipboard. Usage conventions and details vary between Operating Systems; different versions of the same OS; and often within different programs run within the same environment. These differences cause some user annoyance.
Most GUI operating systems have clipboards that appear to the user to be a dedicated block of system memory where any program can store and access data. Some text based systems that support multiple activities running simultaneously have clipboard like buffers ("cut buffers", "kill buffers") as well. At least one experimental GUI-like Operating System -- oberon -- uses drag and drop instead of a clipboard.
It has been observed that although clipboards use the terminology used by copy editors of a previous era, the operations performed are different. The newsroom cut and paste involved taking a draft article, physically cutting it up into logical pieces, rearranging them into a new order, pasting the article back together, and editing transitions and such to reflect the new, and hopefully better, arrangement. The PC clipboard on the other hand merely allows blocks of text to be copied, replicated, or discarded. The classical copy editing operations are possible, but not especially convenient, with the PC clipboard as it has evolved.
Clipboards presumably had their origin in text buffers used in interactive editors and later in word processors to move data around. These originated in the late 1960s or earlier. In their simplest form, a user would somehow mark a block of text, cut or copy it to a buffer, and later copy it back (generally someplace else) one or more times -- an operation that we would now call pasting.
Clipboards came into their own when Graphical User Interfaces (GUIs) started to come into use in the early 1980s. The Xerox Palo Alto Research Center (PARC) developed software that could move and copy objects as early as the mid 1970s. There were other experimental GUI OSes and it is possible that some of them had a clipboard or a clear predecessor. Credit for the first modern clipboard is generally given to Apple Computer where the concept was developed independently by the Lisa development team. Development on the Lisa started in 1979. The first products were shipped in 1983. A Clipboard was included in Apple's Macintosh shipped in 1984. Microsoft had a clipboard in Windows 1.0 shipped in November 1985. Other GUI OSes also had clipboards -- for example NEXTSTEP (the Pasteboard).
Macintosh and Windows Clipboards have always included the capability to support multiple object types (e.g. images, text, links, etc). Later enhancements -- sometimes third party -- add accessible histories of prior clipboard contents.
Although Unix was at the forefront of many computing advances in the last quarter of the 20th Century, Graphical User Interfaces and clipboards came somewhat late to Unix. The X-Windows window manager was not released in its final form (X11) until 1987. Some Linux environments -- KDE and Gnome -- provide clipboards with capabilities similar to the Macintosh and Windows. Some clipboard capabilities such as the ability to select and move non-text objects must, of necessity, be implemented in individual client programs and may not be available in software not written for the specific environment. For example the KDE Word Processor KWORD can obtain text and images from other KDE software via the clipboard. But it can only obtain text from the non-KDE Firefox web browser. Linux also supports a clipboard like pre-X11 text-only cut buffer that is dubiously well integrated with the X11 clipboard.
Clipboards appear to the user to be a sort of global storage area where "objects" that have been marked by a user can be stashed for later access elsewhere. The user sees three commands. COPY (appears to) create(s) a copy of the data in the clipboard, CUT (appears to) move(s) the object to the clipboard. PASTE appears to copy the object in the clipboard (non-destructively) to the destination. There is a fourth command PASTE SPECIAL that allows data with multiple representations such as images or formatted text to be pasted in any of several user selected formats. Macintosh programs support a PASTE AND MATCH STYLE (Ctrl-Option-Shift-V) that matches copied text to the type of the surrounding material. Copying or Cutting a new object to the clipboard overwrites any previous selection of the same type. In addition to the obvious functions of copying and moving data, clipboard operations are sometimes used simply to convert data between formats.
The actual operations under the hood may be somewhat different than they appear to the user. Using a global buffer area may potentially require a lot of resources. Large blocks of data may need to be transferred then stored redundantly -- once in the original program and once in the global buffer. That can cause excessive resource use and slow operation -- especially if a network is involved. The problems are exacerbated if the data has many possible representations (e.g. ASCII, Unicode, HTML, RTF). Either all would need to be present in the global buffer or the clipboard would need to know how to do data transformations.
To get around the resource and transformation problems, some Clipboard schemes including those used in Java and Linux use what Java calls a "lazy data model" instead of an immediate data model. In this model, a program wishing to cut or copy simply claims Clipboard ownership, but does not transfer data until it is asked for it. Programs wishing to Paste, interrogate the clipboard manager as to who owns the clipboard, then negotiate a transfer -- including a style/flavor/format -- with the owner.
Java and Unix use the lazy model. I have seen assertions that Windows uses a lazy model, but the examples I have looked at clearly use an immediate data model. I have been unable to determine how the Macintosh clipboard (pasteboard) works, or whether its operation is the same in all iterations of the OSes. My best guess is that it does not use the lazy data model and somehow uses a desktop file called a 'scrap' to hold all supported data representations. There seems to be a convention that when multiple representations are copied, they are ordered with the most complex first. Tasks doing pasting present a list of representations they can handle ordered in the same fashion. The paste is done using the first match between the two lists. Here's a link to a programmer's notes on the Mac clipboard. I can make sense out of about one sentence in five -- not because of poor writing but because I don't understand the context.
In the lazy data model, clipboard owners are notified when another program claims clipboard ownership. Programs may be expected to keep track of times of clipboard ownership and not to service PASTE requests for times outside those intervals. In some systems a task that has clipboard ownership is expected to pass off its clipboard information to a clipboard manager if the task terminates. That prevents data from "vanishing" from the clipboard when a task terminates while still owning the clipboard but negates some of the advantages of the lazy data model.
PC operating systems generally have little or no idea about the nature of "objects" seen by programs. Clipboards could work better and more consistently if OSes could select objects or copy/move objects around without help from applications. But for the most part, the OS has no idea what to select, copy, or move, nor of what selections/transformations to make if multiple formats are supported, nor of where to put the copied/moved object. The application programs have to manage the object selection, moves, COPY, CUT, and PASTE. This can and does lead to discrepancies in how different programs handle selection, identification of selected material, and how users request CUT, COPY and PASTE.
Note: There seems to be little agreement on what the terms Clipboard Manager and Clipboard Extender mean. I've tried to use the terms consistently, but my definition may not be the same as anyone else's.
Current clipboard selections would become inaccessible if the program owning the clipboard were no longer running. That doesn't always happen because a clipboard manager program is often used. One type of Clipboard manager is a passive program. A program that is terminating while owning the clipboard can hand off the data and the clipboard ownership to the passive Clipboard Manager which will then service any requests for the data.
A clipboard manager in a system using the Lazy data model is likely to be more active. It observes that someone has taken ownership of the clipboard. It asks the owner for the clipboard contents which it stashes in its clipboard buffer. Then it takes ownership of the clipboard so that anyone asking for data will get the data from the manager instead of the former owner. Basically, this kind of manager converts a lazy data model system into a global buffer system.
Windows and Macintosh have built in clipboard management. Unix does not, but the KDE clipboard manager -- KLIPPER -- will run with desktops other than KDE. It can be used to provide clipboard management on most (all?) Unix GUIs using X11 windows management,
Clipboard managers and clipboard extenders (extensions to Clipboard Management) can be used to build a layer of software on top of the basic operations that allows clipboard objects to be persistent (i.e. not to go away if the source program is terminated), allows for a clipboard history to be maintained, and permits objects of different types to reside in the clipboard simultaneously. Confusingly, clipboard extenders are often called Clipboard Managers. Support for multiple data representations is a problem for clipboard managers since saving data in all the possible formats can use excessive resources. See the section on problems for a discussion of approaches to handling multiple representations.
Clipboard managers can be designed to save clipboard contents in persistent storage, but usually are not. In most operating systems, restarting the OS clears the clipboard of all content
There is one special case of clipboard handling. When console tasks are run in text mode, they are often run under a text shell such as bash (Unix) or CMD/COMMAND(Microsoft). In this case, because the objects in use are known to be text strings, and the shell or some resident monitor program can examine inputs and outputs, it's possible for the shell or monitor program to mark screen areas and provide clipboard services to console programs that were not designed for clipboard support. This can be wildly confusing if the program has it's own clipboard support because the two clipboards not likely to be aware of each other. But for the vast majority of text mode programs these shell clipboards work well and produce a simple, straightforward, text mode clipboard. Integrating shell clipboards with the system GUI clipboard is possible, but not entirely trivial.
There are a few other details. Clipboard selections are window specific, but conceptual clipboards are global. Attempts to implement clipboard schemes that implicitly copy information to the global clipboard will run into trouble deciding which window object selection to use for the source. Windowing systems work by passing messages. Sometimes there are significant delays between messages being sent and messages being acted upon. That can cause race conditions that depend on the order in which streams of events occur. In an attempt to solve (or at least moderate) the race conditions, clipboard related events may be time tagged and clipboard related actions may be expected to reflect the state of the clipboard at the time of the action, not the state at the current time.
In general, text or object selection can be done using either the keyboard or the "mouse". Selection is usually done by holding down the (left) mouse key while moving the mouse or holding down the shift key while using mouse or the arrow and positioning keys (e.g. page up, end) on the key board. Selected text is generally highlighted. In most cases cut/copy/paste are done either by clicking appropriate icons or by means of keystrokes Ctrl-C or Ctrl-Ins for Copy, Ctrl-X or Shift-Del for cut, Ctrl-V or Shift-Ins for paste. Ctrl-C,X,V derive from the Macintosh. Ctrl-Ins, Shift-Ins, Shift-Del are Windows conventions derived from IBM's Common User Access Specification. Most software recognizes one or the other. Some recognizes either. Ctrl-C, while fine in a Macintosh environment, conflicts with a long-standing use of Ctrl-C as a program termination combination in Unix and MSDOS console software. See Problems.
Mouse based object selection for clipboard operations is usually similar to or identical to object selection for drag and drop. Some Unix software supports a convention where objects selected with the mouse can be moved by clicking the mouse at the desired location -- usually using the middle key or simultaneous clicking of the left and right mouse keys. Mouse actions tend to be somewhat overloaded (actions can have more than one meaning) and can lead to undesired activity. See Problems.
Most scripting languages support some sort of clipboard set and access commands. This may be built in or may be by means of programs that can be executed in a script and set/deliver clipboard information using files, pipes or environment variables.
Classic clipboards do not provide access to clipboards on other network computers. Extensions exist to allow such access. Windows supports access to other computer clipboards via NETDDE. Microsoft's .NET supports access to clipboards on other computers. Network clipboard support can raise security concerns.
For purposes of this FAQ, a Clipboard Manager is a program that manages clipboard interfaces that would otherwise be negotiated directly between a source program (the program that owns the clipboard) and a client program that wishes to do a paste. Clipboard managers provide the user accessible global storage space that users assume exists, and may also maintain clipboard histories allowing access to old contents. Clipboard histories generally appear to the user single n-element push down stack with each new selection -- regardless of type -- added to the top and the oldest entry pushed out the bottom.
A distinction is sometimes drawn between Clipboard Managers and Clipboard Extenders. In direct data models, Clipboard Managers provide a parking place for clipboard data when programs terminate. In lazy data models Clipboard Managers provide an actual global data buffer rather than a virtual data buffer that doesn't actually exist. Clipboard Extenders provide additional functions such as history.
It isn't practical to consider all clipboard implementations. Here is a summary of a few of the most popular:
Java is a more or less platform independent programming language that uses a virtual machine to allow the same code to run on different operating systems. Java added Clipboard (Copy, Cut, Paste) and Drag and Drop support in Version 1.1. Java has support for multiple data formats using MIME types or Java flavor names that are MIMElike and end with an x. Java supports multiple independent clipboards, but the clipboard used for general intercommunication is called SYSTEM. There are two clipboard methods -- setContents and getContents; an event -- LostOwnership and an additional method --getTransferData that is used to negotiate data formats. Data formats are called 'Flavors' in Java. See the specification for the Java Transfer API - https//docs.oracle.com/cd/E40972_01/doc.70/e49239/symbols/wsc.DataTransfer.html for details. Java supports what it calls the 'Lazy' data model -- e.g. Copy is deferred until a Paste is requested and therefore apparently requires that applications that support Copy also support the lazy model.
This is a link to information on the Java Clipboard Class. There are a couple of Fields (whatever the heck a Java Field is - My guess is they are Attributes) called owner and contents. There's a constructor called Clipboard. And there are three Methods -- getName, setContents, and getContents.
The Apple Macintosh clipboard is externally similar to the Windows clipboard (and vice versa). All Mac programs use the Ctrl-C,X,V keys for Copy, Cut, Paste. A large number of non-text data types are supported. Clipboard viewing is available from the Finder menu. A separate Application Programming Interface supports moving objects via drag and drop.
A secondary, text-only clipboard, is also available. It is an emacs-style kill-ring. This works in all applications that use standard Cocoa_%28API%29 text boxes:
The Windows clipboard is externally similar to the Apple clipboard (and vice versa). Older Windows programs support the IBM CUA conventions of Ctrl-Ins,Ctrl-Del,Shift-Ins for Copy, Cut, Paste. Some also support Ctrl-C,X,V. A few programs support neither, but provide icons and/or Edit Menu entries to accomplish the actions. Roughly 65534 non-text data types are supported. Some Windows clipboardable objects are things like Excel Spreadsheets (or subsets thereof) that may transfer as anything from simple text to complete, properly reindexed spreadsheet subsets depending on the target capabilities. A separate Application Programming Interface supports moving objects via drag and drop. Windows 98 and later ship with a clipboard viewer - CLIPBRD.EXE. Third party extensions support clipboard history.
Windows has two clipboard APIs. There is a widely used traditional API, and a more recent OLE Clipboard API.
In the traditional API, COPY/CUT can be implemented as follows: NOTE: This is based on sample code that implements an immediate data model, not a 'Lazy Data Model' where the global buffer presumably would not be allocated until PASTE is requested
See http://www.codeproject.com/Articles/2242/Using-the-Clipboard-Part-I-Transferring-Simple-Tex for details.
In the traditional API, PASTE can be implemented as follows:
Recognized Windows TypeNames (Formats, 'Flavors' in Javanese):
There is also an OLE (COM) Clipboard Model which is purported to be more capable than the classic model. Other than the usage of OLE data transfer mechanisms, it's not clear what the advantages are.
For most purposes, the Linux clipboard is provided by the X-Windows system. The operation is specified in the Inter-Client Communication Conventions Manual (ICCCM). The ICCCM specifies three single item 'atoms' called PRIMARY, SECONDARY and CLIPBOARD. It appears that the intent was that PRIMARY would be used for drag and drop like text operations whereas CLIPBOARD would be used for clipboard-like operations. The intended use of SECONDARY is not entirely clear. It seems rarely to be used. The CLIPBOARD is not limited to text. A SelectConversion mechanism is specified that allows clipboard clients (not to be confused with X-windows clients) to negotiate data formats. X-Windows supports only one CLIPBOARD item at a time. The ICCCM also describes the role of a clipboard manager and some things that it must support.
A second specification Free Desktop Clipboard Standard addresses some aspects of clipboard management and the mechanisms for supporting them as, for example, when a clipboard owner shuts down and wishes to hand off it's clipboard object to a clipboard manager.
X-Windows also supports a Cut-Buffer data transfer mechanism that appears probably to be a holdover from older X-Windows implementations. Cut Buffers appear to be text only and are implemented as an 8 item rotating buffer. Cut Buffers appear to be mostly used by the emacs text editor and it's environment.
In Windows and Macintosh environments, the clipboard was present in initial releases. In Linux it has evolved. Some older programs may use conventions and techniques that are no longer supported. This can result in some idiosyncrasies. For example, text selected via the mouse manager gpm within a console program run in GUI console support (KONSOLE) will be found in the system clipboard whereas the same selection in an actual console will not.
A text only(?) Interface to the Clipboard is available in the TKINTER GUI manager used by the Python Programming Language. It consists of:
It took no small amount of time to figure out the Python-TKinter interface works in Windows and on Linux. ... Assuming that I have figured out how it works. it may well be different on Macs. Much of the material I found while looking was misleading, incomprehensible, and some of it looks to be just plain wrong. I still haven't found a summary document that lays it all out. I do not plan to undertake a similar exercise for other languages that I know even less about.
As was mentioned earlier, the Macintosh and Windows systems specify different keystroke combinations for user clipboard actions. Ctrl-X and Ctrl-V do not usually present major problems, but when the Macintosh Ctrl-C is ported to Windows/Unix environments it may conflict with previous wide usage of Ctrl-C in text console software to generate an ASCII EOT character (03) that often causes older text based software to exit. Pressing Ctrl-C in console programs in Windows or Unix may copy to the clipboard. Or it may terminate the program forthwith (without copying to the clipboard).
Example If you wish to see why Ctrl-C is often not a great idea in Windows/Linux, install the links2.1-pre18 browser on Linux. Start it in framebuffer video mode. Go to a website and try to copy text using Ctrl-C (Hint: Do not try this unless you know how to restart a TCP/IP stack or are prepared to reboot). This particular program will copy text to the Clipboard, but only using its own dedicated function key sequence.
Some programs use the Macintosh keystroke conventions (Ctrl-C,X,V) for Copy, Cut, Paste. Some programs use the IBM CUA/Windows conventions (Ctrl-Ins,Shift-Ins, Shift-Del). Many Windows/Linux use both. Some programs -- especially those that have already used some of these keystrokes for other things, have their own conventions. Edit menus with clipboard action options may or may not be present. Icons for clipboard actions may or may not be present, may not be consistent, and may be in different relative locations in different programs. Some programs will not copy/cut/paste some objects from the Edit Menu but will from the keyboard under some conditions (e.g. in dialog or editing boxes). Some portions of the user interface in some contexts may be configurable, but rarely to the extent that a user can configure all the software to use the same conventions. Not surprisingly, users find this lack of consistent semantics for clipboard usage confusing and/or annoying.
The Copy action usually provides no visible feedback to the user about whether the action succeeded. There may sometimes be some ambiguity about which object was copied. If the desired information is not actually copied to the clipboard the user may not find out about it until later when a number of actions will need to be repeated. Some users prefer to CUT then PASTE back rather than COPYing just in order to receive visual assurance that the desired data is actually in the clipboard. (And using Undo to recover if it is not).
Some software overloads the mouse using the same mouse action for different program actions and differentiating by speed of mouse motion or other criteria. This sometimes results in undesired actions such as moving text while trying to select it.
If clipboard management is combined with display management and software is run from a remote computer, clipboard data from the remote computer will be passed over the network to the display manager. Programs not specifically designed for this situation may severely load the network with clipboard traffic -- for example by moving mass deleted objects serially to the clipboard over the network.
If a Clipboard Manager program is used to move application data to the clipboard immediately upon Copy or Cut instead of waiting for the target to Paste, and an attempt is made to save multiple data formats in the clipboard, the resources required for the clipboard can be excessive. This can result in sluggish performance. It can also cause background programs to slow down. This problem will be worse if clipboard histories are maintained.
Objects that can have multiple representations such as ornamented text must select a representation (format/type) to use for clipboard transfers. If this is done by the software without user intervention, an inappropriate type (format) may be selected. For example, Text ornamentation like Bold or Italic may be lost. If it user is asked what type/format to use, the user may find the requests burdensome and/or baffling.
To a varying degree, attempts to move data via the clipboard are prone to default to the Least Common Denominator -- unornamented ASCII text. This can cause difficulty even with what might appear to be simple text transfers if one side of the transaction is using ASCII and the other is using some 8 bit superset of ANSI. That may result in conversion of characters to boxes or other unhelpful characters.
The content of the clipboard if changes are made to an object after CUT or COPY is not well defined If a clipboard manager is in use, the content may be the content at the time of the cut/copy. In practice, whether the content will include changes made after the CUT/COPY is somewhat unpredictable.
The asynchronous nature of clipboard commands virtually guarantees race conditions. These are conditions wherein the results of operations depends on the sequence of actions and messages taken within and sent by several programs, and that sequence may vary.
Some programs may use the clipboard internally to transfer data between tasks and/or force data conversions. If Clipboard history is maintained, these operations -- which may be numerous -- will end up in the History, quite possibly displacing user Clipboard Actions.
When data is passed between programs via the clipboard it is assumed that both programs know what the format of the data is. Unless the source and object are the same program, there are plentiful opportunities for misunderstanding. Even as simple a format as ASCII text may use different string length conventions (length specified vs zero terminated vs both), different End Of Line conventions (LF, CR, or a CR-LF pair), and different usages for the 128 8 bit extended values. More complex formats multiply this problem. Even if two programs use identical formats for an object, they may call the formats by different names and thus be unable to effect a transfer. Case handling differences between Operating Systems can cause trouble in transferring data between programs ported between OSes. e.g. is 'jpeg' the same as 'JPEG' or 'Jpeg'?
This can occur when software attempts to use the Clipboard mechanism to solve problems caused by lack of visibility of objects in other conceptual hierarchies. After all, the clipboard is global and everyone can see it? What could possibly go wrong? What can go wrong is that multiple instances of software can overwrite each other's Clipboard communications. This will happen if, for example, a Python script using TKinter for GUI presentation puts up multiple listboxes and the user clicks on entries in several of them, only information relevant to the last clicked will be found in the clipboard.
Copyright 2020-9, Donald Kenney (Donald.Kenney@GMail.com). Unless otherwise stated, permission is hereby granted to use any materials on these pages under the V2.5 Creative Commons License
This page has not been validated as Valid HTML 4.01 Transitional [Date]. Logo Image omitted.
UNRESOLVED ISSUES
Copyright 2006-2012 Donald Kenney (Donald.Kenney@GMail.com). Unless otherwise stated, permission is hereby granted to use any materials on these pages under the Creative Commons License V2.5.
This page will have been validated as Valid HTML 4.01 Transitional prior to posting on the web site. W3C Logo Image omitted.