{
// This data objects are held by the clipboard,
// so do not delete them in the app.
- wxTheClipboard->AddData( new wxTextDataObject("Some text") );
+ wxTheClipboard->SetData( new wxTextDataObject("Some text") );
wxTheClipboard->Close();
}
no default filename will be supplied. The wildcard determines what files
are displayed in the file selector, and file extension supplies a type
extension for the required filename. Flags may be a combination of wxOPEN,
-wxSAVE, wxOVERWRITE\_PROMPT, wxHIDE\_READONLY, or 0. They are only significant
-at present in Windows.
+wxSAVE, wxOVERWRITE\_PROMPT, wxHIDE\_READONLY, or 0.
Both the X and Windows versions implement a wildcard filter. Typing a
filename containing wildcards (*, ?) in the filename text item, and
clicking on Ok, will result in only those files matching the pattern being
-displayed. In the X version, supplying no default name will result in the
-wildcard filter being inserted in the filename text item; the filter is
-ignored if a default name is supplied.
-
-Under Windows (only), the wildcard may be a specification for multiple
+displayed. The wildcard may be a specification for multiple
types of file with a description for each, such as:
\begin{verbatim}
\twocolwidtha{5cm}
\begin{twocollist}
-\twocolitem{{\bf wxOPEN}}{This is an open dialog (Windows only).}
-\twocolitem{{\bf wxSAVE}}{This is a save dialog (Windows only).}
-\twocolitem{{\bf wxHIDE\_READONLY}}{Hide read-only files (Windows only).}
-\twocolitem{{\bf wxOVERWRITE\_PROMPT}}{Prompt for a conformation if a file will be overridden (Windows only).}
+\twocolitem{{\bf wxOPEN}}{This is an open dialog.}
+\twocolitem{{\bf wxSAVE}}{This is a save dialog.}
+\twocolitem{{\bf wxHIDE\_READONLY}}{Hide read-only files.}
+\twocolitem{{\bf wxOVERWRITE\_PROMPT}}{Prompt for a conformation if a file will be overridden.}
\end{twocollist}%
}
\twocolitem{{\bf wxYES\_NO}}{Show Yes and No buttons.}
\twocolitem{{\bf wx\_NO\_DEFAULT}}{Used with {\bf wxYES\_NO}, makes {\bf No} button the default.}
\twocolitem{{\bf wxCENTRE}}{Centre the message. Not Windows.}
-\twocolitem{{\bf wxICON\_EXCLAMATION}}{Shows an exclamation mark icon. Windows only.}
-\twocolitem{{\bf wxICON\_HAND}}{Shows a hand icon. Windows only.}
-\twocolitem{{\bf wxICON\_QUESTION}}{Shows a question mark icon. Windows only.}
-\twocolitem{{\bf wxICON\_INFORMATION}}{Shows an information (i) icon. Windows only.}
+\twocolitem{{\bf wxICON\_EXCLAMATION}}{Shows an exclamation mark icon.}
+\twocolitem{{\bf wxICON\_HAND}}{Shows a hand icon.}
+\twocolitem{{\bf wxICON\_QUESTION}}{Shows a question mark icon.}
+\twocolitem{{\bf wxICON\_INFORMATION}}{Shows an information (i) icon.}
\end{twocollist}
}
\section{\class{wxZlibOutputStream}}\label{wxzliboutputstream}
This stream compresses all data written to it, and passes the compressed data
-to the ``filtered'' stream.
+to the "filtered" stream.
\wxheading{Derived from}
\helpref{wxTextDropTarget}{wxtextdroptarget},
\helpref{wxFileDropTarget}{wxfiledroptarget}
-It has to be noted that the API for drag and drop in wxWindows is not
-yet finished which is mostly due to the fact that DnD support under
-GTK 1.0 is very rudimentary and entirely different from the XDnD
-protocol used by GTK 1.2. This also entails that not all of the documentation
-concerning DnD might be correct and some of the code might get broken
-in the future. The next release of wxWindows will be based on GTK 1.2
-and will hopefully include a much improved DnD support. The general
-design on the wxDropSource side will be the same but especially the
-wxDropTarget is almost certain to change.
-
Note that wxUSE\_DRAG\_AND\_DROP must be defined in setup.h in order
to use Drag'n'Drop in wxWindows.
\item {\bf Dragging:} The call to DoDragDrop() blocks until the user release the
mouse button (unless you override \helpref{GiveFeedback}{wxdropsourcegivefeedback} function
to do something special). When the mouse moves in a window of a program which understands the
-same drag-and-drop protocol (any program under Windows or any program supporting GTK 1.0
-DnD protocol under X Windows), the corresponding \helpref{wxDropTarget}{wxdroptarget} methods
+same drag-and-drop protocol (any program under Windows or any program supporting the
+XDnD protocol under X Windows), the corresponding \helpref{wxDropTarget}{wxdroptarget} methods
are called - see below.
\item {\bf Processing the result:} DoDragDrop() returns an {\it effect code} which
is one of the values of \helpref{wxDragResult}{wxdropsource} enum. Codes
\helpref{wxFileDropTarget}{wxfiledroptarget} and override their OnDropText()
or OnDropFiles() method.
\item {\bf Drop:} When the user releases the mouse over a window, wxWindows
-queries the associated wxDropTarget object if it accepts the data. For
-this, \helpref{GetFormatCount}{wxdroptargetgetformatcount} and \helpref{GetFormat}{wxdroptargetgetformat} are
-used and if the format is
-supported (i.e. is one of returned by GetFormat()),
-then \helpref{OnDrop}{wxdroptargetondrop} is called.
-Otherwise, wxDragNone is returned by DoDragDrop() and
-nothing happens.
+queries the associated wxDropTarget object if it accepts the data. For this,
+a \helpref{wxDataObject}{wxdataobject} must be associated with the drop target
+and this data object will be responsible for the format negotiation between
+the drag source and the drop target. If all goes well, then \helpref{OnData}{wxdroptargetondata}
+will get called and the wxDataObject belonging to the drop target can get
+filled with data.
\item {\bf The end:} After processing the data, DoDragDrop() returns either
wxDragCopy or wxDragMove depending on the state of the keys (<Ctrl>, <Shift>
and <Alt>) at the moment of drop. There is currently no way for the drop
In wxWindows, the code fragment froim above should be written instead:
\begin{verbatim}
- wxChar ch = T('*');
- wxString s = T("Hello, world!");
+ wxChar ch = wxT('*');
+ wxString s = wxT("Hello, world!");
int len = s.Len();
\end{verbatim}
We have a {\tt wxChar} type which maps either on {\tt char} or {\tt wchar\_t}
depending on the mode in which program is being compiled. There is no need for
a separate type for strings though, because the standard
-\helpref{wxString}{wxstring} supports Unicode, i.e. it stores iether ANSI or
-Unicode strings depending on the mode.
+\helpref{wxString}{wxstring} supports Unicode, i.e. it stores either ANSI or
+Unicode strings depending on the compile mode.
-Finally, there is a special {\tt T()} macro which should enclose all literal
+Finally, there is a special {\tt wxT()} macro which should enclose all literal
strings in the program. As it's easy to see comparing the last fragment with
the one above, this macro expands to nothing in the (usual) ANSI mode and
prefixes {\tt 'L'} to its argument in the Unicode mode.
The important conclusion is that if you use {\tt wxChar} instead of
{\tt char}, avoid using C style strings and use {\tt wxString} instead and
-don't forget to enclose all string literals inside {\tt T()} macro, your
+don't forget to enclose all string literals inside {\tt wxT()} macro, your
program automatically becomes (almost) Unicode compliant!
Just let us state once again the rules:
\begin{itemize}
\item Always use {\tt wxChar} instead of {\tt char}
-\item Always enclose literal string constants in {\tt T()} macro unless
+\item Always enclose literal string constants in {\tt wxT()} macro unless
they're already converted to the right representation (another standard
-wxWindows macro {\tt \_()} does it, so there is no need for {\tt T()} in this
+wxWindows macro {\tt \_()} does it, so there is no need for {\tt wxT()} in this
case) or you intend to pass the constant directly to an external function
which doesn't accept wide-character strings.
\item Use {\tt wxString} instead of C style strings.
projects / wxWidgets.git / commitdiff
