Minor doc updates.

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@4359 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Robert Roebling 1999-11-04 17:49:21 +00:00
parent 678b92a94a
commit 330d6fd063
6 changed files with 28 additions and 44 deletions

View File

@ -19,7 +19,7 @@ For example:
{
// 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();
}

View File

@ -26,17 +26,12 @@ If path is ``", the current directory will be used. If filename is ``",
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}
@ -69,10 +64,10 @@ Constructor. Use \helpref{wxFileDialog::ShowModal}{wxfiledialogshowmodal} to sho
\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}%
}

View File

@ -45,10 +45,10 @@ Constructor. Use \helpref{wxMessageDialog::ShowModal}{wxmessagedialogshowmodal}
\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}
}

View File

@ -24,7 +24,7 @@ stream to get new compressed data.
\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}

View File

@ -7,16 +7,6 @@ Classes: \helpref{wxDataObject}{wxdataobject},
\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.
@ -55,8 +45,8 @@ of wxDropSource object which should be constructed like this:
\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
@ -82,13 +72,12 @@ derive from \helpref{wxTextDropTarget}{wxtextdroptarget} or
\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

View File

@ -99,8 +99,8 @@ section.
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}
@ -112,26 +112,26 @@ compilation in the program itself.
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.