Fix some typos, no code changes (besides strings)
This commit is contained in:
Dimitri Schoolwerth
@@ -18,7 +18,7 @@
|
||||
\setheader{{\it CHAPTER \thechapter}}{}{}{}{}{{\it CHAPTER \thechapter}}%
|
||||
\setfooter{\thepage}{}{}{}{}{\thepage}%
|
||||
|
||||
This is a demo document for the wxWindows 'help' sample.
|
||||
This is a demo document for the wxWidgets 'help' sample.
|
||||
|
||||
You should process this file with Tex2RTF, for example:
|
||||
|
||||
|
||||
@@ -1414,7 +1414,7 @@ bool FormMain::RunTests( bool fullTest, bool interactive )
|
||||
}
|
||||
else
|
||||
{
|
||||
RT_MSG(wxT("All tests successfull"))
|
||||
RT_MSG(wxT("All tests successful"))
|
||||
retVal = true;
|
||||
|
||||
if ( !interactive )
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
<object class="wxTextCtrl" name="message_textctrl">
|
||||
<size>500,150</size>
|
||||
<style>wxTE_MULTILINE</style>
|
||||
<value>You can specify wxArtProvider icons in your XRC resources. These icons will be retrieved from the active wxArtProvider (see wxArtProvider in docs and /samples/artprov for more information on wxArtProvider).\n\nThe most common usage for this is that you want a dialog, toolbar or menu item to have the correct platform-specific icon in your interface, such as a custom "Don't show this again" checkbox message dialog that has the appropriate icon, as shown below.\n\nYou can also use it to manage your own custom bitmaps though, too--instead of having to write multiple versions of an XRC file that only differ in their bitmaps, you can instead just write one XRC file with the bitmap to be retrieved from the wxArtProvider at runtime, having your custom wxArtProvider use some code to serve out the desired bitmap based on such things as a wxConfig n entry of a desired icon set, what OS the application is running on, what size or resolution the display is, and so on.\n\nNote that your application's custom bitmaps are the only thing that will differ between OS's in order to ensure proper Look And Feel, as everything else: windows decoration, colors, fonts, widgets, etc already match perfectly since wxWindows runs natively.\n\nTo use a wxArtProvider bitmap instead of usual bitmap, in your XRC, instead of <bitmap>somefile.png</bitmap>, use <bitmap stock__id="SOME__ART__ID" client="SOME__CLIENT__ID">somefile.png</bitmap>. The stock__id parameter is required for a bitmap to be read from wxArtProvider, stock__client is optional. The image filename is also optional, and is just used as a fallback in case the wxArtProvider couldn't return a bitmap for that particular stock__id (and particular stock__client if your wxArtProvider is set up to also filter stock__client).</value>
|
||||
<value>You can specify wxArtProvider icons in your XRC resources. These icons will be retrieved from the active wxArtProvider (see wxArtProvider in docs and /samples/artprov for more information on wxArtProvider).\n\nThe most common usage for this is that you want a dialog, toolbar or menu item to have the correct platform-specific icon in your interface, such as a custom "Don't show this again" checkbox message dialog that has the appropriate icon, as shown below.\n\nYou can also use it to manage your own custom bitmaps though, too--instead of having to write multiple versions of an XRC file that only differ in their bitmaps, you can instead just write one XRC file with the bitmap to be retrieved from the wxArtProvider at runtime, having your custom wxArtProvider use some code to serve out the desired bitmap based on such things as a wxConfig entry of a desired icon set, what OS the application is running on, what size or resolution the display is, and so on.\n\nNote that your application's custom bitmaps are the only thing that will differ between OS's in order to ensure proper Look And Feel, as everything else: windows decoration, colors, fonts, widgets, etc already match perfectly since wxWidgets runs natively.\n\nTo use a wxArtProvider bitmap instead of usual bitmap, in your XRC, instead of <bitmap>somefile.png</bitmap>, use <bitmap stock__id="SOME__ART__ID" client="SOME__CLIENT__ID">somefile.png</bitmap>. The stock__id parameter is required for a bitmap to be read from wxArtProvider, stock__client is optional. The image filename is also optional, and is just used as a fallback in case the wxArtProvider couldn't return a bitmap for that particular stock__id (and particular stock__client if your wxArtProvider is set up to also filter stock__client).</value>
|
||||
</object>
|
||||
</object>
|
||||
<object class="sizeritem">
|
||||
|
||||
@@ -19,7 +19,7 @@
|
||||
<object class="wxTextCtrl" name="message_textctrl">
|
||||
<size>500,150</size>
|
||||
<style>wxTE_MULTILINE</style>
|
||||
<value>You can embed your own custom classes into an XRC file. This is referred to as attaching an unknown control.\n\nThere are 3 main cases when you would want to do this:\n\n(A) Most commonly: you have derived a class from one of the main wxWidgets controls, so that it can manage its own state and look after its own events, because it is better management to have a portable class with all the code for that control in there with the class, instead of being having many event handlers for that control scattered up in its parent dialog (which is allowed, but gets messy if a control has alot of methods). For example, if you require a wxListCtrl that popups a menu when right-clicked on an item, and you want the wxListCtrl to resize its columns in response to an OnSize(), and a few more methods, it makes better sourcecode logic to package all these methods into by a standalone derived wxListCtrl class, instead of having the parent dialog manage all these events and other functions. This is what the example below shows: it does a custom behaviour of resizing its first column to appropriately fill up the width of the control on a resize event, and it pops up a context-menu in response to a left click (and shades out popup menu item appropriately if there is no item currenty selected in the listctrl).\n\n(B)You have an utterly new widget that has no equivalent in the wxWindows class heirarchy, so you thus need to embed your class to get the needed functionality.\n\n(C) You are using one of the rarely used wxWindows controls that doesn't have an XRC handler in the XRC library. However, all of the major controls: wxButton, wxTextCtrl, etc have an XRC handler, so this is pretty rare, and you could always write your own XRC handler for that control if you wanted. You can choose the "Controls example" from the XRC demo menu to see all the controls that have an XRC handler.\n\nThe typical formula for attaching an unknown control is:\n\n(1) If you are deriving your own custom class to be embedded into the XRC, describe that class with its own .cpp and .h file. In this example it is custclass.cpp and custclass.h\n\n(2)Specify an "unknown" tag in the XRC file that you want to embed it into (see the unknown tag in custclass.xrc). This will be the placeholder of the new class.\n\n(3) Load the XRC dialog as usual, but before you show the dialog to the user, construct an instance of your custom control, and then use wxXmlResource::Get()->AttachUnknownControl() to put the custom class into its "unknown" placeholder in the XRC file.\n\nThe result is what you see below, a custom class control that fits in seemlessly with the whole dialog, the same as if it was read from XRC directly. Try out resizing this dialog, and watch the listctrl column resize, and right-click to call up its popup menu. By the way, if you look at the source of this XRC dialog, you will that this dialog node has a set of style flags that includes wxRESIZE__BORDER--that is why this dialog is resizable, whereas most of the rest of the dialogs in the XRC sample that don't include this tag, are not resizable.</value>
|
||||
<value>You can embed your own custom classes into an XRC file. This is referred to as attaching an unknown control.\n\nThere are 3 main cases when you would want to do this:\n\n(A) Most commonly: you have derived a class from one of the main wxWidgets controls, so that it can manage its own state and look after its own events, because it is better management to have a portable class with all the code for that control in there with the class, instead of having many event handlers for that control scattered up in its parent dialog (which is allowed, but gets messy if a control has a lot of methods). For example, if you require a wxListCtrl that popups a menu when right-clicked on an item, and you want the wxListCtrl to resize its columns in response to an OnSize(), and a few more methods, it makes better sourcecode logic to package all these methods into a standalone derived wxListCtrl class, instead of having the parent dialog manage all these events and other functions. This is what the example below shows: it does a custom behaviour of resizing its first column to appropriately fill up the width of the control on a resize event, and it pops up a context-menu in response to a left click (and shades out popup menu item appropriately if there is no item currenty selected in the listctrl).\n\n(B)You have an utterly new widget that has no equivalent in the wxWindows class hierarchy, so you thus need to embed your class to get the needed functionality.\n\n(C) You are using one of the rarely used wxWindows controls that doesn't have an XRC handler in the XRC library. However, all of the major controls: wxButton, wxTextCtrl, etc have an XRC handler, so this is pretty rare, and you could always write your own XRC handler for that control if you wanted. You can choose the "Controls example" from the XRC demo menu to see all the controls that have an XRC handler.\n\nThe typical formula for attaching an unknown control is:\n\n(1) If you are deriving your own custom class to be embedded into the XRC, describe that class with its own .cpp and .h file. In this example it is custclass.cpp and custclass.h\n\n(2)Specify an "unknown" tag in the XRC file that you want to embed it into (see the unknown tag in custclass.xrc). This will be the placeholder of the new class.\n\n(3) Load the XRC dialog as usual, but before you show the dialog to the user, construct an instance of your custom control, and then use wxXmlResource::Get()->AttachUnknownControl() to put the custom class into its "unknown" placeholder in the XRC file.\n\nThe result is what you see below, a custom class control that fits in seamlessly with the whole dialog, the same as if it was read from XRC directly. Try out resizing this dialog, and watch the listctrl column resize, and right-click to call up its popup menu. By the way, if you look at the source of this XRC dialog, you will that this dialog node has a set of style flags that includes wxRESIZE__BORDER--that is why this dialog is resizable, whereas most of the rest of the dialogs in the XRC sample that don't include this tag, are not resizable.</value>
|
||||
</object>
|
||||
</object>
|
||||
<object class="sizeritem">
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
<object class="wxTextCtrl" name="message_textctrl">
|
||||
<size>500,150</size>
|
||||
<style>wxTE_MULTILINE</style>
|
||||
<value>This is a derived dialog using XRC. This type of derived dialog will likely be the heart of your project, and thus is the most important example in this demonstration.\n\nIt is recommended to open up derivdlg.cpp, derivdlg.h and derivdlg.xrc and follow along what is going on.\n\nThe steps to use a derived dialog are:\n\n(1) Derive your own dialog from wxDialog (derivdlg.cpp and derivdlg.h are an example).\n\n(2) In the source of the constructor of the derived dialog, load the XRC into the file, using the code as shown in the derivdlg.cpp\n\n(3)Add to the derived dilog's sourcecode some event handlers and other methods you want the dialog to do.\n\n(4)You can now just make an instance of the derived dialog and show it using ShowModal(), as is done in the MyFrame::OnDerivedDialogToolOrMenuCommand() method.\n\nThe remainder of this docuent will talk about how to use events with derived dialogs and XRC. There are 3 bits of an extra event functionality that this derived dialog can do, these will be described in turn:\n\n(A) Something to do when a user clicks on your custom button: This is straightforward. You name a control in the XRC file (in this example it is "my__button"). Then in the .cpp file, put an entry in the event table that will connect button clicks with that ID to a function that will be fired. The event table entry in the example is EVT__BUTTON( XRCID( "my__button" ), PreferencesDialog::OnMyButtonClicked ) This event table entry has 3 parts: The first part, EVT__BUTTON tells that you are describing a button click event. The final part, PreferencesDialog::OnMyButtonClicked() is what you want done in response to a button event. The middle part, XRCID( "my__button" ) is the restriction that only button events generated by a wxButton of that ID should trigger go on to do the function. This XRCID is the name of the wxButton in your XRC file. Now just describe, in the .h file and .cpp file, what you want your custom OnMyButtonClicked() function to do.\n\n(B) The second example is a very common requirement: that a checkbox or radiobutton disables some other control. The event table is set up the same as the "My Button" example above. However, it isn't an EVT__BUTTON event, it is an EVT__UPDATE__UI event: when the dialog does an updating of its UI (and thus fires this event) if the updating if of a control matching that XRCID, then it will do the specified function (which in this case looks at whether or not the checkbox is checked, and if it isn't checked, then disable the textctrl).\n\n(C) The last example shows how to handle the OK button. You will likely want to do something when the user presses OK, like save preferences or start some action (this example shows a simple case of just popping up a dialog and stopping a close). OK buttons are always named wxID__OK, so the XRC file should have it as wxID__OK also. The Event table has an EVT__BUTTON entry for wxID__OK (no XRCID though). Since this is a derived dialog with an event table, in response to an EVT__BUTTON event from a wxID__OK button, it will first look around in its own event table to see if there was any EVT__BUTTON entries, and since there is, it will do that one--if there wasn't it then checks out the base class's event table and sees if there was one there, and so on up the chain of inherited classes. Note that this is exactly what happens with the derived dialog's wxID__CANCEL button. You didn't put any EVT__BUTTON entries with an identifier of wxID__CANCEL, so after it scans your derived dialog's event table, it will then look at wxDialog's event table and see if there is one in that event table, and so on until it finds one. It will find a wxID__CANCEL handler, which will connect to the proper function (which causes the dialog to close).
|
||||
<value>This is a derived dialog using XRC. This type of derived dialog will likely be the heart of your project, and thus is the most important example in this demonstration.\n\nIt is recommended to open up derivdlg.cpp, derivdlg.h and derivdlg.xrc and follow along what is going on.\n\nThe steps to use a derived dialog are:\n\n(1) Derive your own dialog from wxDialog (derivdlg.cpp and derivdlg.h are an example).\n\n(2) In the source of the constructor of the derived dialog, load the XRC into the file, using the code as shown in the derivdlg.cpp\n\n(3)Add to the derived dialog's sourcecode some event handlers and other methods you want the dialog to do.\n\n(4)You can now just make an instance of the derived dialog and show it using ShowModal(), as is done in the MyFrame::OnDerivedDialogToolOrMenuCommand() method.\n\nThe remainder of this document will talk about how to use events with derived dialogs and XRC. There are 3 bits of an extra event functionality that this derived dialog can do, these will be described in turn:\n\n(A) Something to do when a user clicks on your custom button: This is straightforward. You name a control in the XRC file (in this example it is "my__button"). Then in the .cpp file, put an entry in the event table that will connect button clicks with that ID to a function that will be fired. The event table entry in the example is EVT__BUTTON( XRCID( "my__button" ), PreferencesDialog::OnMyButtonClicked ) This event table entry has 3 parts: The first part, EVT__BUTTON tells that you are describing a button click event. The final part, PreferencesDialog::OnMyButtonClicked() is what you want done in response to a button event. The middle part, XRCID( "my__button" ) is the restriction that only button events generated by a wxButton of that ID should trigger go on to do the function. This XRCID is the name of the wxButton in your XRC file. Now just describe, in the .h file and .cpp file, what you want your custom OnMyButtonClicked() function to do.\n\n(B) The second example is a very common requirement: that a checkbox or radiobutton disables some other control. The event table is set up the same as the "My Button" example above. However, it isn't an EVT__BUTTON event, it is an EVT__UPDATE__UI event: when the dialog does an update of its UI (and thus fires this event) if the updating is of a control matching that XRCID, then it will do the specified function (which in this case looks at whether or not the checkbox is checked, and if it isn't checked, then disable the textctrl).\n\n(C) The last example shows how to handle the OK button. You will likely want to do something when the user presses OK, like save preferences or start some action (this example shows a simple case of just popping up a dialog and stopping a close). OK buttons are always named wxID__OK, so the XRC file should have it as wxID__OK also. The Event table has an EVT__BUTTON entry for wxID__OK (no XRCID though). Since this is a derived dialog with an event table, in response to an EVT__BUTTON event from a wxID__OK button, it will first look around in its own event table to see if there was any EVT__BUTTON entries, and since there is, it will do that one--if there wasn't it then checks out the base class's event table and sees if there was one there, and so on up the chain of inherited classes. Note that this is exactly what happens with the derived dialog's wxID__CANCEL button. You didn't put any EVT__BUTTON entries with an identifier of wxID__CANCEL, so after it scans your derived dialog's event table, it will then look at wxDialog's event table and see if there is one in that event table, and so on until it finds one. It will find a wxID__CANCEL handler, which will connect to the proper function (which causes the dialog to close).
|
||||
</value>
|
||||
</object>
|
||||
</object>
|
||||
|
||||
@@ -18,7 +18,7 @@
|
||||
<object class="wxTextCtrl" name="message_textctrl">
|
||||
<size>500,150</size>
|
||||
<style>wxTE_MULTILINE</style>
|
||||
<value>VARIABLE EXPANSION ISN'T IMPLEMENTED CURRENTLY. You can use variable expansion in your XRC files. The steps to do this are:\n\n(1)Enclose a variable inside a dollarsign and round brackets, like this: dollarsign(version).\n\n(2) Set the XmlResource flags to allow expansion of variables.\n\n(3)Before you use that XML resource, inform the XmlResourceHandler what you want that variable's value to be, via wxResourceHandler::Get()->SetVariable( "version", "2.4.0")\n\n Now, at runtime, the variable will be automatically replace by its value before the control is constructed.\n\nThe number in the version at the bottom of this dialog is an example of this expansion in action.\n\nThis is very handy for things like replacing the text in a wxStaticText, since it is a much simpler way to make a wxStaticText be a proper size: by creating it the proper size. This is in contrast to the alternative way of having using some static non-variable value in your XRC, having XRC construct it, then your application having code to change the text of it, then your app getting its best size, then setting the statictext's size, then laying out the dialog's sizer again, and other work.</value>
|
||||
<value>VARIABLE EXPANSION ISN'T IMPLEMENTED CURRENTLY. You can use variable expansion in your XRC files. The steps to do this are:\n\n(1)Enclose a variable inside a dollarsign and round brackets, like this: dollarsign(version).\n\n(2) Set the XmlResource flags to allow expansion of variables.\n\n(3)Before you use that XML resource, inform the XmlResourceHandler what you want that variable's value to be, via wxResourceHandler::Get()->SetVariable( "version", "2.4.0")\n\n Now, at runtime, the variable will be automatically replace by its value before the control is constructed.\n\nThe number in the version at the bottom of this dialog is an example of this expansion in action.\n\nThis is very handy for things like replacing the text in a wxStaticText, since it is a much simpler way to make a wxStaticText be a proper size: by creating it at the proper size. This is in contrast to the alternative way of using some static non-variable value in your XRC, having XRC construct it, then your application having code to change the text of it, then your app getting its best size, then setting the statictext's size, then laying out the dialog's sizer again, and other work.</value>
|
||||
</object>
|
||||
</object>
|
||||
<object class="sizeritem">
|
||||
|
||||
Reference in New Issue
Block a user