Removed lots of OnClose functions; doc'ed OnCloseWindow better;

MM_... -> wxMM_...


git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@1615 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
This commit is contained in:
Julian Smart
1999-02-05 23:55:04 +00:00
parent cd743a6f71
commit e306597309
130 changed files with 533 additions and 659 deletions

View File

@@ -148,7 +148,7 @@ same API;
temporarily with the window as an argument;
\item events from sliders and scrollbars can be handled more flexibly;
\item the handling of window close events has been changed in line with the new
event system, but backward {\bf OnClose} compatibility has been retained;
event system;
\item the concept of {\it validator} has been added to allow much easier coding of
the relationship between controls and application data;
\item the documentation has been revised, with more cross-referencing.

View File

@@ -644,12 +644,12 @@ PostScript output.
The mapping mode can be one of the following:
\begin{twocollist}\itemsep=0pt
\twocolitem{MM\_TWIPS}{Each logical unit is 1/20 of a point, or 1/1440 of
\twocolitem{wxMM\_TWIPS}{Each logical unit is 1/20 of a point, or 1/1440 of
an inch.}
\twocolitem{MM\_POINTS}{Each logical unit is a point, or 1/72 of an inch.}
\twocolitem{MM\_METRIC}{Each logical unit is 1 mm.}
\twocolitem{MM\_LOMETRIC}{Each logical unit is 1/10 of a mm.}
\twocolitem{MM\_TEXT}{Each logical unit is 1 pixel.}
\twocolitem{wxMM\_POINTS}{Each logical unit is a point, or 1/72 of an inch.}
\twocolitem{wxMM\_METRIC}{Each logical unit is 1 mm.}
\twocolitem{wxMM\_LOMETRIC}{Each logical unit is 1/10 of a mm.}
\twocolitem{wxMM\_TEXT}{Each logical unit is 1 pixel.}
\end{twocollist}
\membersection{wxDC::SetOptimization}\label{wxsetoptimization}

View File

@@ -463,7 +463,7 @@ the equivalent of the following code to the start of the metafile data:
SetWindowExt(dc, maxX - minX, maxY - minY);
\end{verbatim}
This simulates the MM\_TEXT mapping mode, which wxWindows assumes.
This simulates the wxMM\_TEXT mapping mode, which wxWindows assumes.
Placeable metafiles may be imported by many Windows applications, and can be
used in RTF (Rich Text Format) files.

View File

@@ -167,9 +167,9 @@ in the application.
This function should be called by the application prior to
showing the frame.
\membersection{wxPreviewFrame::OnClose}
\membersection{wxPreviewFrame::OnCloseWindow}
\func{bool}{OnClose}{\void}
\func{void}{OnCloseWindow}{\param{wxCloseEvent\&}{ event}}
Enables the other frames in the application, and deletes the print preview
object, implicitly deleting any printout objects associated with the print

View File

@@ -9,15 +9,18 @@ to close windows.
\wxheading{What is the sequence of events in a window deletion?}
When the user clicks on the system close button or system close command,
in a frame or a dialog, wxWindows calls \helpref{wxWindow::Close}{wxwindowclose}.
in a frame or a dialog, wxWindows calls \helpref{wxWindow::Close}{wxwindowclose}. This
in turn generates an EVT\_CLOSE event: see \helpref{wxWindow::OnCloseWindow}{wxwindowonclosewindow}.
This function then generates a \helpref{wxCloseEvent}{wxcloseevent} event which
can be handled by the application (by using an EVT\_CLOSE event table entry). It is the duty of the application to
define a suitable event handler, and decide whether or not to destroy the window.
If the application is for some reason forcing the application to close,
the window should always be destroyed, otherwise there is the option to
It is the duty of the application to define a suitable event handler, and
decide whether or not to destroy the window.
If the application is for some reason forcing the application to close
(\helpref{wxCloseEvent::CanVeto}{wxcloseeventcanveto} returns FALSE), the window should always be destroyed, otherwise there is the option to
ignore the request, or maybe wait until the user has answered a question
before deciding whether it's safe to close.
before deciding whether it's safe to close. The handler for EVT\_CLOSE should
signal to the calling code if it does not destroy the window, by calling
\helpref{wxCloseEvent::Veto}{wxcloseeventveto}. Calling this provides useful information
to the calling code.
The wxCloseEvent handler should only call \helpref{wxWindow::Destroy}{wxwindowdestroy} to
delete the window, and not use the {\bf delete} operator. This is because
@@ -26,24 +29,28 @@ since otherwise there is the danger that events will be sent to a non-existent w
\wxheading{How can the application close a window itself?}
Your application can use the \helpref{wxWindow::Close}{wxwindowclose} event just as
the framework does. Pass a TRUE argument to this function to tell the event handler
that we definitely want to delete the frame.
Your application can either use \helpref{wxWindow::Close}{wxwindowclose} event just as
the framework does, or it can call \helpref{wxWindow::Destroy}{wxwindowdestroy} directly.
If using Close(), you can pass a TRUE argument to this function to tell the event handler
that we definitely want to delete the frame and it cannot be vetoed.
If for some reason you don't wish to use the {\bf Close} function to delete a window, at least use
the {\bf Destroy} function so that wxWindows can decide when it's safe to delete the window.
The advantage of using Close instead of Destroy is that it will call any clean-up code
defined by the EVT\_CLOSE handler; for example it may close a document contained in
a window after first asking the user whether the work should be saved. Close can be vetoed
by this process (return FALSE), whereas Destroy definitely destroys the window.
\wxheading{What is the default behaviour?}
By default, the close event handlers for wxFrame and wxDialog
both call the old \helpref{wxWindow::OnClose}{wxwindowonclose} handler
for backward compatibility. So you can still use the old form if you wish.
In addition, the default close event handler for wxDialog simulates a Cancel command,
The default close event handler for wxDialog simulates a Cancel command,
generating a wxID\_CANCEL event. Since the handler for this cancel event might
itself call {\bf Close}, there is a check for infinite looping.
itself call {\bf Close}, there is a check for infinite looping. The default handler
for wxID\_CANCEL hides the dialog (if modeless) or calls EndModal(wxID\_CANCEL) (if modal).
In other words, by default, the dialog is not destroyed (it might have been created
on the stack, so the assumption of dynamic creation cannot be made).
Under Windows, wxDialog also defines a handler for \helpref{wxWindow::OnCharHook}{wxwindowoncharhook} that
The default close event handler for wxFrame destroys the frame using Destroy().
Under Windows, wxDialog defines a handler for \helpref{wxWindow::OnCharHook}{wxwindowoncharhook} that
generates a Cancel event if the Escape key has been pressed.
\wxheading{What should I do when the user calls up Exit from a menu?}
@@ -63,9 +70,6 @@ In wxWindows 1.xx, the {\bf OnClose} function did not actually delete 'this', bu
to the calling function (either {\bf Close}, or the wxWindows framework) to delete
or not delete the window.
You can still use this function unchanged in 2.0, but it's worth upgrading to
the new method in case future versions of wxWindows does not support the old one.
To update your code, you should provide an event table entry in your frame or
dialog, using the EVT\_CLOSE macro. The event handler function might look like this:
@@ -73,22 +77,13 @@ dialog, using the EVT\_CLOSE macro. The event handler function might look like t
\begin{verbatim}
void MyFrame::OnCloseWindow(wxCloseEvent& event)
{
// If the application forces the deletion,
// obey without question.
if (event.GetForce())
{
this->Destroy();
return;
}
// Otherwise...
if (MyDataHasBeenModified())
{
wxMessageDialog* dialog = new wxMessageDialog(this,
"Save changed data?", "My app", wxYES_NO|wxCANCEL);
int ans = dialog->ShowModal();
dialog->Close(TRUE);
dialog->Destroy();
switch (ans)
{
@@ -101,6 +96,10 @@ dialog, using the EVT\_CLOSE macro. The event handler function might look like t
break;
case wxID_CANCEL: // Do nothing - so don't quit app.
default:
if (!event.CanVeto()) // Test if we can veto this deletion
this->Destroy(); // If not, destroy the window anyway.
else
event.Veto(); // Notify the calling code that we didn't delete the frame.
break;
}
}
@@ -111,7 +110,8 @@ dialog, using the EVT\_CLOSE macro. The event handler function might look like t
\wxheading{How do I exit the application gracefully?}
A wxWindows application automatically exits when the designated top window, or the
last frame or dialog, is destroyed.
last frame or dialog, is destroyed. Put any application-wide cleanup code in \helpref{wxApp::OnExit}{wxapponexit} (this
is a virtual function, not an event handler).
\wxheading{Do child windows get deleted automatically?}

View File

@@ -27,7 +27,7 @@ or if allowing the user to specify a face name, store the family id with any fil
might be transported to a different Windows machine or other platform.
\normalbox{{\bf Note:} There is currently a difference between the appearance of fonts on the
two platforms, if the mapping mode is anything other than MM\_TEXT.
two platforms, if the mapping mode is anything other than wxMM\_TEXT.
Under X, font size is always specified in points. Under MS Windows, the
unit for text is points but the text is scaled according to the
current mapping mode. However, user scaling on a device context will

View File

@@ -898,7 +898,7 @@ the control(s) in question.
Called when the user has tried to close a a frame
or dialog box using the window manager (X) or system menu (Windows).
{\bf Note:} This is an obsolete function retained for backward compatibility.
{\bf Note:} This is an obsolete function.
It is superceded by the \helpref{wxWindow::OnCloseWindow}{wxwindowonclosewindow} event
handler.
@@ -908,10 +908,6 @@ If TRUE is returned by OnClose, the window will be deleted by the system, otherw
attempt will be ignored. Do not delete the window from within this handler, although
you may delete other windows.
\wxheading{Remarks}
Derive your own class to handle this message. The default handler returns TRUE.
\wxheading{See also}
\helpref{Window deletion overview}{windowdeletionoverview},\rtfsp

View File

@@ -296,3 +296,7 @@ General Notes
and it's also on the wxWindows CD-ROM under Packages.
- If you are installing wxWindows 2 from CVS, you may find that
include/wx/msw/setup.h is missing. This is deliberate, to avoid
developers' different setup.h configurations getting confused.
Please copy setup0.h to setup.h before compiling.