]>
Commit | Line | Data |
---|---|---|
1 | \section{Drag-and-drop and clipboard overview}\label{wxdndoverview} | |
2 | ||
3 | Classes: \helpref{wxDataObject}{wxdataobject}, | |
4 | \helpref{wxTextDataObject}{wxtextdataobject}, | |
5 | \helpref{wxDropSource}{wxdropsource}, | |
6 | \helpref{wxDropTarget}{wxdroptarget}, | |
7 | \helpref{wxTextDropTarget}{wxtextdroptarget}, | |
8 | \helpref{wxFileDropTarget}{wxfiledroptarget} | |
9 | ||
10 | It has to be noted that the API for drag and drop in wxWindows is not | |
11 | yet finished which is mostly due to the fact that DnD support under | |
12 | GTK 1.0 is very rudimentary and entirely different from the XDnD | |
13 | protocoll used by GTK 1.2. This also entails that not all of the documentation | |
14 | concerning DnD might be correct and some of the code might get broken | |
15 | in the future. The next release of wxWindows will be based on GTK 1.2 | |
16 | and will hopefully include a much improved DnD support. The general | |
17 | design on the wxDropSource side will be the same but especially the | |
18 | wxDropTarget is almost certain to change. | |
19 | ||
20 | Note that wxUSE\_DRAG\_AND\_DROP must be defined in setup.h in order | |
21 | to use Drag'n'Drop in wxWindows. | |
22 | ||
23 | This overview describes wxWindows support for drag and drop and clipboard | |
24 | operations. Both of these topics are discussed here because, in fact, they're | |
25 | quite related. Drag and drop and clipboard are just two ways of passing the | |
26 | data around and so the code required to implement both types of the operations | |
27 | is almost the same. | |
28 | ||
29 | Both operations involve passing some data from one program to another, | |
30 | although the data can be received in the same program as the source. In the case | |
31 | of clipboard transfer, the data is first placed on the clipboard and then | |
32 | pasted into the destination program, while for a drag-and-drop operation the | |
33 | data object is not stored anywhere but is created when the user starts | |
34 | dragging and is destroyed as soon as he ends it, whether the operation was | |
35 | ended successfully or cancelled. | |
36 | ||
37 | To be a {\it drag source}, i.e. to provide the data which may be dragged by | |
38 | user elsewhere, you should implement the following steps: | |
39 | ||
40 | \begin{itemize}\itemsep=0pt | |
41 | \item {\bf Preparation:} First of all, the data object must be created and | |
42 | initialized with the data you wish to drag. For example: | |
43 | ||
44 | \begin{verbatim} | |
45 | wxDataObject *my_data = new wxTextDataObject data("This string will be dragged."); | |
46 | \end{verbatim} | |
47 | ||
48 | \item{\bf Drag start:} To start dragging process (typically in response to a | |
49 | mouse click) you must call \helpref{DoDragDrop}{wxdropsourcedodragdrop} function | |
50 | of wxDropSource object which should be constructed like this: | |
51 | ||
52 | \begin{verbatim} | |
53 | wxDropSource dragSource( this ); | |
54 | dragSource.SetData( my_data ); | |
55 | \end{verbatim} | |
56 | ||
57 | \item {\bf Dragging:} The call to DoDragDrop() blocks until the user release the | |
58 | mouse button (unless you override \helpref{GiveFeedback}{wxdropsourcegivefeedback} function | |
59 | to do something special). When the mouse moves in a window of a program which understands the | |
60 | same drag-and-drop protocol (any program under Windows or any program supporting GTK 1.0 | |
61 | DnD protocol under X Windows), the corresponding \helpref{wxDropTarget}{wxdroptarget} methods | |
62 | are called - see below. | |
63 | ||
64 | \item {\bf Processing the result:} DoDragDrop() returns an {\it effect code} which | |
65 | is one of the values of \helpref{wxDragResult}{wxdropsource} enum. Codes | |
66 | of wxDragError, wxDragNone and wxDragCancel have the obvious meaning and mean | |
67 | that there is nothing to do on the sending end (except of possibly logging the | |
68 | error in the first case). wxDragCopy means that the data has been successfully | |
69 | copied and doesn't require any specific actions neither. But wxDragMove is | |
70 | special because it means that the data must be deleted from where it was | |
71 | copied. If it doesn't make sense (dragging selected text from a read-only | |
72 | file) you should pass FALSE as parameter to DoDragDrop() in the previous step. | |
73 | \end{itemize} | |
74 | ||
75 | To be a {\it drop target}, i.e. to receive the data dropped by user you should | |
76 | follow the instructions below: | |
77 | ||
78 | \begin{itemize}\itemsep=0pt | |
79 | \item {\bf Initialization:} For a window to be drop target, it needs to have | |
80 | an associated \helpref{wxDropTarget}{wxdroptarget} object. Normally, you will | |
81 | call \helpref{wxWindow::SetDropTarget}{wxwindowsetdroptarget} during window | |
82 | creation associating you drop target with it. You must derive a class from | |
83 | wxDropTarget and override its pure virtual methods. Alternatively, you may | |
84 | derive from \helpref{wxTextDropTarget}{wxtextdroptarget} or | |
85 | \helpref{wxFileDropTarget}{wxfiledroptarget} and override their OnDropText() | |
86 | or OnDropFiles() method. | |
87 | ||
88 | \item {\bf Drop:} When the user releases the mouse over a window, wxWindows | |
89 | queries the associated wxDropTarget object if it accepts the data. For | |
90 | this, \helpref{GetFormatCount}{wxdroptargetgetformatcount} and \helpref{GetFormat}{wxdroptargetgetformat} are | |
91 | used and if the format is | |
92 | supported (i.e. is one of returned by GetFormat()), | |
93 | then \helpref{OnDrop}{wxdroptargetondrop} is called. | |
94 | Otherwise, wxDragNone is returned by DoDragDrop() and | |
95 | nothing happens. | |
96 | ||
97 | \item {\bf The end:} After processing the data, DoDragDrop() returns either | |
98 | wxDragCopy or wxDragMove depending on the state of the keys (<Ctrl>, <Shift> | |
99 | and <Alt>) at the moment of drop. There is currently no way for the drop | |
100 | target to change this return code. | |
101 | \end{itemize} | |
102 |