]>
Commit | Line | Data |
---|---|---|
15b6757b | 1 | ///////////////////////////////////////////////////////////////////////////// |
e244be15 | 2 | // Name: xrc.h |
15b6757b FM |
3 | // Purpose: topic overview |
4 | // Author: wxWidgets team | |
5 | // RCS-ID: $Id$ | |
526954c5 | 6 | // Licence: wxWindows licence |
15b6757b FM |
7 | ///////////////////////////////////////////////////////////////////////////// |
8 | ||
880efa2a | 9 | /** |
36c9828f | 10 | |
032e27aa | 11 | @page overview_xrc XML Based Resource System (XRC) |
3863c5eb BP |
12 | |
13 | Classes: wxXmlResource, wxXmlResourceHandler | |
14 | ||
15 | The XML-based resource system, known as XRC, allows user interface elements | |
16 | such as dialogs, menu bars and toolbars, to be stored in text files and loaded | |
17 | into the application at run-time. XRC files can also be compiled into binary | |
18 | XRS files or C++ code (the former makes it possible to store all resources in a | |
19 | single file and the latter is useful when you want to embed the resources into | |
20 | the executable). | |
21 | ||
22 | There are several advantages to using XRC resources: | |
23 | ||
24 | @li Recompiling and linking an application is not necessary if the resources | |
25 | change. | |
26 | @li If you use a dialog designer that generates C++ code, it can be hard to | |
27 | reintegrate this into existing C++ code. Separation of resources and code | |
28 | is a more elegant solution. | |
29 | @li You can choose between different alternative resource files at run time, if | |
30 | necessary. | |
31 | @li The XRC format uses sizers for flexibility, allowing dialogs to be | |
32 | resizable and highly portable. | |
33 | @li The XRC format is a wxWidgets standard, and can be generated or | |
d9384bfb | 34 | postprocessed by any program that understands it. As it is based on the XML |
3863c5eb BP |
35 | standard, existing XML editors can be used for simple editing purposes. |
36 | ||
37 | XRC was written by Vaclav Slavik. | |
38 | ||
5fcef184 VZ |
39 | @li @ref overview_xrc_gettingstarted |
40 | @li @ref overview_xrc_xrcsample | |
3863c5eb BP |
41 | @li @ref overview_xrc_binaryresourcefiles |
42 | @li @ref overview_xrc_embeddedresource | |
3863c5eb BP |
43 | @li @ref overview_xrc_cppheader |
44 | @li @ref overview_xrc_newresourcehandlers | |
41e69d79 | 45 | |
5fcef184 VZ |
46 | See also the separate @ref overview_xrcformat page for more information, and |
47 | details about the XRC file format. | |
3863c5eb | 48 | |
3863c5eb | 49 | |
5fcef184 | 50 | @section overview_xrc_gettingstarted Getting Started with XRC |
3863c5eb | 51 | |
5fcef184 | 52 | <b> Creating an XRC file </b> |
3863c5eb | 53 | |
5fcef184 VZ |
54 | You will need to write an XRC file. Though this @e can be done by hand in a |
55 | text editor, for all but the smallest files it is advisable to use a | |
56 | specialised tool. Examples of these include: | |
3863c5eb | 57 | |
5fcef184 VZ |
58 | @e Non-free: |
59 | @li wxDesigner <http://www.wxdesigner-software.de/>, a commercial dialog | |
60 | designer/RAD tool. | |
61 | @li DialogBlocks <http://www.anthemion.co.uk/dialogblocks/>, a commercial | |
3863c5eb | 62 | dialog editor. |
5fcef184 VZ |
63 | |
64 | @e Free: | |
65 | @li XRCed <http://xrced.sf.net/>, a wxPython-based dialog editor that you | |
3863c5eb | 66 | can find in the wxPython/tools subdirectory of the wxWidgets SVN archive. |
5fcef184 VZ |
67 | @li wxFormBuilder <http://wxformbuilder.org/>, a C++-based dialog editor that |
68 | can output C++, XRC or python. | |
69 | ||
70 | There's a more complete list at <http://www.wxwidgets.org/wiki/index.php/Tools> | |
71 | ||
72 | This small demonstration XRC file contains a simple dialog: | |
73 | @code | |
74 | <?xml version="1.0" ?> | |
75 | <resource version="2.3.0.1"> | |
76 | <object class="wxDialog" name="SimpleDialog"> | |
77 | <title>Simple dialog</title> | |
78 | <object class="wxBoxSizer"> | |
79 | <orient>wxVERTICAL</orient> | |
80 | <object class="sizeritem"> | |
81 | <object class="wxTextCtrl" name="text"/> | |
82 | <option>1</option> | |
83 | <flag>wxALL|wxEXPAND</flag> | |
84 | <border>10</border> | |
85 | </object> | |
86 | <object class="sizeritem"> | |
87 | <object class="wxBoxSizer"> | |
88 | <object class="sizeritem"> | |
89 | <object class="wxButton" name="clickme_btn"> | |
90 | <label>Click</label> | |
91 | </object> | |
92 | <flag>wxRIGHT</flag> | |
93 | <border>10</border> | |
94 | </object> | |
95 | <object class="sizeritem"> | |
96 | <object class="wxButton" name="wxID_OK"> | |
97 | <label>OK</label> | |
98 | </object> | |
99 | <flag>wxLEFT</flag> | |
100 | <border>10</border> | |
101 | </object> | |
102 | <orient>wxHORIZONTAL</orient> | |
103 | </object> | |
104 | <flag>wxALL|wxALIGN_CENTRE</flag> | |
105 | <border>10</border> | |
106 | </object> | |
107 | </object> | |
108 | </object> | |
109 | </resource> | |
110 | @endcode | |
111 | ||
112 | You can keep all your XRC elements together in one file, or split them between | |
113 | several. | |
114 | ||
115 | <b> Loading XRC files </b> | |
116 | ||
117 | Before you can use XRC in an app, it must first be loaded. This code fragment | |
118 | shows how to load a single XRC file "resource.xrc" from the current working | |
119 | directory, plus all the *.xrc files contained in the subdirectory "rc". | |
120 | ||
121 | @code | |
122 | #include "wx/xrc/xmlres.h" | |
123 | ||
124 | bool MyApp::OnInit() | |
125 | { | |
126 | ... | |
127 | wxXmlResource::Get()->InitAllHandlers(); | |
128 | ||
129 | wxXmlResource::Get()->Load("resource.xrc"); | |
130 | wxXmlResource::Get()->LoadAllFiles("rc"); | |
131 | ... | |
132 | } | |
133 | @endcode | |
134 | ||
135 | It's normal to load any XRC files at the beginning of an app. Though it is | |
136 | possible to unload a file later, it's seldom necessary. | |
137 | ||
138 | ||
139 | <b> Using an XRC item </b> | |
140 | ||
141 | The XRC file(s) are now loaded into the app's virtual filesystem. From there, | |
142 | you must do another sort of load when you want to use an individual object. | |
143 | Yes, it's confusingly named, but you first Load() the file, and later load each | |
144 | top-level object when its needed. | |
3863c5eb | 145 | |
5fcef184 | 146 | This is how you would use the above simple dialog in your code. |
3863c5eb | 147 | |
5fcef184 VZ |
148 | @code |
149 | void MyClass::ShowDialog() | |
150 | { | |
151 | wxDialog dlg; | |
152 | if (wxXmlResource::Get()->LoadDialog(&dlg, NULL, "SimpleDialog")) | |
153 | dlg.ShowModal(); | |
154 | } | |
155 | @endcode | |
156 | ||
157 | See how simple the code is. All the instantiation is done invisibly by the XRC | |
158 | system. | |
159 | ||
160 | Though you'll most often use wxXmlResource::LoadDialog, there are also | |
161 | equivalents that load a frame, a menu etc; and the generic | |
162 | wxXmlResource::LoadObject. See wxXmlResource for more details. | |
3863c5eb | 163 | |
5fcef184 | 164 | <b> Accessing XRC child controls </b> |
3863c5eb | 165 | |
5fcef184 VZ |
166 | The last section showed how to load top-level windows like dialogs, but what |
167 | about child windows like the wxTextCtrl named "text" that the dialog contains? | |
168 | You can't 'load' an individual child control in the same way. Instead you use | |
169 | the XRCCTRL macro to get a pointer to the child. To expand the previous code: | |
3863c5eb | 170 | |
5fcef184 VZ |
171 | @code |
172 | void MyClass::ShowDialog() | |
173 | { | |
174 | wxDialog dlg; | |
175 | if (!wxXmlResource::Get()->LoadDialog(&dlg, NULL, "SimpleDialog")) | |
176 | return; | |
177 | ||
178 | wxTextCtrl* pText = XRCCTRL(dlg, "text", wxTextCtrl); | |
179 | if (pText) | |
180 | pText->ChangeValue("This is a simple dialog"); | |
181 | ||
182 | dlg.ShowModal(); | |
183 | } | |
184 | @endcode | |
185 | ||
186 | XRCCTRL takes a reference to the parent container and uses wxWindow::FindWindow | |
187 | to search inside it for a wxWindow with the supplied name (here "text"). It | |
188 | returns a pointer to that control, cast to the type in the third parameter; so | |
189 | a similar effect could be obtained by writing: | |
190 | ||
191 | @code | |
192 | pText = (wxTextCtrl*)(dlg.FindWindowByName("text")); | |
193 | @endcode | |
194 | ||
195 | <b> XRC and IDs </b> | |
196 | ||
197 | The ID of a control is often needed, e.g. for use in an event table | |
198 | or with wxEvtHandler::Bind. It can easily be found by passing the name of the | |
199 | control to the XRCID macro: | |
200 | ||
201 | @code | |
202 | void MyClass::ShowDialog() | |
203 | { | |
204 | wxDialog dlg; | |
205 | if (!wxXmlResource::Get()->LoadDialog(&dlg, NULL, "SimpleDialog")) | |
206 | return; | |
3863c5eb | 207 | |
5fcef184 VZ |
208 | XRCCTRL(dlg, "text", wxTextCtrl)->Bind(wxEVT_COMMAND_TEXT_UPDATED, |
209 | wxTextEventHandler(MyClass::OnTextEntered), this, XRCID("text")); | |
210 | ||
211 | XRCCTRL(dlg, "clickme_btn", wxButton)->Bind(wxEVT_COMMAND_BUTTON_CLICKED, | |
212 | wxCommandEventHandler(MyClass::OnClickme), this, XRCID("clickme_btn")); | |
213 | ||
214 | dlg.ShowModal(); | |
215 | } | |
216 | @endcode | |
217 | ||
218 | A few points to note: | |
219 | @li The value of the int returned by XRCID("foo") is guaranteed to be unique | |
220 | within an app. | |
221 | @li However that value isn't predictable, and you shouldn't rely on it being | |
222 | consistent between runs. It certainly won't be the same in different apps. | |
223 | @li @ref page_stockitems such as wxID_OK work correctly without requiring XRCID | |
224 | (because, internally, XRCID("wxID_OK") is mapped to wxID_OK). | |
225 | @li Both XRCID and XRCCTRL use the 'name' of the control (as in | |
226 | wxWindow::GetName). This is different from the label that the user sees on | |
227 | e.g. a wxButton. | |
228 | ||
229 | <b> Subclassing in XRC </b> | |
230 | ||
231 | You will often want to use subclassed wx controls in your code. There are three | |
232 | ways to do this from XRC: | |
233 | @li Very rarely you might need to | |
234 | @ref overview_xrcformat_extending_custom "create your own wxXmlResourceHandler" | |
235 | @li Occasionally wxXmlResource::AttachUnknownControl may be best. See | |
236 | @ref overview_xrcformat_extending_unknown | |
237 | @li Usually though, the simple 'subclass' keyword will suffice. | |
238 | ||
239 | Suppose you wanted the wxTextCtrl named "text" to be created as your derived | |
240 | class MyTextCtrl. The only change needed in the XRC file would be in this line: | |
241 | ||
242 | @code | |
243 | <object class="wxTextCtrl" name="text" subclass="MyTextCtrl"/> | |
244 | @endcode | |
245 | ||
246 | The only change in your code would be to use MyTextCtrl in XRCCTRL. However for | |
247 | the subclass to be created successfully, it's important to ensure that it uses | |
248 | wxWidget's RTTI mechanism: see @ref overview_xrcformat_extending_subclass for | |
249 | the details. | |
250 | ||
251 | ||
252 | ||
253 | @section overview_xrc_xrcsample The XRC sample | |
254 | ||
255 | A major resource for learning how to use XRC is the @sample{xrc}. This | |
256 | demonstrates all of the standard uses of XRC, and some of the less common ones. | |
257 | It is strongly suggested that you run it, and look at the well-commented | |
258 | source code to see how it works. | |
259 | ||
260 | ||
261 | @section overview_xrc_binaryresourcefiles Binary Resource Files | |
3863c5eb BP |
262 | |
263 | To compile binary resource files, use the command-line @c wxrc utility. It | |
264 | takes one or more file parameters (the input XRC files) and the following | |
265 | switches and options: | |
266 | ||
267 | @li -h (--help): Show a help message. | |
268 | @li -v (--verbose): Show verbose logging information. | |
269 | @li -c (--cpp-code): Write C++ source rather than a XRS file. | |
270 | @li -e (--extra-cpp-code): If used together with -c, generates C++ header file | |
271 | containing class definitions for the windows defined by the XRC file (see | |
272 | special subsection). | |
273 | @li -u (--uncompressed): Do not compress XML files (C++ only). | |
274 | @li -g (--gettext): Output underscore-wrapped strings that poEdit or gettext | |
275 | can scan. Outputs to stdout, or a file if -o is used. | |
276 | @li -n (--function) @<name@>: Specify C++ function name (use with -c). | |
277 | @li -o (--output) @<filename@>: Specify the output file, such as resource.xrs | |
278 | or resource.cpp. | |
279 | @li -l (--list-of-handlers) @<filename@>: Output a list of necessary handlers | |
280 | to this file. | |
281 | ||
282 | For example: | |
283 | ||
284 | @code | |
285 | $ wxrc resource.xrc | |
286 | $ wxrc resource.xrc -o resource.xrs | |
287 | $ wxrc resource.xrc -v -c -o resource.cpp | |
288 | @endcode | |
289 | ||
290 | @note XRS file is essentially a renamed ZIP archive which means that you can | |
291 | manipulate it with standard ZIP tools. Note that if you are using XRS files, | |
292 | you have to initialize the wxFileSystem archive handler first! It is a simple | |
293 | thing to do: | |
294 | ||
295 | @code | |
296 | #include <wx/filesys.h> | |
297 | #include <wx/fs_arc.h> | |
298 | ... | |
299 | wxFileSystem::AddHandler(new wxArchiveFSHandler); | |
300 | @endcode | |
301 | ||
302 | ||
303 | @section overview_xrc_embeddedresource Using Embedded Resources | |
304 | ||
305 | It is sometimes useful to embed resources in the executable itself instead of | |
306 | loading an external file (e.g. when your app is small and consists only of one | |
307 | exe file). XRC provides means to convert resources into regular C++ file that | |
308 | can be compiled and included in the executable. | |
309 | ||
310 | Use the @c -c switch to @c wxrc utility to produce C++ file with embedded | |
311 | resources. This file will contain a function called @c InitXmlResource (unless | |
312 | you override this with a command line switch). Use it to load the resource: | |
313 | ||
314 | @code | |
315 | extern void InitXmlResource(); // defined in generated file | |
316 | ... | |
317 | wxXmlResource::Get()->InitAllHandlers(); | |
318 | InitXmlResource(); | |
319 | ... | |
320 | @endcode | |
321 | ||
322 | ||
3863c5eb BP |
323 | @section overview_xrc_cppheader C++ header file generation |
324 | ||
325 | Using the @c -e switch together with @c -c, a C++ header file is written | |
326 | containing class definitions for the GUI windows defined in the XRC file. This | |
327 | code generation can make it easier to use XRC and automate program development. | |
328 | The classes can be used as basis for development, freeing the programmer from | |
329 | dealing with most of the XRC specifics (e.g. @c XRCCTRL). | |
330 | ||
331 | For each top level window defined in the XRC file a C++ class definition is | |
332 | generated, containing as class members the named widgets of the window. A | |
333 | default constructor for each class is also generated. Inside the constructor | |
334 | all XRC loading is done and all class members representing widgets are | |
335 | initialized. | |
336 | ||
337 | A simple example will help understand how the scheme works. Suppose you have a | |
338 | XRC file defining a top level window @c TestWnd_Base, which subclasses wxFrame | |
3c4f71cc | 339 | (any other class like @c wxDialog will do also), and has subwidgets wxTextCtrl A |
3863c5eb BP |
340 | and wxButton B. |
341 | ||
342 | The XRC file and corresponding class definition in the header file will be | |
343 | something like: | |
344 | ||
345 | @code | |
346 | <?xml version="1.0"?> | |
347 | <resource version="2.3.0.1"> | |
348 | <object class="wxFrame" name="TestWnd_Base"> | |
349 | <size>-1,-1</size> | |
350 | <title>Test</title> | |
351 | <object class="wxBoxSizer"> | |
352 | <orient>wxHORIZONTAL</orient> | |
353 | <object class="sizeritem"> | |
354 | <object class="wxTextCtrl" name="A"> | |
355 | <label>Test label</label> | |
356 | </object> | |
357 | </object> | |
358 | <object class="sizeritem"> | |
359 | <object class="wxButton" name="B"> | |
360 | <label>Test button</label> | |
361 | </object> | |
362 | </object> | |
363 | </object> | |
364 | </object> | |
365 | </resource> | |
366 | ||
367 | ||
368 | class TestWnd_Base : public wxFrame | |
369 | { | |
370 | protected: | |
371 | wxTextCtrl* A; | |
372 | wxButton* B; | |
373 | ||
374 | private: | |
375 | void InitWidgetsFromXRC() | |
376 | { | |
377 | wxXmlResource::Get()->LoadObject(this, NULL, "TestWnd", "wxFrame"); | |
378 | A = XRCCTRL(*this, "A", wxTextCtrl); | |
379 | B = XRCCTRL(*this, "B", wxButton); | |
380 | } | |
381 | public: | |
382 | TestWnd::TestWnd() | |
383 | { | |
384 | InitWidgetsFromXRC(); | |
385 | } | |
386 | }; | |
387 | @endcode | |
388 | ||
389 | The generated window class can be used as basis for the full window class. The | |
390 | class members which represent widgets may be accessed by name instead of using | |
391 | @c XRCCTRL every time you wish to reference them (note that they are | |
392 | @c protected class members), though you must still use @c XRCID to refer to | |
393 | widget IDs in the event table. | |
394 | ||
395 | Example: | |
396 | ||
397 | @code | |
398 | #include "resource.h" | |
399 | ||
400 | class TestWnd : public TestWnd_Base | |
401 | { | |
402 | public: | |
403 | TestWnd() | |
404 | { | |
405 | // A, B already initialised at this point | |
406 | A->SetValue("Updated in TestWnd::TestWnd"); | |
407 | B->SetValue("Nice :)"); | |
408 | } | |
409 | void OnBPressed(wxEvent& event) | |
410 | { | |
411 | Close(); | |
412 | } | |
413 | DECLARE_EVENT_TABLE(); | |
414 | }; | |
415 | ||
416 | BEGIN_EVENT_TABLE(TestWnd,TestWnd_Base) | |
417 | EVT_BUTTON(XRCID("B"), TestWnd::OnBPressed) | |
418 | END_EVENT_TABLE() | |
419 | @endcode | |
420 | ||
421 | It is also possible to access the wxSizerItem of a sizer that is part of a | |
422 | resource. This can be done using @c XRCSIZERITEM as shown. | |
423 | ||
424 | The resource file can have something like this for a sizer item. | |
425 | ||
426 | @code | |
427 | <object class="spacer" name="area"> | |
428 | <size>400, 300</size> | |
429 | </object> | |
430 | @endcode | |
431 | ||
432 | The code can then access the sizer item by using @c XRCSIZERITEM and @c XRCID | |
433 | together. | |
434 | ||
435 | @code | |
436 | wxSizerItem* item = XRCSIZERITEM(*this, "area"); | |
437 | @endcode | |
438 | ||
439 | ||
440 | @section overview_xrc_newresourcehandlers Adding New Resource Handlers | |
441 | ||
442 | Adding a new resource handler is pretty easy. | |
443 | ||
444 | Typically, to add an handler for the @c MyControl class, you'll want to create | |
445 | the @c xh_mycontrol.h and @c xh_mycontrol.cpp files. | |
446 | ||
447 | The header needs to contains the @c MyControlXmlHandler class definition: | |
448 | ||
449 | @code | |
450 | class MyControlXmlHandler : public wxXmlResourceHandler | |
451 | { | |
452 | public: | |
453 | // Constructor. | |
454 | MyControlXmlHandler(); | |
455 | ||
456 | // Creates the control and returns a pointer to it. | |
457 | virtual wxObject *DoCreateResource(); | |
458 | ||
459 | // Returns true if we know how to create a control for the given node. | |
460 | virtual bool CanHandle(wxXmlNode *node); | |
461 | ||
462 | // Register with wxWidgets' dynamic class subsystem. | |
463 | DECLARE_DYNAMIC_CLASS(MyControlXmlHandler) | |
464 | }; | |
465 | @endcode | |
466 | ||
467 | The implementation of your custom XML handler will typically look as: | |
468 | ||
469 | @code | |
470 | // Register with wxWidgets' dynamic class subsystem. | |
471 | IMPLEMENT_DYNAMIC_CLASS(MyControlXmlHandler, wxXmlResourceHandler) | |
472 | ||
473 | MyControlXmlHandler::MyControlXmlHandler() | |
474 | { | |
475 | // this call adds support for all wxWindows class styles | |
476 | // (e.g. wxBORDER_SIMPLE, wxBORDER_SUNKEN, wxWS_EX_* etc etc) | |
477 | AddWindowStyles(); | |
478 | ||
479 | // if MyControl class supports e.g. MYCONTROL_DEFAULT_STYLE | |
480 | // you should use: | |
481 | // XRC_ADD_STYLE(MYCONTROL_DEFAULT_STYLE); | |
482 | } | |
483 | ||
484 | wxObject *MyControlXmlHandler::DoCreateResource() | |
485 | { | |
486 | // the following macro will init a pointer named "control" | |
487 | // with a new instance of the MyControl class, but will NOT | |
488 | // Create() it! | |
489 | XRC_MAKE_INSTANCE(control, MyControl) | |
490 | ||
491 | // this is the point where you'll typically need to do the most | |
492 | // important changes: here the control is created and initialized. | |
493 | // You'll want to use the wxXmlResourceHandler's getters to | |
494 | // do most of your work. | |
495 | // If e.g. the MyControl::Create function looks like: | |
496 | // | |
3c4f71cc | 497 | // bool MyControl::Create(wxWindow *parent, int id, |
3863c5eb BP |
498 | // const wxBitmap &first, const wxPoint &posFirst, |
499 | // const wxBitmap &second, const wxPoint &posSecond, | |
500 | // const wxString &theTitle, const wxFont &titleFont, | |
501 | // const wxPoint &pos, const wxSize &size, | |
502 | // long style = MYCONTROL_DEFAULT_STYLE, | |
503 | // const wxString &name = wxT("MyControl")); | |
504 | // | |
505 | // Then the XRC for your component should look like: | |
506 | // | |
507 | // <object class="MyControl" name="some_name"> | |
508 | // <first-bitmap>first.xpm</first-bitmap> | |
509 | // <second-bitmap>text.xpm</second-bitmap> | |
510 | // <first-pos>3,3</first-pos> | |
511 | // <second-pos>4,4</second-pos> | |
512 | // <the-title>a title</the-title> | |
513 | // <title-font> | |
514 | // <!-- Standard XRC tags for a font: <size>, <style>, <weight>, etc --> | |
515 | // </title-font> | |
516 | // <!-- XRC also accepts other usual tags for wxWindow-derived classes: | |
517 | // like e.g. <name>, <style>, <size>, <position>, etc --> | |
518 | // </object> | |
519 | // | |
520 | // And the code to read your custom tags from the XRC file is just: | |
521 | control->Create(m_parentAsWindow, GetID(), | |
522 | GetBitmap(wxT("first-bitmap")), | |
523 | GetPosition(wxT("first-pos")), | |
524 | GetBitmap(wxT("second-bitmap")), | |
525 | GetPosition(wxT("second-pos")), | |
526 | GetText(wxT("the-title")), | |
527 | GetFont(wxT("title-font")), | |
528 | GetPosition(), GetSize(), GetStyle(), GetName()); | |
529 | ||
530 | SetupWindow(control); | |
531 | ||
532 | return control; | |
533 | } | |
534 | ||
535 | bool MyControlXmlHandler::CanHandle(wxXmlNode *node) | |
536 | { | |
537 | // this function tells XRC system that this handler can parse | |
538 | // the <object class="MyControl"> tags | |
539 | return IsOfClass(node, wxT("MyControl")); | |
540 | } | |
541 | @endcode | |
542 | ||
543 | You may want to check the wxXmlResourceHandler documentation to see how many | |
544 | built-in getters it contains. It's very easy to retrieve also complex | |
545 | structures out of XRC files using them. | |
36c9828f | 546 | |
e244be15 | 547 | */ |
36c9828f | 548 |