]>
Commit | Line | Data |
---|---|---|
1 | \section{\class{wxApp}}\label{wxapp} | |
2 | ||
3 | The {\bf wxApp} class represents the application itself. It is used | |
4 | to: | |
5 | ||
6 | \begin{itemize}\itemsep=0pt | |
7 | \item set and get application-wide properties; | |
8 | \item implement the windowing system message or event loop; | |
9 | \item initiate application processing via \helpref{wxApp::OnInit}{wxapponinit}; | |
10 | \item allow default processing of events not handled by other | |
11 | objects in the application. | |
12 | \end{itemize} | |
13 | ||
14 | You should use the macro IMPLEMENT\_APP(appClass) in your application implementation | |
15 | file to tell wxWidgets how to create an instance of your application class. | |
16 | ||
17 | Use DECLARE\_APP(appClass) in a header file if you want the wxGetApp function (which returns | |
18 | a reference to your application object) to be visible to other files. | |
19 | ||
20 | \wxheading{Derived from} | |
21 | ||
22 | \helpref{wxEvtHandler}{wxevthandler}\\ | |
23 | \helpref{wxObject}{wxobject} | |
24 | ||
25 | \wxheading{Include files} | |
26 | ||
27 | <wx/app.h> | |
28 | ||
29 | \wxheading{See also} | |
30 | ||
31 | \helpref{wxApp overview}{wxappoverview} | |
32 | ||
33 | \latexignore{\rtfignore{\wxheading{Members}}} | |
34 | ||
35 | ||
36 | \membersection{wxApp::wxApp}\label{wxappctor} | |
37 | ||
38 | \func{}{wxApp}{\void} | |
39 | ||
40 | Constructor. Called implicitly with a definition of a wxApp object. | |
41 | ||
42 | ||
43 | \membersection{wxApp::\destruct{wxApp}}\label{wxappdtor} | |
44 | ||
45 | \func{virtual}{\destruct{wxApp}}{\void} | |
46 | ||
47 | Destructor. Will be called implicitly on program exit if the wxApp | |
48 | object is created on the stack. | |
49 | ||
50 | ||
51 | \membersection{wxApp::argc}\label{wxappargc} | |
52 | ||
53 | \member{int}{argc} | |
54 | ||
55 | Number of command line arguments (after environment-specific processing). | |
56 | ||
57 | ||
58 | \membersection{wxApp::argv}\label{wxappargv} | |
59 | ||
60 | \member{wxChar **}{argv} | |
61 | ||
62 | Command line arguments (after environment-specific processing). | |
63 | ||
64 | ||
65 | \membersection{wxApp::CreateLogTarget}\label{wxappcreatelogtarget} | |
66 | ||
67 | \func{virtual wxLog*}{CreateLogTarget}{\void} | |
68 | ||
69 | Creates a wxLog class for the application to use for logging errors. The default | |
70 | implementation returns a new wxLogGui class. | |
71 | ||
72 | \wxheading{See also} | |
73 | ||
74 | \helpref{wxLog}{wxlog} | |
75 | ||
76 | ||
77 | \membersection{wxApp::CreateTraits}\label{wxappcreatetraits} | |
78 | ||
79 | \func{virtual wxAppTraits *}{CreateTraits}{\void} | |
80 | ||
81 | Creates the \helpref{wxAppTraits}{wxapptraits} object when \helpref{GetTraits}{wxappgettraits} | |
82 | needs it for the first time. | |
83 | ||
84 | \wxheading{See also} | |
85 | ||
86 | \helpref{wxAppTraits}{wxapptraits} | |
87 | ||
88 | ||
89 | \membersection{wxApp::Dispatch}\label{wxappdispatch} | |
90 | ||
91 | \func{virtual void}{Dispatch}{\void} | |
92 | ||
93 | Dispatches the next event in the windowing system event queue. | |
94 | ||
95 | This can be used for programming event loops, e.g. | |
96 | ||
97 | \begin{verbatim} | |
98 | while (app.Pending()) | |
99 | Dispatch(); | |
100 | \end{verbatim} | |
101 | ||
102 | \wxheading{See also} | |
103 | ||
104 | \helpref{wxApp::Pending}{wxapppending} | |
105 | ||
106 | ||
107 | \membersection{wxApp::ExitMainLoop}\label{wxappexitmainloop} | |
108 | ||
109 | \func{virtual void}{ExitMainLoop}{\void} | |
110 | ||
111 | Call this to explicitly exit the main message (event) loop. | |
112 | You should normally exit the main loop (and the application) by deleting | |
113 | the top window. | |
114 | ||
115 | ||
116 | \membersection{wxApp::FilterEvent}\label{wxappfilterevent} | |
117 | ||
118 | \func{int}{FilterEvent}{\param{wxEvent\& }{event}} | |
119 | ||
120 | This function is called before processing any event and allows the application | |
121 | to preempt the processing of some events. If this method returns $-1$ the event | |
122 | is processed normally, otherwise either {\tt true} or {\tt false} should be | |
123 | returned and the event processing stops immediately considering that the event | |
124 | had been already processed (for the former return value) or that it is not | |
125 | going to be processed at all (for the latter one). | |
126 | ||
127 | ||
128 | \membersection{wxApp::GetAppName}\label{wxappgetappname} | |
129 | ||
130 | \constfunc{wxString}{GetAppName}{\void} | |
131 | ||
132 | Returns the application name. | |
133 | ||
134 | \wxheading{Remarks} | |
135 | ||
136 | wxWidgets sets this to a reasonable default before | |
137 | calling \helpref{wxApp::OnInit}{wxapponinit}, but the application can reset it at will. | |
138 | ||
139 | ||
140 | \membersection{wxApp::GetClassName}\label{wxappgetclassname} | |
141 | ||
142 | \constfunc{wxString}{GetClassName}{\void} | |
143 | ||
144 | Gets the class name of the application. The class name may be used in a platform specific | |
145 | manner to refer to the application. | |
146 | ||
147 | \wxheading{See also} | |
148 | ||
149 | \helpref{wxApp::SetClassName}{wxappsetclassname} | |
150 | ||
151 | ||
152 | \membersection{wxApp::GetExitOnFrameDelete}\label{wxappgetexitonframedelete} | |
153 | ||
154 | \constfunc{bool}{GetExitOnFrameDelete}{\void} | |
155 | ||
156 | Returns true if the application will exit when the top-level window is deleted, false | |
157 | otherwise. | |
158 | ||
159 | \wxheading{See also} | |
160 | ||
161 | \helpref{wxApp::SetExitOnFrameDelete}{wxappsetexitonframedelete},\\ | |
162 | \helpref{wxApp shutdown overview}{wxappshutdownoverview} | |
163 | ||
164 | ||
165 | \membersection{wxApp::GetInstance}\label{wxappgetinstance} | |
166 | ||
167 | \func{static wxAppConsole *}{GetInstance}{\void} | |
168 | ||
169 | Returns the one and only global application object. | |
170 | Usually \texttt{wxTheApp} is usead instead. | |
171 | ||
172 | \wxheading{See also} | |
173 | ||
174 | \helpref{wxApp::SetInstance}{wxappsetinstance} | |
175 | ||
176 | ||
177 | \membersection{wxApp::GetTopWindow}\label{wxappgettopwindow} | |
178 | ||
179 | \constfunc{virtual wxWindow *}{GetTopWindow}{\void} | |
180 | ||
181 | Returns a pointer to the top window. | |
182 | ||
183 | \wxheading{Remarks} | |
184 | ||
185 | If the top window hasn't been set using \helpref{wxApp::SetTopWindow}{wxappsettopwindow}, this | |
186 | function will find the first top-level window (frame or dialog) and return that. | |
187 | ||
188 | \wxheading{See also} | |
189 | ||
190 | \helpref{SetTopWindow}{wxappsettopwindow} | |
191 | ||
192 | ||
193 | ||
194 | \membersection{wxApp::GetTraits}\label{wxappgettraits} | |
195 | ||
196 | \func{wxAppTraits *}{GetTraits}{\void} | |
197 | ||
198 | Returns a pointer to the \helpref{wxAppTraits}{wxapptraits} object for the application. | |
199 | If you want to customize the \helpref{wxAppTraits}{wxapptraits} object, you must override the | |
200 | \helpref{CreateTraits}{wxappcreatetraits} function. | |
201 | ||
202 | ||
203 | ||
204 | \membersection{wxApp::GetUseBestVisual}\label{wxappgetusebestvisual} | |
205 | ||
206 | \constfunc{bool}{GetUseBestVisual}{\void} | |
207 | ||
208 | Returns true if the application will use the best visual on systems that support | |
209 | different visuals, false otherwise. | |
210 | ||
211 | \wxheading{See also} | |
212 | ||
213 | \helpref{SetUseBestVisual}{wxappsetusebestvisual} | |
214 | ||
215 | ||
216 | \membersection{wxApp::GetVendorName}\label{wxappgetvendorname} | |
217 | ||
218 | \constfunc{wxString}{GetVendorName}{\void} | |
219 | ||
220 | Returns the application's vendor name. | |
221 | ||
222 | ||
223 | \membersection{wxApp::IsActive}\label{wxappisactive} | |
224 | ||
225 | \constfunc{bool}{IsActive}{\void} | |
226 | ||
227 | Returns \true if the application is active, i.e. if one of its windows is | |
228 | currently in the foreground. If this function returns \false and you need to | |
229 | attract users attention to the application, you may use | |
230 | \helpref{wxTopLevelWindow::RequestUserAttention}{wxtoplevelwindowrequestuserattention} | |
231 | to do it. | |
232 | ||
233 | ||
234 | \membersection{wxApp::IsMainLoopRunning}\label{wxappismainlooprunning} | |
235 | ||
236 | \func{static bool}{IsMainLoopRunning}{\void} | |
237 | ||
238 | Returns \true if the main event loop is currently running, i.e. if the | |
239 | application is inside \helpref{OnRun}{wxapponrun}. | |
240 | ||
241 | This can be useful to test whether events can be dispatched. For example, | |
242 | if this function returns \false, non-blocking sockets cannot be used because | |
243 | the events from them would never be processed. | |
244 | ||
245 | ||
246 | \membersection{wxApp::MainLoop}\label{wxappmainloop} | |
247 | ||
248 | \func{virtual int}{MainLoop}{\void} | |
249 | ||
250 | Called by wxWidgets on creation of the application. Override this if you wish | |
251 | to provide your own (environment-dependent) main loop. | |
252 | ||
253 | \wxheading{Return value} | |
254 | ||
255 | Returns 0 under X, and the wParam of the WM\_QUIT message under Windows. | |
256 | ||
257 | %% VZ: OnXXX() functions should *not* be documented | |
258 | %% | |
259 | %%\membersection{wxApp::OnActivate}\label{wxapponactivate} | |
260 | %% | |
261 | %%\func{void}{OnActivate}{\param{wxActivateEvent\& }{event}} | |
262 | %% | |
263 | %%Provide this member function to know whether the application is being | |
264 | %%activated or deactivated (Windows only). | |
265 | %% | |
266 | %%\wxheading{See also} | |
267 | %% | |
268 | %%\helpref{wxWindow::OnActivate}{wxwindowonactivate}, \helpref{wxActivateEvent}{wxactivateevent} | |
269 | %% | |
270 | %%\membersection{wxApp::OnCharHook}\label{wxapponcharhook} | |
271 | %% | |
272 | %%\func{void}{OnCharHook}{\param{wxKeyEvent\&}{ event}} | |
273 | %% | |
274 | %%This event handler function is called (under Windows only) to allow the window to intercept keyboard events | |
275 | %%before they are processed by child windows. | |
276 | %% | |
277 | %%\wxheading{Parameters} | |
278 | %% | |
279 | %%\docparam{event}{The keypress event.} | |
280 | %% | |
281 | %%\wxheading{Remarks} | |
282 | %% | |
283 | %%Use the wxEVT\_CHAR\_HOOK macro in your event table. | |
284 | %% | |
285 | %%If you use this member, you can selectively consume keypress events by calling\rtfsp | |
286 | %%\helpref{wxEvent::Skip}{wxeventskip} for characters the application is not interested in. | |
287 | %% | |
288 | %%\wxheading{See also} | |
289 | %% | |
290 | %%\helpref{wxKeyEvent}{wxkeyevent}, \helpref{wxWindow::OnChar}{wxwindowonchar},\rtfsp | |
291 | %%\helpref{wxWindow::OnCharHook}{wxwindowoncharhook}, \helpref{wxDialog::OnCharHook}{wxdialogoncharhook} | |
292 | ||
293 | ||
294 | \membersection{wxApp::OnAssertFailure}\label{wxapponassertfailure} | |
295 | ||
296 | \func{void}{OnAssertFailure}{\param{const wxChar }{*file}, \param{int }{line}, \param{const wxChar }{*func}, \param{const wxChar }{*cond}, \param{const wxChar }{*msg}} | |
297 | ||
298 | This function is called when an assert failure occurs, i.e. the condition | |
299 | specified in \helpref{wxASSERT}{wxassert} macro evaluated to {\tt false}. | |
300 | It is only called in debug mode (when {\tt \_\_WXDEBUG\_\_} is defined) as | |
301 | asserts are not left in the release code at all. | |
302 | ||
303 | The base class version shows the default assert failure dialog box proposing to | |
304 | the user to stop the program, continue or ignore all subsequent asserts. | |
305 | ||
306 | \wxheading{Parameters} | |
307 | ||
308 | \docparam{file}{the name of the source file where the assert occurred} | |
309 | ||
310 | \docparam{line}{the line number in this file where the assert occurred} | |
311 | ||
312 | \docparam{func}{the name of the function where the assert occurred, may be | |
313 | empty if the compiler doesn't support C99 \texttt{\_\_FUNCTION\_\_}} | |
314 | ||
315 | \docparam{cond}{the condition of the failed assert in text form} | |
316 | ||
317 | \docparam{msg}{the message specified as argument to | |
318 | \helpref{wxASSERT\_MSG}{wxassertmsg} or \helpref{wxFAIL\_MSG}{wxfailmsg}, will | |
319 | be {\tt NULL} if just \helpref{wxASSERT}{wxassert} or \helpref{wxFAIL}{wxfail} | |
320 | was used} | |
321 | ||
322 | ||
323 | \membersection{wxApp::OnCmdLineError}\label{wxapponcmdlineerror} | |
324 | ||
325 | \func{bool}{OnCmdLineError}{\param{wxCmdLineParser\& }{parser}} | |
326 | ||
327 | Called when command line parsing fails (i.e. an incorrect command line option | |
328 | was specified by the user). The default behaviour is to show the program usage | |
329 | text and abort the program. | |
330 | ||
331 | Return {\tt true} to continue normal execution or {\tt false} to return | |
332 | {\tt false} from \helpref{OnInit}{wxapponinit} thus terminating the program. | |
333 | ||
334 | \wxheading{See also} | |
335 | ||
336 | \helpref{OnInitCmdLine}{wxapponinitcmdline} | |
337 | ||
338 | ||
339 | \membersection{wxApp::OnCmdLineHelp}\label{wxapponcmdlinehelp} | |
340 | ||
341 | \func{bool}{OnCmdLineHelp}{\param{wxCmdLineParser\& }{parser}} | |
342 | ||
343 | Called when the help option ({\tt --help}) was specified on the command line. | |
344 | The default behaviour is to show the program usage text and abort the program. | |
345 | ||
346 | Return {\tt true} to continue normal execution or {\tt false} to return | |
347 | {\tt false} from \helpref{OnInit}{wxapponinit} thus terminating the program. | |
348 | ||
349 | \wxheading{See also} | |
350 | ||
351 | \helpref{OnInitCmdLine}{wxapponinitcmdline} | |
352 | ||
353 | ||
354 | \membersection{wxApp::OnCmdLineParsed}\label{wxapponcmdlineparsed} | |
355 | ||
356 | \func{bool}{OnCmdLineParsed}{\param{wxCmdLineParser\& }{parser}} | |
357 | ||
358 | Called after the command line had been successfully parsed. You may override | |
359 | this method to test for the values of the various parameters which could be | |
360 | set from the command line. | |
361 | ||
362 | Don't forget to call the base class version unless you want to suppress | |
363 | processing of the standard command line options. | |
364 | ||
365 | Return {\tt true} to continue normal execution or {\tt false} to return | |
366 | {\tt false} from \helpref{OnInit}{wxapponinit} thus terminating the program. | |
367 | ||
368 | \wxheading{See also} | |
369 | ||
370 | \helpref{OnInitCmdLine}{wxapponinitcmdline} | |
371 | ||
372 | ||
373 | \membersection{wxApp::OnExceptionInMainLoop}\label{wxapponexceptioninmainloop} | |
374 | ||
375 | \func{virtual bool}{OnExceptionInMainLoop}{\void} | |
376 | ||
377 | This function is called if an unhandled exception occurs inside the main | |
378 | application event loop. It can return \true to ignore the exception and to | |
379 | continue running the loop or \false to exit the loop and terminate the | |
380 | program. In the latter case it can also use C++ \texttt{throw} keyword to | |
381 | rethrow the current exception. | |
382 | ||
383 | The default behaviour of this function is the latter in all ports except under | |
384 | Windows where a dialog is shown to the user which allows him to choose between | |
385 | the different options. You may override this function in your class to do | |
386 | something more appropriate. | |
387 | ||
388 | Finally note that if the exception is rethrown from here, it can be caught in | |
389 | \helpref{OnUnhandledException}{wxapponunhandledexception}. | |
390 | ||
391 | ||
392 | \membersection{wxApp::OnExit}\label{wxapponexit} | |
393 | ||
394 | \func{virtual int}{OnExit}{\void} | |
395 | ||
396 | Override this member function for any processing which needs to be | |
397 | done as the application is about to exit. OnExit is called after | |
398 | destroying all application windows and controls, but before | |
399 | wxWidgets cleanup. Note that it is not called at all if | |
400 | \helpref{OnInit}{wxapponinit} failed. | |
401 | ||
402 | The return value of this function is currently ignored, return the same value | |
403 | as returned by the base class method if you override it. | |
404 | ||
405 | ||
406 | \membersection{wxApp::OnFatalException}\label{wxapponfatalexception} | |
407 | ||
408 | \func{void}{OnFatalException}{\void} | |
409 | ||
410 | This function may be called if something fatal happens: an unhandled | |
411 | exception under Win32 or a a fatal signal under Unix, for example. However, | |
412 | this will not happen by default: you have to explicitly call | |
413 | \helpref{wxHandleFatalExceptions}{wxhandlefatalexceptions} to enable this. | |
414 | ||
415 | Generally speaking, this function should only show a message to the user and | |
416 | return. You may attempt to save unsaved data but this is not guaranteed to | |
417 | work and, in fact, probably won't. | |
418 | ||
419 | \wxheading{See also} | |
420 | ||
421 | \helpref{wxHandleFatalExceptions}{wxhandlefatalexceptions} | |
422 | ||
423 | %% VZ: the wxApp event handler are private and should not be documented here! | |
424 | %% | |
425 | %%\membersection{wxApp::OnIdle}\label{wxapponidle} | |
426 | %% | |
427 | %%\func{void}{OnIdle}{\param{wxIdleEvent\& }{event}} | |
428 | %% | |
429 | %%Override this member function for any processing which needs to be done | |
430 | %%when the application is idle. You should call wxApp::OnIdle from your own function, | |
431 | %%since this forwards OnIdle events to windows and also performs garbage collection for | |
432 | %%windows whose destruction has been delayed. | |
433 | %% | |
434 | %%wxWidgets' strategy for OnIdle processing is as follows. After pending user interface events for an | |
435 | %%application have all been processed, wxWidgets sends an OnIdle event to the application object. wxApp::OnIdle itself | |
436 | %%sends an OnIdle event to each application window, allowing windows to do idle processing such as updating | |
437 | %%their appearance. If either wxApp::OnIdle or a window OnIdle function requested more time, by | |
438 | %%calling \helpref{wxIdleEvent::RequestMore}{wxidleeventrequestmore}, wxWidgets will send another OnIdle | |
439 | %%event to the application object. This will occur in a loop until either a user event is found to be | |
440 | %%pending, or OnIdle requests no more time. Then all pending user events are processed until the system | |
441 | %%goes idle again, when OnIdle is called, and so on. | |
442 | %% | |
443 | %%\wxheading{See also} | |
444 | %% | |
445 | %%\helpref{wxWindow::OnIdle}{wxwindowonidle}, \helpref{wxIdleEvent}{wxidleevent},\rtfsp | |
446 | %%\helpref{wxWindow::SendIdleEvents}{wxappsendidleevents} | |
447 | %% | |
448 | %%\membersection{wxApp::OnEndSession}\label{wxapponendsession} | |
449 | %% | |
450 | %%\func{void}{OnEndSession}{\param{wxCloseEvent\& }{event}} | |
451 | %% | |
452 | %%This is an event handler function called when the operating system or GUI session is | |
453 | %%about to close down. The application has a chance to silently save information, | |
454 | %%and can optionally close itself. | |
455 | %% | |
456 | %%Use the EVT\_END\_SESSION event table macro to handle query end session events. | |
457 | %% | |
458 | %%The default handler calls \helpref{wxWindow::Close}{wxwindowclose} with a true argument | |
459 | %%(forcing the application to close itself silently). | |
460 | %% | |
461 | %%\wxheading{Remarks} | |
462 | %% | |
463 | %%Under X, OnEndSession is called in response to the `die' event. | |
464 | %% | |
465 | %%Under Windows, OnEndSession is called in response to the WM\_ENDSESSION message. | |
466 | %% | |
467 | %%\wxheading{See also} | |
468 | %% | |
469 | %%\helpref{wxWindow::Close}{wxwindowclose},\rtfsp | |
470 | %%\helpref{wxWindow::OnCloseWindow}{wxwindowonclosewindow},\rtfsp | |
471 | %%\helpref{wxCloseEvent}{wxcloseevent},\rtfsp | |
472 | ||
473 | ||
474 | \membersection{wxApp::OnInit}\label{wxapponinit} | |
475 | ||
476 | \func{bool}{OnInit}{\void} | |
477 | ||
478 | This must be provided by the application, and will usually create the | |
479 | application's main window, optionally calling | |
480 | \helpref{wxApp::SetTopWindow}{wxappsettopwindow}. You may use | |
481 | \helpref{OnExit}{wxapponexit} to clean up anything initialized here, provided | |
482 | that the function returns \true. | |
483 | ||
484 | Notice that if you want to to use the command line processing provided by | |
485 | wxWidgets you have to call the base class version in the derived class | |
486 | OnInit(). | |
487 | ||
488 | Return \true to continue processing, \false to exit the application | |
489 | immediately. | |
490 | ||
491 | ||
492 | \membersection{wxApp::OnInitCmdLine}\label{wxapponinitcmdline} | |
493 | ||
494 | \func{void}{OnInitCmdLine}{\param{wxCmdLineParser\& }{parser}} | |
495 | ||
496 | Called from \helpref{OnInit}{wxapponinit} and may be used to initialize the | |
497 | parser with the command line options for this application. The base class | |
498 | versions adds support for a few standard options only. | |
499 | ||
500 | \membersection{wxApp::OnRun}\label{wxapponrun} | |
501 | ||
502 | \func{virtual int}{OnRun}{\void} | |
503 | ||
504 | This virtual function is where the execution of a program written in wxWidgets | |
505 | starts. The default implementation just enters the main loop and starts | |
506 | handling the events until it terminates, either because | |
507 | \helpref{ExitMainLoop}{wxappexitmainloop} has been explicitly called or because | |
508 | the last frame has been deleted and | |
509 | \helpref{GetExitOnFrameDelete}{wxappgetexitonframedelete} flag is \true (this | |
510 | is the default). | |
511 | ||
512 | The return value of this function becomes the exit code of the program, so it | |
513 | should return $0$ in case of successful termination. | |
514 | ||
515 | ||
516 | \membersection{wxApp::OnUnhandledException}\label{wxapponunhandledexception} | |
517 | ||
518 | \func{virtual void}{OnUnhandledException}{\void} | |
519 | ||
520 | This function is called when an unhandled C++ exception occurs inside | |
521 | \helpref{OnRun()}{wxapponrun} (the exceptions which occur during the program | |
522 | startup and shutdown might not be caught at all). Notice that by now the main | |
523 | event loop has been terminated and the program will exit, if you want to | |
524 | prevent this from happening (i.e. continue running after catching an exception) | |
525 | you need to override \helpref{OnExceptionInMainLoop}{wxapponexceptioninmainloop}. | |
526 | ||
527 | The default implementation shows information about the exception in debug build | |
528 | but does nothing in the release build. | |
529 | ||
530 | ||
531 | \membersection{wxApp::ProcessMessage}\label{wxappprocessmessage} | |
532 | ||
533 | \func{bool}{ProcessMessage}{\param{WXMSG *}{msg}} | |
534 | ||
535 | Windows-only function for processing a message. This function | |
536 | is called from the main message loop, checking for windows that | |
537 | may wish to process it. The function returns true if the message | |
538 | was processed, false otherwise. If you use wxWidgets with another class | |
539 | library with its own message loop, you should make sure that this | |
540 | function is called to allow wxWidgets to receive messages. For example, | |
541 | to allow co-existence with the Microsoft Foundation Classes, override | |
542 | the PreTranslateMessage function: | |
543 | ||
544 | \begin{verbatim} | |
545 | // Provide wxWidgets message loop compatibility | |
546 | BOOL CTheApp::PreTranslateMessage(MSG *msg) | |
547 | { | |
548 | if (wxTheApp && wxTheApp->ProcessMessage((WXMSW *)msg)) | |
549 | return true; | |
550 | else | |
551 | return CWinApp::PreTranslateMessage(msg); | |
552 | } | |
553 | \end{verbatim} | |
554 | ||
555 | ||
556 | \membersection{wxApp::Pending}\label{wxapppending} | |
557 | ||
558 | \func{virtual bool}{Pending}{\void} | |
559 | ||
560 | Returns true if unprocessed events are in the window system event queue. | |
561 | ||
562 | \wxheading{See also} | |
563 | ||
564 | \helpref{wxApp::Dispatch}{wxappdispatch} | |
565 | ||
566 | ||
567 | \membersection{wxApp::SendIdleEvents}\label{wxappsendidleevents} | |
568 | ||
569 | \func{bool}{SendIdleEvents}{\param{wxWindow*}{ win}, \param{wxIdleEvent\& }{event}} | |
570 | ||
571 | Sends idle events to a window and its children. | |
572 | ||
573 | Please note that this function is internal to wxWidgets and shouldn't be used | |
574 | by user code. | |
575 | ||
576 | \wxheading{Remarks} | |
577 | ||
578 | These functions poll the top-level windows, and their children, for idle event processing. | |
579 | If true is returned, more OnIdle processing is requested by one or more window. | |
580 | ||
581 | \wxheading{See also} | |
582 | ||
583 | \helpref{wxIdleEvent}{wxidleevent} | |
584 | ||
585 | ||
586 | \membersection{wxApp::SetAppName}\label{wxappsetappname} | |
587 | ||
588 | \func{void}{SetAppName}{\param{const wxString\& }{name}} | |
589 | ||
590 | Sets the name of the application. The name may be used in dialogs | |
591 | (for example by the document/view framework). A default name is set by | |
592 | wxWidgets. | |
593 | ||
594 | \wxheading{See also} | |
595 | ||
596 | \helpref{wxApp::GetAppName}{wxappgetappname} | |
597 | ||
598 | ||
599 | \membersection{wxApp::SetClassName}\label{wxappsetclassname} | |
600 | ||
601 | \func{void}{SetClassName}{\param{const wxString\& }{name}} | |
602 | ||
603 | Sets the class name of the application. This may be used in a platform specific | |
604 | manner to refer to the application. | |
605 | ||
606 | \wxheading{See also} | |
607 | ||
608 | \helpref{wxApp::GetClassName}{wxappgetclassname} | |
609 | ||
610 | ||
611 | \membersection{wxApp::SetExitOnFrameDelete}\label{wxappsetexitonframedelete} | |
612 | ||
613 | \func{void}{SetExitOnFrameDelete}{\param{bool}{ flag}} | |
614 | ||
615 | Allows the programmer to specify whether the application will exit when the | |
616 | top-level frame is deleted. | |
617 | ||
618 | \wxheading{Parameters} | |
619 | ||
620 | \docparam{flag}{If true (the default), the application will exit when the top-level frame is | |
621 | deleted. If false, the application will continue to run.} | |
622 | ||
623 | \wxheading{See also} | |
624 | ||
625 | \helpref{wxApp::GetExitOnFrameDelete}{wxappgetexitonframedelete},\\ | |
626 | \helpref{wxApp shutdown overview}{wxappshutdownoverview} | |
627 | ||
628 | ||
629 | \membersection{wxApp::SetInstance}\label{wxappsetinstance} | |
630 | ||
631 | \func{static void}{SetInstance}{\param{wxAppConsole* }{app}} | |
632 | ||
633 | Allows external code to modify global \texttt{wxTheApp}, but you should really | |
634 | know what you're doing if you call it. | |
635 | ||
636 | \wxheading{Parameters} | |
637 | ||
638 | \docparam{app}{Replacement for the global application object.} | |
639 | ||
640 | \wxheading{See also} | |
641 | ||
642 | \helpref{wxApp::GetInstance}{wxappgetinstance} | |
643 | ||
644 | ||
645 | \membersection{wxApp::SetTopWindow}\label{wxappsettopwindow} | |
646 | ||
647 | \func{void}{SetTopWindow}{\param{wxWindow* }{window}} | |
648 | ||
649 | Sets the `top' window. You can call this from within \helpref{wxApp::OnInit}{wxapponinit} to | |
650 | let wxWidgets know which is the main window. You don't have to set the top window; | |
651 | it is only a convenience so that (for example) certain dialogs without parents can use a | |
652 | specific window as the top window. If no top window is specified by the application, | |
653 | wxWidgets just uses the first frame or dialog in its top-level window list, when it | |
654 | needs to use the top window. | |
655 | ||
656 | \wxheading{Parameters} | |
657 | ||
658 | \docparam{window}{The new top window.} | |
659 | ||
660 | \wxheading{See also} | |
661 | ||
662 | \helpref{wxApp::GetTopWindow}{wxappgettopwindow}, \helpref{wxApp::OnInit}{wxapponinit} | |
663 | ||
664 | ||
665 | ||
666 | \membersection{wxApp::SetVendorName}\label{wxappsetvendorname} | |
667 | ||
668 | \func{void}{SetVendorName}{\param{const wxString\& }{name}} | |
669 | ||
670 | Sets the name of application's vendor. The name will be used | |
671 | in registry access. A default name is set by | |
672 | wxWidgets. | |
673 | ||
674 | \wxheading{See also} | |
675 | ||
676 | \helpref{wxApp::GetVendorName}{wxappgetvendorname} | |
677 | ||
678 | ||
679 | \membersection{wxApp::SetUseBestVisual}\label{wxappsetusebestvisual} | |
680 | ||
681 | \func{void}{SetUseBestVisual}{\param{bool}{ flag}, \param{bool}{ forceTrueColour = false}} | |
682 | ||
683 | Allows the programmer to specify whether the application will use the best visual | |
684 | on systems that support several visual on the same display. This is typically the | |
685 | case under Solaris and IRIX, where the default visual is only 8-bit whereas certain | |
686 | applications are supposed to run in TrueColour mode. | |
687 | ||
688 | If \arg{forceTrueColour} is true then the application will try to force | |
689 | using a TrueColour visual and abort the app if none is found. | |
690 | ||
691 | Note that this function has to be called in the constructor of the {\tt wxApp} | |
692 | instance and won't have any effect when called later on. | |
693 | ||
694 | This function currently only has effect under GTK. | |
695 | ||
696 | \wxheading{Parameters} | |
697 | ||
698 | \docparam{flag}{If true, the app will use the best visual.} | |
699 | ||
700 | ||
701 | \membersection{wxApp::HandleEvent}\label{wxapphandleevent} | |
702 | ||
703 | \constfunc{virtual void}{HandleEvent}{\param{wxEvtHandler}{ *handler}, \param{wxEventFunction}{ func}, \param{wxEvent\& }{event}} | |
704 | ||
705 | This function simply invokes the given method \arg{func} of the specified | |
706 | event handler \arg{handler} with the \arg{event} as parameter. It exists solely | |
707 | to allow to catch the C++ exceptions which could be thrown by all event | |
708 | handlers in the application in one place: if you want to do this, override this | |
709 | function in your wxApp-derived class and add try/catch clause(s) to it. | |
710 | ||
711 | ||
712 | \membersection{wxApp::Yield}\label{wxappyield} | |
713 | ||
714 | \func{bool}{Yield}{\param{bool}{ onlyIfNeeded = false}} | |
715 | ||
716 | Yields control to pending messages in the windowing system. This can be useful, for example, when a | |
717 | time-consuming process writes to a text window. Without an occasional | |
718 | yield, the text window will not be updated properly, and on systems with | |
719 | cooperative multitasking, such as Windows 3.1 other processes will not respond. | |
720 | ||
721 | Caution should be exercised, however, since yielding may allow the | |
722 | user to perform actions which are not compatible with the current task. | |
723 | Disabling menu items or whole menus during processing can avoid unwanted | |
724 | reentrance of code: see \helpref{::wxSafeYield}{wxsafeyield} for a better | |
725 | function. | |
726 | ||
727 | Note that Yield() will not flush the message logs. This is intentional as | |
728 | calling Yield() is usually done to quickly update the screen and popping up a | |
729 | message box dialog may be undesirable. If you do wish to flush the log | |
730 | messages immediately (otherwise it will be done during the next idle loop | |
731 | iteration), call \helpref{wxLog::FlushActive}{wxlogflushactive}. | |
732 | ||
733 | Calling Yield() recursively is normally an error and an assert failure is | |
734 | raised in debug build if such situation is detected. However if the | |
735 | {\it onlyIfNeeded} parameter is {\tt true}, the method will just silently | |
736 | return {\tt false} instead. | |
737 |