wxruby3 0.9.0-x64-mingw-ucrt → 0.9.2-x64-mingw-ucrt

data/lib/wx/doc/gen/events.rb

@@ -11,18 +11,16 @@ module Wx
   # If you need to ensure a continuous stream of idle events, you can either use {Wx::IdleEvent#request_more} method in your handler or call {wake_up_idle} periodically (for example from a timer event handler), but note that both of these approaches (and especially the first one) increase the system load and so should be avoided if possible.
   # By default, idle events are sent to all windows, including even the hidden ones because they may be shown if some condition is met from their {Wx::EVT_IDLE} (or related {Wx::EVT_UPDATE_UI}) handler. The children of hidden windows do not receive idle events however as they can't change their state in any way noticeable by the user. Finally, the global {Wx::App} object also receives these events, as usual, so it can be used for any global idle time processing.
   # If sending idle events to all windows is causing a significant overhead in your application, you can call {Wx::IdleEvent.set_mode} with the value {Wx::IdleMode::IDLE_PROCESS_SPECIFIED}, and set the {Wx::WS_EX_PROCESS_IDLE} extra window style for every window which should receive idle events, all the other ones will not receive them in this case.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::IdleEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_idle}(meth = nil, &block): Process a {Wx::EVT_IDLE} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # 
-  # == Delayed Action Mechanism
+  # ## Delayed Action Mechanism
   # 
   # {Wx::IdleEvent} can be used to perform some action "at slightly later time". This can be necessary in several circumstances when, for whatever reason, something can't be done in the current event handler. For example, if a mouse event handler is called with the mouse button pressed, the mouse can be currently captured and some operations with it  notably capturing it again  might be impossible or lead to undesirable results. If you still want to capture it, you can do it from {Wx::EVT_IDLE} handler when it is called the next time instead of doing it immediately.
   # This can be achieved in two different ways: when using static event tables, you will need a flag indicating to the (always connected) idle event handler whether the desired action should be performed. The originally called handler would then set it to indicate that it should indeed be done and the idle handler itself would reset it to prevent it from doing the same action again.
@@ -67,7 +65,6 @@ module Wx
   
   # This class is not used by the event handlers by itself, but is a base class for other event classes (such as {Wx::BookCtrlEvent}).
   # It (or an object of a derived class) is sent when the controls state is being changed and allows the program to {Wx::NotifyEvent#veto} this change if it wants to prevent it from happening.
-  # === 
   # 
   # Category:  {Wx::Events}
   # @see Wx::BookCtrlEvent 
@@ -76,7 +73,7 @@ module Wx
   class NotifyEvent < CommandEvent
   
     # Constructor (used internally by wxWidgets only).
-    # @param eventType [Wx::CommandLinkButton::EventType] 
+    # @param eventType [Wx::Slider::EventType] 
     # @param id [Integer] 
     # @return [Wx::NotifyEvent]
     def initialize(eventType=Wx::EVT_NULL, id=0) end
@@ -101,14 +98,19 @@ module Wx
   # A scroll event holds information about events sent from stand-alone scrollbars (see {Wx::ScrollBar}) and sliders (see {Wx::Slider}).
   # Note that scrolled windows send the {Wx::ScrollWinEvent} which does not derive from {Wx::CommandEvent}, but from {Wx::Event} directly - don't confuse these two kinds of events and use the event table macros mentioned below only for the scrollbar-like controls.
   # 
-  # == The difference between EVT_SCROLL_THUMBRELEASE and EVT_SCROLL_CHANGED
+  # ## The difference between EVT_SCROLL_THUMBRELEASE and EVT_SCROLL_CHANGED
   # 
   # The EVT_SCROLL_THUMBRELEASE event is only emitted when actually dragging the thumb using the mouse and releasing it (This EVT_SCROLL_THUMBRELEASE event is also followed by an EVT_SCROLL_CHANGED event).
   # The EVT_SCROLL_CHANGED event also occurs when using the keyboard to change the thumb position, and when clicking next to the thumb (In all these cases the EVT_SCROLL_THUMBRELEASE event does not happen).
   # In short, the EVT_SCROLL_CHANGED event is triggered when scrolling/ moving has finished independently of the way it had started. Please see the Widgets Sample ("Slider" page) to see the difference between EVT_SCROLL_THUMBRELEASE and EVT_SCROLL_CHANGED in action.
-  # Note that unless specifying a scroll control identifier, you will need to test for scrollbar orientation with {Wx::ScrollEvent#get_orientation}, since horizontal and vertical scroll events are processed using the same event handler.
   # 
-  # === Events using this class
+  # <div class="wxrb-remark">
+  # <b>Remark:</b>
+  # <p>Note that unless specifying a scroll control identifier, you will need to test for scrollbar orientation with {Wx::ScrollEvent#get_orientation}, since horizontal and vertical scroll events are processed using the same event handler.
+  # </p>
+  # </div>>
+  # 
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::ScrollEvent} events.
   # Event handler methods: except for this, the macros behave exactly the same. 
@@ -153,8 +155,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_command_scroll_changed}(meth = nil, &block): Process {Wx::EVT_SCROLL_CHANGED} end of scrolling events (MSW only). 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::ScrollBar
   # @see  Wx::Slider
@@ -166,7 +166,7 @@ module Wx
   class ScrollEvent < CommandEvent
   
     # Constructor.
-    # @param commandType [Wx::CommandLinkButton::EventType] 
+    # @param commandType [Wx::Slider::EventType] 
     # @param id [Integer] 
     # @param pos [Integer] 
     # @param orientation [Integer] 
@@ -197,7 +197,7 @@ module Wx
   
   # A scroll event holds information about events sent from scrolling windows.
   # Note that you can use the EVT_SCROLLWIN* macros for intercepting scroll window events from the receiving window.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::ScrollWinEvent} events.
   # Event handler methods:
@@ -220,8 +220,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_scrollwin_thumbrelease}(meth = nil, &block): Process {Wx::EVT_SCROLLWIN_THUMBRELEASE} thumb release events. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::ScrollEvent
   # @see  Events and Event Handling 
@@ -230,7 +228,7 @@ module Wx
   class ScrollWinEvent < Event
   
     # Constructor.
-    # @param commandType [Wx::CommandLinkButton::EventType] 
+    # @param commandType [Wx::Slider::EventType] 
     # @param pos [Integer] 
     # @param orientation [Integer] 
     # @return [Wx::ScrollWinEvent]
@@ -264,9 +262,14 @@ module Wx
   # All mouse events involving the buttons use {Wx::MouseButton::MOUSE_BTN_LEFT} for the left mouse button, {Wx::MouseButton::MOUSE_BTN_MIDDLE} for the middle one and {Wx::MouseButton::MOUSE_BTN_RIGHT} for the right one. And if the system supports more buttons, the {Wx::MouseButton::MOUSE_BTN_AUX1} and {Wx::MouseButton::MOUSE_BTN_AUX2} events can also be generated. Note that not all mice have even a middle button so a portable application should avoid relying on the events from it (but the right button click can be emulated using the left mouse button with the control key under Mac platforms with a single button mouse).
   # For the {Wx::EVT_ENTER_WINDOW} and {Wx::EVT_LEAVE_WINDOW} events purposes, the mouse is considered to be inside the window if it is in the window client area and not inside one of its children. In other words, the parent window receives {Wx::EVT_LEAVE_WINDOW} event not only when the mouse leaves the window entirely but also when it enters one of its children.
   # The position associated with a mouse event is expressed in the window coordinates of the window which generated the event, you can use {Wx::Window#client_to_screen} to convert it to screen coordinates and possibly call {Wx::Window#screen_to_client} next to convert it to window coordinates of another window.
-  # Note the difference between methods like {Wx::MouseEvent#left_down} and the inherited {Wx::MouseState#left_is_down}: the former returns true when the event corresponds to the left mouse button click while the latter returns true if the left mouse button is currently being pressed. For example, when the user is dragging the mouse you can use {Wx::MouseEvent::LeftIsDown} to test whether the left mouse button is (still) depressed. Also, by convention, if {Wx::MouseEvent#left_down} returns true, {Wx::MouseEvent::LeftIsDown} will also return true in wxWidgets whatever the underlying GUI behaviour is (which is platform-dependent). The same applies, of course, to other mouse buttons as well.
   # 
-  # === Events using this class
+  # <div class="wxrb-note">
+  # <b>Note:</b>
+  # <p>Note the difference between methods like {Wx::MouseEvent#left_down} and the inherited {Wx::MouseState#left_is_down}: the former returns true when the event corresponds to the left mouse button click while the latter returns true if the left mouse button is currently being pressed. For example, when the user is dragging the mouse you can use {Wx::MouseEvent::LeftIsDown} to test whether the left mouse button is (still) depressed. Also, by convention, if {Wx::MouseEvent#left_down} returns true, {Wx::MouseEvent::LeftIsDown} will also return true in wxWidgets whatever the underlying GUI behaviour is (which is platform-dependent). The same applies, of course, to other mouse buttons as well.
+  # </p>
+  # </div>
+  # 
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::MouseEvent} events.
   # Event handler methods:
@@ -313,8 +316,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_magnify}(meth = nil, &block): Process a {Wx::EVT_MAGNIFY} event (new since wxWidgets 3.1.0). 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::KeyEvent 
   # 
@@ -363,7 +364,7 @@ module Wx
     # - {Wx::EVT_MOUSEWHEEL} 
     # 
     # - {Wx::EVT_MAGNIFY}
-    # @param mouseEventType [Wx::CommandLinkButton::EventType] 
+    # @param mouseEventType [Wx::Slider::EventType] 
     # @return [Wx::MouseEvent]
     def initialize(mouseEventType=Wx::EVT_NULL) end
     
@@ -434,7 +435,7 @@ module Wx
     def get_button; end
     
     # Returns the number of mouse clicks for this event: 1 for a simple click, 2 for a double-click, 3 for a triple-click and so on.
-    # Currently this function is implemented only in {Wx::Mac} and returns -1 for the other platforms (you can still distinguish simple clicks from double-clicks as they generate different kinds of events however).
+    # Currently this function is implemented only in WXOSX and returns -1 for the other platforms (you can still distinguish simple clicks from double-clicks as they generate different kinds of events however).
     # @return [Integer]
     def get_click_count; end
     alias_method :click_count, :get_click_count
@@ -733,15 +734,13 @@ module Wx
   
   # A {Wx::SetCursorEvent} is generated from {Wx::Window} when the mouse cursor is about to be set as a result of mouse motion.
   # This event gives the application the chance to perform specific mouse cursor processing based on the current position of the mouse within the window. Use {Wx::SetCursorEvent#set_cursor} to specify the cursor you want to be displayed.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::SetCursorEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_set_cursor}(meth = nil, &block): Process a {Wx::EVT_SET_CURSOR} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::SetCursor
   # @see  Wx::Window#set_cursor 
@@ -771,7 +770,11 @@ module Wx
     alias_method :y, :get_y
     
     # Returns true if the cursor specified by this event is a valid cursor.
-    # You cannot specify {Wx::NULL_CURSOR} with this event, as it is not considered a valid cursor.
+    # <div class="wxrb-remark">
+    # <b>Remark:</b>
+    # <p>You cannot specify {Wx::NULL_CURSOR} with this event, as it is not considered a valid cursor. 
+    # </p>
+    # </div>>
     # @return [Boolean]
     def has_cursor; end
     alias_method :has_cursor?, :has_cursor
@@ -785,9 +788,11 @@ module Wx
   end # SetCursorEvent
   
   # This is the base class for all supported gesture events.
-  # Gesture events are not generated by default, you must call {Wx::Window#enable_touch_events} with the appropriate parameter to request their generation.
-  # 
-  # === 
+  # <div class="wxrb-note">
+  # <b>Note:</b>
+  # <p>Gesture events are not generated by default, you must call {Wx::Window#enable_touch_events} with the appropriate parameter to request their generation.
+  # </p>
+  # </div>
   # 
   # Category:  {Wx::Events}
   # @see Wx::PanGestureEvent
@@ -799,7 +804,7 @@ module Wx
   
     # Constructor.
     # @param winid [Integer] 
-    # @param type [Wx::CommandLinkButton::EventType] 
+    # @param type [Wx::Slider::EventType] 
     # @return [Wx::GestureEvent]
     def initialize(winid=0, type=Wx::EVT_NULL) end
     
@@ -839,17 +844,15 @@ module Wx
   end # GestureEvent
   
   # This event is generated when the user moves a finger on the surface.
-  # wxGTK also generates this event during mouse dragging (mouse motion while a left mouse button is depressed).
+  # WXGTK also generates this event during mouse dragging (mouse motion while a left mouse button is depressed).
   # Note that OSX requires the primary mouse button to be pressed while performing the finger movement.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::PanGestureEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_gesture_pan}(id, meth = nil, &block): Process a {Wx::EVT_GESTURE_PAN}. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # 
   class PanGestureEvent < GestureEvent
@@ -873,15 +876,13 @@ module Wx
   end # PanGestureEvent
   
   # This event is generated when two fingers pinch the surface to zoom in or out.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::ZoomGestureEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_gesture_zoom}(id, meth = nil, &block): Process a {Wx::EVT_GESTURE_ZOOM}. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # 
   class ZoomGestureEvent < GestureEvent
@@ -906,15 +907,13 @@ module Wx
   end # ZoomGestureEvent
   
   # This event is generated when two fingers move in opposite directions on the surface.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::RotateGestureEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_gesture_rotate}(id, meth = nil, &block): Process a {Wx::EVT_GESTURE_ROTATE}. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # 
   class RotateGestureEvent < GestureEvent
@@ -940,15 +939,13 @@ module Wx
   end # RotateGestureEvent
   
   # This event is generated when two fingers touch the surface at the same time.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::TwoFingerTapEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_two_finger_tap}(id, meth = nil, &block): Process a {Wx::EVT_TWO_FINGER_TAP}. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # 
   class TwoFingerTapEvent < GestureEvent
@@ -961,17 +958,15 @@ module Wx
   end # TwoFingerTapEvent
   
   # This event is generated when one finger touches the surface and remains stationary.
-  # Note that currently it is only generated under wxGTK and wxOSX.
-  # wxGTK also generates this event when left mouse button is being pressed for some minimum duration of time.
-  # === Events using this class
+  # Note that currently it is only generated under WXGTK and WXOSX.
+  # WXGTK also generates this event when left mouse button is being pressed for some minimum duration of time.
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::LongPressEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_long_press}(id, meth = nil, &block): Process a {Wx::EVT_LONG_PRESS}. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # 
   class LongPressEvent < GestureEvent
@@ -985,15 +980,13 @@ module Wx
   
   # This event is generated when the user press the surface with one finger and taps with another.
   # Note that once started the event will also be generated when the finger that was pressed moves on surface.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::PressAndTapEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_press_and_tap}(id, meth = nil, &block): Process a {Wx::EVT_PRESS_AND_TAP}. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # 
   class PressAndTapEvent < GestureEvent
@@ -1006,7 +999,7 @@ module Wx
   end # PressAndTapEvent
   
   # This event class contains information about key press and release events.
-  # The main information carried by this event is the key being pressed or released. It can be accessed using one of {Wx::KeyEvent#get_unicode_key}, {Wx::KeyEvent#get_key_code} or {Wx::KeyEvent#get_raw_key_code} functions. For the printable characters, {Wx::KeyEvent#get_unicode_key} should be used as it works for any keys, including non-Latin-1 characters that can be entered when using national keyboard layouts. {Wx::KeyEvent#get_key_code} should be used to handle special characters (such as cursor arrows keys or HOME or INS and so on) which correspond to {Wx::KeyCode} enum elements above the {Wx::K_START} constant. While {Wx::KeyEvent#get_key_code} also returns the character code for Latin-1 keys for compatibility, it doesn't work for Unicode characters in general and will return {Wx::K_NONE} for any non-Latin-1 ones. If both {Wx::KeyEvent#get_unicode_key} and {Wx::KeyEvent#get_key_code} return {Wx::K_NONE} then the key has no WXK_xxx mapping and {Wx::KeyEvent#get_raw_key_code} can be used to distinguish between keys, but raw key codes are platform specific. For these reasons, it is recommended to always use {Wx::KeyEvent#get_unicode_key} and only fall back to {Wx::KeyEvent#get_key_code} if {Wx::KeyEvent#get_unicode_key} returned {Wx::K_NONE}, meaning that the event corresponds to a non-printable special keys, then optionally check {Wx::KeyEvent#get_raw_key_code} if {Wx::KeyEvent#get_key_code} also returned {Wx::K_NONE} or simply ignore that key.
+  # The main information carried by this event is the key being pressed or released. It can be accessed using one of {Wx::KeyEvent#get_unicode_key}, {Wx::KeyEvent#get_key_code} or {Wx::KeyEvent#get_raw_key_code} functions. For the printable characters, {Wx::KeyEvent#get_unicode_key} should be used as it works for any keys, including non-Latin-1 characters that can be entered when using national keyboard layouts. {Wx::KeyEvent#get_key_code} should be used to handle special characters (such as cursor arrows keys or HOME or INS and so on) which correspond to {Wx::KeyCode} enum elements above the {Wx::KeyCode::K_START} constant. While {Wx::KeyEvent#get_key_code} also returns the character code for Latin-1 keys for compatibility, it doesn't work for Unicode characters in general and will return {Wx::KeyCode::K_NONE} for any non-Latin-1 ones. If both {Wx::KeyEvent#get_unicode_key} and {Wx::KeyEvent#get_key_code} return {Wx::KeyCode::K_NONE} then the key has no WXK_xxx mapping and {Wx::KeyEvent#get_raw_key_code} can be used to distinguish between keys, but raw key codes are platform specific. For these reasons, it is recommended to always use {Wx::KeyEvent#get_unicode_key} and only fall back to {Wx::KeyEvent#get_key_code} if {Wx::KeyEvent#get_unicode_key} returned {Wx::KeyCode::K_NONE}, meaning that the event corresponds to a non-printable special keys, then optionally check {Wx::KeyEvent#get_raw_key_code} if {Wx::KeyEvent#get_key_code} also returned {Wx::KeyCode::K_NONE} or simply ignore that key.
   # While these three functions can be used with the events of {Wx::EVT_KEY_DOWN}, {Wx::EVT_KEY_UP} and {Wx::EVT_CHAR} types, the values returned by them are different for the first two events and the last one. For the latter, the key returned corresponds to the character that would appear in e.g. a text zone if the user pressed the key in it. As such, its value depends on the current state of the Shift key and, for the letters, on the state of Caps Lock modifier. For example, if A key is pressed without Shift being held down, {Wx::KeyEvent} of type {Wx::EVT_CHAR} generated for this key press will return (from either {Wx::KeyEvent#get_key_code} or {Wx::KeyEvent#get_unicode_key} as their meanings coincide for ASCII characters) key code of 97 corresponding the ASCII value of a. And if the same key is pressed but with Shift being held (or Caps Lock being active), then the key could would be 65, i.e. ASCII value of capital A.
   # However for the key down and up events the returned key code will instead be A independently of the state of the modifier keys i.e. it depends only on physical key being pressed and is not translated to its logical representation using the current keyboard state. Such untranslated key codes are defined as follows:
   # 
@@ -1014,22 +1007,40 @@ module Wx
   # - For the other alphanumeric keys (e.g. 7 or <code>+</code>), the untranslated key code corresponds to the character produced by the key when it is pressed without Shift. E.g. in standard US keyboard layout the untranslated key code for the key <code>=/+</code> in the upper right corner of the keyboard is 61 which is the ASCII value of <code>=</code>.
   # - For the rest of the keys (i.e. special non-printable keys) it is the same as the normal key code as no translation is used anyhow.
   # 
-  # Notice that the first rule applies to all Unicode letters, not just the usual Latin-1 ones. However for non-Latin-1 letters only {Wx::KeyEvent#get_unicode_key} can be used to retrieve the key code as {Wx::KeyEvent#get_key_code} just returns {Wx::K_NONE} in this case.
+  # Notice that the first rule applies to all Unicode letters, not just the usual Latin-1 ones. However for non-Latin-1 letters only {Wx::KeyEvent#get_unicode_key} can be used to retrieve the key code as {Wx::KeyEvent#get_key_code} just returns {Wx::KeyCode::K_NONE} in this case.
   # Also, note that {Wx::EVT_CHAR} events are not generated for keys which do not have a wxWidgets mapping, so {Wx::KeyEvent#get_raw_key_code} should never be required for this event.
   # To summarize: you should handle {Wx::EVT_CHAR} if you need the translated key and {Wx::EVT_KEY_DOWN} if you only need the value of the key itself, independent of the current keyboard state.
-  # Not all key down events may be generated by the user. As an example, {Wx::EVT_KEY_DOWN} with <code>=</code> key code can be generated using the standard US keyboard layout but not using the German one because the <code>=</code> key corresponds to Shift-0 key combination in this layout and the key code for it is 0, not <code>=</code>. Because of this you should avoid requiring your users to type key events that might be impossible to enter on their keyboard.
   # 
-  # Another difference between key and char events is that another kind of translation is done for the latter ones when the Control key is pressed: char events for ASCII letters in this case carry codes corresponding to the ASCII value of Ctrl-Latter, i.e. 1 for Ctrl-A, 2 for Ctrl-B and so on until 26 for Ctrl-Z. This is convenient for terminal-like applications and can be completely ignored by all the other ones (if you need to handle Ctrl-A it is probably a better idea to use the key event rather than the char one). Notice that currently no translation is done for the presses of <code></code>[, <code>\</code>, <code></code>], <code>^</code> and _ keys which might be mapped to ASCII values from 27 to 31. Since version 2.9.2, the enum values {Wx::K_CONTROL}_A - {Wx::K_CONTROL}_Z can be used instead of the non-descriptive constant values 1-26.
-  # Finally, modifier keys only generate key events but no char events at all. The modifiers keys are {Wx::K_SHIFT}, {Wx::K_CONTROL}, {Wx::K_ALT} and various {Wx::K_WINDOWS}_XXX from {Wx::KeyCode} enum.
+  # <div class="wxrb-note">
+  # <b>Note:</b>
+  # <p>Not all key down events may be generated by the user. As an example, {Wx::EVT_KEY_DOWN} with <code>=</code> key code can be generated using the standard US keyboard layout but not using the German one because the <code>=</code> key corresponds to Shift-0 key combination in this layout and the key code for it is 0, not <code>=</code>. Because of this you should avoid requiring your users to type key events that might be impossible to enter on their keyboard.
+  # </p>
+  # </div>
+  # 
+  # Another difference between key and char events is that another kind of translation is done for the latter ones when the Control key is pressed: char events for ASCII letters in this case carry codes corresponding to the ASCII value of Ctrl-Latter, i.e. 1 for Ctrl-A, 2 for Ctrl-B and so on until 26 for Ctrl-Z. This is convenient for terminal-like applications and can be completely ignored by all the other ones (if you need to handle Ctrl-A it is probably a better idea to use the key event rather than the char one). Notice that currently no translation is done for the presses of <code></code>[, <code>\</code>, <code></code>], <code>^</code> and _ keys which might be mapped to ASCII values from 27 to 31. Since version 2.9.2, the enum values {Wx::KeyCode::K_CONTROL}_A - {Wx::KeyCode::K_CONTROL}_Z can be used instead of the non-descriptive constant values 1-26.
+  # Finally, modifier keys only generate key events but no char events at all. The modifiers keys are {Wx::KeyCode::K_SHIFT}, {Wx::KeyCode::K_CONTROL}, {Wx::KeyCode::K_ALT} and various {Wx::KeyCode::K_WINDOWS}_XXX from {Wx::KeyCode} enum.
   # Modifier keys events are special in one additional aspect: usually the keyboard state associated with a key press is well defined, e.g. {Wx::KeyboardState#shift_down} returns true only if the Shift key was held pressed when the key that generated this event itself was pressed. There is an ambiguity for the key press events for Shift key itself however. By convention, it is considered to be already pressed when it is pressed and already released when it is released. In other words, {Wx::EVT_KEY_DOWN} event for the Shift key itself will have {Wx::KeyModifier::MOD_SHIFT} in {Wx::KeyEvent#get_modifiers} and {Wx::KeyEvent#shift_down} will return true while the {Wx::EVT_KEY_UP} event for Shift itself will not have {Wx::KeyModifier::MOD_SHIFT} in its modifiers and {Wx::KeyEvent#shift_down} will return false.
   # <b>Tip:</b> You may discover the key codes and modifiers generated by all the keys on your system interactively by running the Key Event Sample wxWidgets sample and pressing some keys in it.
-  # If a key down (EVT_KEY_DOWN) event is caught and the event handler does not call <code>event.Skip()</code> then the corresponding char event (EVT_CHAR) will not happen. This is by design and enables the programs that handle both types of events to avoid processing the same key twice. As a consequence, if you do not want to suppress the {Wx::EVT_CHAR} events for the keys you handle, always call <code>event.Skip()</code> in your {Wx::EVT_KEY_DOWN} handler. Not doing may also prevent accelerators defined using this key from working.
   # 
-  # If a key is maintained in a pressed state, you will typically get a lot of (automatically generated) key down events but only one key up one at the end when the key is released so it is wrong to assume that there is one up event corresponding to each down one.
+  # <div class="wxrb-note">
+  # <b>Note:</b>
+  # <p>If a key down (EVT_KEY_DOWN) event is caught and the event handler does not call <code>event.Skip()</code> then the corresponding char event (EVT_CHAR) will not happen. This is by design and enables the programs that handle both types of events to avoid processing the same key twice. As a consequence, if you do not want to suppress the {Wx::EVT_CHAR} events for the keys you handle, always call <code>event.Skip()</code> in your {Wx::EVT_KEY_DOWN} handler. Not doing may also prevent accelerators defined using this key from working.
+  # </p>
+  # </div>
+  # 
+  # <div class="wxrb-note">
+  # <b>Note:</b>
+  # <p>If a key is maintained in a pressed state, you will typically get a lot of (automatically generated) key down events but only one key up one at the end when the key is released so it is wrong to assume that there is one up event corresponding to each down one.
+  # </p>
+  # </div>
   # 
-  # For Windows programmers: The key and char events in wxWidgets are similar to but slightly different from Windows WM_KEYDOWN and WM_CHAR events. In particular, Alt-x combination will generate a char event in wxWidgets (unless it is used as an accelerator) and almost all keys, including ones without ASCII equivalents, generate char events too.
+  # <div class="wxrb-note">
+  # <b>Note:</b>
+  # <p>For Windows programmers: The key and char events in wxWidgets are similar to but slightly different from Windows WM_KEYDOWN and WM_CHAR events. In particular, Alt-x combination will generate a char event in wxWidgets (unless it is used as an accelerator) and almost all keys, including ones without ASCII equivalents, generate char events too.
+  # </p>
+  # </div>
   # 
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::KeyEvent} events.
   # Event handler methods:
@@ -1042,8 +1053,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_char_hook}(meth = nil, &block): Process a {Wx::EVT_CHAR_HOOK} event. Unlike all the other key events, this event is propagated upwards the window hierarchy which allows intercepting it in the parent window of the focused window to which it is sent initially (if there is no focused window, this event is sent to the {Wx::App} global object). It is also generated before any other key events and so gives the parent window an opportunity to modify the keyboard handling of its children, e.g. it is used internally by wxWidgets in some ports to intercept pressing Esc key in any child of a dialog to close the dialog itself when it's pressed. By default, if this event is handled, i.e. the handler doesn't call {Wx::Event#skip}, neither {Wx::EVT_KEY_DOWN} nor {Wx::EVT_CHAR} events will be generated (although {Wx::EVT_KEY_UP} still will be), i.e. it replaces the normal key events. However by calling the special {Wx::KeyEvent#do_allow_next_event} method you can handle {Wx::EVT_CHAR_HOOK} and still allow normal events generation. This is something that is rarely useful but can be required if you need to prevent a parent {Wx::EVT_CHAR_HOOK} handler from running without suppressing the normal key events. Finally notice that this event is not generated when the mouse is captured as it is considered that the window which has the capture should receive all the keyboard events too without allowing its parent {Wx::TopLevelWindow} to interfere with their processing. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::KeyboardState
   # 
@@ -1059,14 +1068,14 @@ module Wx
     
     # Constructor.
     # Currently, the only valid event types are {Wx::EVT_CHAR} and {Wx::EVT_CHAR_HOOK}.
-    # @param keyEventType [Wx::CommandLinkButton::EventType] 
+    # @param keyEventType [Wx::Slider::EventType] 
     # @return [Wx::KeyEvent]
     def initialize(keyEventType=Wx::EVT_NULL) end
     
     # Returns the key code of the key that generated this event.
-    # ASCII symbols return normal ASCII values, while events from special keys such as "left cursor arrow" ({Wx::K_LEFT}) return values outside of the ASCII range. See {Wx::KeyCode} for a full list of the virtual key codes.
-    # Note that this method returns a meaningful value only for special non-alphanumeric keys or if the user entered a Latin-1 character (this includes ASCII and the accented letters found in Western European languages but not letters of other alphabets such as e.g. Cyrillic). Otherwise it simply method returns {Wx::K_NONE} and {Wx::KeyEvent#get_unicode_key} should be used to obtain the corresponding Unicode character.
-    # Using {Wx::KeyEvent#get_unicode_key} is in general the right thing to do if you are interested in the characters typed by the user, {Wx::KeyEvent#get_key_code} should be only used for special keys (for which {Wx::KeyEvent#get_unicode_key} returns nil). To handle both kinds of keys you might write: 
+    # ASCII symbols return normal ASCII values, while events from special keys such as "left cursor arrow" ({Wx::KeyCode::K_LEFT}) return values outside of the ASCII range. See {Wx::KeyCode} for a full list of the virtual key codes.
+    # Note that this method returns a meaningful value only for special non-alphanumeric keys or if the user entered a Latin-1 character (this includes ASCII and the accented letters found in Western European languages but not letters of other alphabets such as e.g. Cyrillic). Otherwise it simply method returns {Wx::KeyCode::K_NONE} and {Wx::KeyEvent#get_unicode_key} should be used to obtain the corresponding Unicode character.
+    # Using {Wx::KeyEvent#get_unicode_key} is in general the right thing to do if you are interested in the characters typed by the user, {Wx::KeyEvent#get_key_code} should be only used for special keys (for which {Wx::KeyEvent#get_unicode_key} returns {Wx::KeyCode::K_NONE}). To handle both kinds of keys you might write: 
     # ```ruby
     #   def on_char(event)
     #      uc = event.get_unicode_key
@@ -1112,7 +1121,12 @@ module Wx
     # Under MSW, the raw key code is the value of wParam parameter of the corresponding message.
     # Under GTK, the raw key code is the keyval field of the corresponding GDK event.
     # Under macOS, the raw key code is the keyCode field of the corresponding NSEvent.
-    # Currently the raw key codes are not supported by all ports, use #ifdef {Wx::HAS_RAW_KEY_CODES} to determine if this feature is available.
+    # 
+    # <div class="wxrb-note">
+    # <b>Note:</b>
+    # <p>Currently the raw key codes are not supported by all ports, use \#ifdef {Wx::HAS_RAW_KEY_CODES} to determine if this feature is available. 
+    # </p>
+    # </div>
     # @return [Integer]
     def get_raw_key_code; end
     alias_method :raw_key_code, :get_raw_key_code
@@ -1122,13 +1136,18 @@ module Wx
     # Under MSW, the raw flags are just the value of lParam parameter of the corresponding message.
     # Under GTK, the raw flags contain the hardware_keycode field of the corresponding GDK event.
     # Under macOS, the raw flags contain the modifiers state.
-    # Currently the raw key flags are not supported by all ports, use #ifdef {Wx::HAS_RAW_KEY_CODES} to determine if this feature is available.
+    # 
+    # <div class="wxrb-note">
+    # <b>Note:</b>
+    # <p>Currently the raw key flags are not supported by all ports, use \#ifdef {Wx::HAS_RAW_KEY_CODES} to determine if this feature is available. 
+    # </p>
+    # </div>
     # @return [Integer]
     def get_raw_key_flags; end
     alias_method :raw_key_flags, :get_raw_key_flags
     
     # Returns the Unicode character corresponding to this key event.
-    # If the key pressed doesn't have any character value (e.g. a cursor key) this method will return nil. In this case you should use {Wx::KeyEvent#get_key_code} to retrieve the value of the key.
+    # If the key pressed doesn't have any character value (e.g. a cursor key) this method will return {Wx::KeyCode::K_NONE}. In this case you should use {Wx::KeyEvent#get_key_code} to retrieve the value of the key.
     # This function is only available in Unicode build, i.e. when {Wx::Setup::USE_UNICODE} is 1.
     # @return [String]
     def get_unicode_key; end
@@ -1263,15 +1282,13 @@ module Wx
   # Note that the size passed is of the whole window: call {Wx::Window#get_client_size} for the area which may be used by the application.
   # When a window is resized, usually only a small part of the window is damaged and you may only need to repaint that area. However, if your drawing depends on the size of the window, you may need to clear the DC explicitly and repaint the whole window. In which case, you may need to call {Wx::Window#refresh} to invalidate the entire window.
   # <b>Important</b> : Sizers ( see Sizers Overview ) rely on size events to function correctly. Therefore, in a sizer-based layout, do not forget to call Skip on all size events you catch (and don't catch size events at all when you don't need to).
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::SizeEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_size}(meth = nil, &block): Process a {Wx::EVT_SIZE} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::Size
   # @see  Events and Event Handling 
@@ -1308,21 +1325,19 @@ module Wx
   end # SizeEvent
   
   # A move event holds information about window position change.
-  # These events are currently generated for top level (see {Wx::TopLevelWindow}) windows in all ports, but are not generated for the child windows in wxGTK.
-  # === Events using this class
+  # These events are currently generated for top level (see {Wx::TopLevelWindow}) windows in all ports, but are not generated for the child windows in WXGTK.
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::MoveEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_move}(meth = nil, &block): Process a {Wx::EVT_MOVE} event, which is generated when a window is moved. 
   # 
-  # - {Wx::EvtHandler#evt_move_start}(meth = nil, &block): Process a {Wx::EVT_MOVE_START} event, which is generated when the user starts to move or size a window. wxMSW only. 
-  # 
-  # - {Wx::EvtHandler#evt_moving}(meth = nil, &block): Process a {Wx::EVT_MOVING} event, which is generated while the user is moving the window. wxMSW only. 
+  # - {Wx::EvtHandler#evt_move_start}(meth = nil, &block): Process a {Wx::EVT_MOVE_START} event, which is generated when the user starts to move or size a window. WXMSW only. 
   # 
-  # - {Wx::EvtHandler#evt_move_end}(meth = nil, &block): Process a {Wx::EVT_MOVE_END} event, which is generated when the user stops moving or sizing a window. wxMSW only. 
+  # - {Wx::EvtHandler#evt_moving}(meth = nil, &block): Process a {Wx::EVT_MOVING} event, which is generated while the user is moving the window. WXMSW only. 
   # 
-  # === 
+  # - {Wx::EvtHandler#evt_move_end}(meth = nil, &block): Process a {Wx::EVT_MOVE_END} event, which is generated when the user stops moving or sizing a window. WXMSW only. 
   # 
   # Category:  {Wx::Events}
   # @see Wx::Point
@@ -1378,10 +1393,6 @@ module Wx
   #       vb_pt = get_view_start # Top left corner of client
   #     
   #       Wx::RegionIterator.for_region(get_update_region) do |region_it|
-  # 
-  #         int vX,vY,vW,vH                 
-  #         wxRegionIterator upd(GetUpdateRegion()) # get the update rect list
-  #     
   #         region_it.each do |rct|
   #           # rct == Dimensions of client area to repaint in pixels
   #     
@@ -1393,17 +1404,19 @@ module Wx
   #   end
   # ```
   # 
-  # Please notice that in general it is impossible to change the drawing of a standard control (such as {Wx::Button}) and so you shouldn't attempt to handle paint events for them as even if it might work on some platforms, this is inherently not portable and won't work everywhere.
+  # <div class="wxrb-remark">
+  # <b>Remark:</b>
+  # <p>Please notice that in general it is impossible to change the drawing of a standard control (such as {Wx::Button}) and so you shouldn't attempt to handle paint events for them as even if it might work on some platforms, this is inherently not portable and won't work everywhere.
+  # </p>
+  # </div>>
   # 
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::PaintEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_paint}(meth = nil, &block): Process a {Wx::EVT_PAINT} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling 
   # 
@@ -1422,15 +1435,13 @@ module Wx
   # On some platforms, such as GTK+, this event is simulated (simply generated just before the paint event) and may cause flicker. It is therefore recommended that you set the text background colour explicitly in order to prevent flicker. The default background colour under GTK+ is grey.
   # To intercept this event, use the EVT_ERASE_BACKGROUND macro in an event table definition.
   # You must use the device context returned by {Wx::EraseEvent#get_dc} to draw on, don't create a {Wx::PaintDC} in the event handler.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::EraseEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_erase_background}(meth = nil, &block): Process a {Wx::EVT_ERASE_BACKGROUND} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling 
   # 
@@ -1455,7 +1466,7 @@ module Wx
   # The window losing focus receives a "kill focus" event while the window gaining it gets a "set focus" one.
   # Notice that the set focus event happens both when the user gives focus to the window (whether using the mouse or keyboard) and when it is done from the program itself using {Wx::Window#set_focus}.
   # The focus event handlers should almost invariably call {Wx::Event#skip} on their event argument to allow the default handling to take place. Failure to do this may result in incorrect behaviour of the native controls. Also note that {Wx::EVT_KILL_FOCUS} handler must not call {Wx::Window#set_focus} as this, again, is not supported by all native controls. If you need to do this, consider using the Delayed Action Mechanism described in {Wx::IdleEvent} documentation.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::FocusEvent} events.
   # Event handler methods:
@@ -1464,8 +1475,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_kill_focus}(meth = nil, &block): Process a {Wx::EVT_KILL_FOCUS} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling 
   # 
@@ -1473,7 +1482,7 @@ module Wx
   class FocusEvent < Event
   
     # Constructor.
-    # @param eventType [Wx::CommandLinkButton::EventType] 
+    # @param eventType [Wx::Slider::EventType] 
     # @param id [Integer] 
     # @return [Wx::FocusEvent]
     def initialize(eventType=Wx::EVT_NULL, id=0) end
@@ -1492,7 +1501,7 @@ module Wx
   end # FocusEvent
   
   # An activate event is sent when a window or application is being activated or deactivated.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::ActivateEvent} events.
   # Event handler methods:
@@ -1503,9 +1512,11 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_hibernate}(meth = nil, &block): Process a hibernate event, supplying the member function. This event applies to {Wx::App} only, and only on Windows SmartPhone and PocketPC. It is generated when the system is low on memory; the application should free up as much memory as possible, and restore full working state when it receives a {Wx::EVT_ACTIVATE} or {Wx::EVT_ACTIVATE_APP} event. 
   # 
-  # Until wxWidgets 3.1.0 activation events could be sent by wxMSW when the window was minimized. This reflected the native MSW behaviour but was often surprising and unexpected, so starting from 3.1.0 such events are not sent any more when the window is in the minimized state.
-  # 
-  # === 
+  # <div class="wxrb-note">
+  # <b>Note:</b>
+  # <p>Until wxWidgets 3.1.0 activation events could be sent by WXMSW when the window was minimized. This reflected the native MSW behaviour but was often surprising and unexpected, so starting from 3.1.0 such events are not sent any more when the window is in the minimized state.
+  # </p>
+  # </div>
   # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling
@@ -1531,7 +1542,7 @@ module Wx
     end # Reason
     
     # Constructor.
-    # @param eventType [Wx::CommandLinkButton::EventType] 
+    # @param eventType [Wx::Slider::EventType] 
     # @param active [Boolean] 
     # @param id [Integer] 
     # @param activationReason [Wx::wxActivateEvent::Reason] 
@@ -1544,7 +1555,7 @@ module Wx
     alias_method :active, :get_active
     
     # Allows checking if the window was activated by clicking it with the mouse or in some other way.
-    # This method is currently only implemented in wxMSW and returns Reason_Mouse there if the window was activated by a mouse click and Reason_Unknown if it was activated in any other way (e.g. from keyboard or programmatically).
+    # This method is currently only implemented in WXMSW and returns Reason_Mouse there if the window was activated by a mouse click and Reason_Unknown if it was activated in any other way (e.g. from keyboard or programmatically).
     # Under all the other platforms, Reason_Unknown is always returned.
     # @return [Wx::wxActivateEvent::Reason]
     def get_activation_reason; end
@@ -1555,15 +1566,13 @@ module Wx
   # A {Wx::InitDialogEvent} is sent as a dialog or panel is being initialised.
   # Handlers for this event can transfer data to the window.
   # The default handler calls {Wx::Window#transfer_data_to_window}.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::InitDialogEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_init_dialog}(meth = nil, &block): Process a {Wx::EVT_INIT_DIALOG} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling 
   # 
@@ -1588,7 +1597,7 @@ module Wx
   # 
   # This is similar to command events generated by the menu items, but, unlike them, {Wx::MenuEvent} are only sent to the window itself and its top level parent but not any intermediate windows in the hierarchy.
   # The default handler for {Wx::EVT_MENU_HIGHLIGHT} in {Wx::Frame} displays help text in the status bar, see {Wx::Frame#set_status_bar_pane}.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::MenuEvent} events.
   # Event handler methods:
@@ -1601,8 +1610,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_menu_highlight_all}(meth = nil, &block): A menu item has been highlighted, i.e. the currently selected menu item has changed. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::CommandEvent
   # @see  Events and Event Handling 
@@ -1611,15 +1618,20 @@ module Wx
   class MenuEvent < Event
   
     # Constructor.
-    # @param type [Wx::CommandLinkButton::EventType] 
+    # @param type [Wx::Slider::EventType] 
     # @param id [Integer] 
     # @param menu [Wx::Menu] 
     # @return [Wx::MenuEvent]
     def initialize(type=Wx::EVT_NULL, id=0, menu=nil) end
     
     # Returns the menu which is being opened or closed, or the menu containing the highlighted item.
-    # Note that the returned value can be NULL if the menu being opened doesn't have a corresponding {Wx::Menu}, e.g. this happens when opening the system menu in wxMSW port.
-    # Since 3.1.3 this function can be used with OPEN, CLOSE and HIGHLIGHT events. Before 3.1.3, this method can only be used with the OPEN and CLOSE events.
+    # Note that the returned value can be NULL if the menu being opened doesn't have a corresponding {Wx::Menu}, e.g. this happens when opening the system menu in WXMSW port.
+    # 
+    # <div class="wxrb-remark">
+    # <b>Remark:</b>
+    # <p>Since 3.1.3 this function can be used with OPEN, CLOSE and HIGHLIGHT events. Before 3.1.3, this method can only be used with the OPEN and CLOSE events. 
+    # </p>
+    # </div>>
     # @return [Wx::Menu]
     def get_menu; end
     alias_method :menu, :get_menu
@@ -1663,7 +1675,7 @@ module Wx
   # 
   # See also <code>samples/dialogs</code> for a full example of interrupting closing an application when there are e.g. unsaved files.
   # The EVT_END_SESSION event is slightly different as it is sent by the system when the user session is ending (e.g. because of log out or shutdown) and so all windows are being forcefully closed. At least under MSW, after the handler for this event is executed the program is simply killed by the system. Because of this, the default handler for this event provided by wxWidgets calls all the usual cleanup code (including {Wx::App#on_exit}) so that it could still be executed and exit()s the process itself, without waiting for being killed. If this behaviour is for some reason undesirable, make sure that you define a handler for this event in your {Wx::App}-derived class and do not call <code>event.Skip()</code> in it (but be aware that the system will still kill your application).
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::CloseEvent} events.
   # Event handler methods:
@@ -1674,8 +1686,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_end_session}(meth = nil, &block): Process a {Wx::EVT_END_SESSION} session event, supplying the member function. This event can be handled in {Wx::App}-derived class only. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::Window#close
   # @see  Window Deletion 
@@ -1684,7 +1694,7 @@ module Wx
   class CloseEvent < Event
   
     # Constructor.
-    # @param commandEventType [Wx::CommandLinkButton::EventType] 
+    # @param commandEventType [Wx::Slider::EventType] 
     # @param id [Integer] 
     # @return [Wx::CloseEvent]
     def initialize(commandEventType=Wx::EVT_NULL, id=0) end
@@ -1726,16 +1736,14 @@ module Wx
   end # CloseEvent
   
   # An event being sent when the window is shown or hidden.
-  # The event is triggered by calls to {Wx::Window#show}, and any user action showing a previously hidden window or vice versa (if allowed by the current platform and/or window manager). Notice that the event is not triggered when the application is iconized (minimized) or restored under wxMSW.
-  # === Events using this class
+  # The event is triggered by calls to {Wx::Window#show}, and any user action showing a previously hidden window or vice versa (if allowed by the current platform and/or window manager). Notice that the event is not triggered when the application is iconized (minimized) or restored under WXMSW.
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::ShowEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_show}(meth = nil, &block): Process a {Wx::EVT_SHOW} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling
   # @see  Wx::Window#show
@@ -1764,15 +1772,13 @@ module Wx
   end # ShowEvent
   
   # An event being sent when the frame is iconized (minimized) or restored.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::IconizeEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_iconize}(meth = nil, &block): Process a {Wx::EVT_ICONIZE} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling
   # @see  Wx::TopLevelWindow#iconize
@@ -1796,16 +1802,14 @@ module Wx
   
   # An event being sent when a top level window is maximized.
   # Notice that it is not sent when the window is restored to its original size after it had been maximized, only a normal {Wx::SizeEvent} is generated in this case.
-  # Currently this event is only generated in wxMSW, wxGTK and wxOSX/Cocoa ports so portable programs should only rely on receiving {Wx::EVT_SIZE} and not necessarily this event when the window is maximized.
-  # === Events using this class
+  # Currently this event is only generated in WXMSW, WXGTK and WXOSX/Cocoa ports so portable programs should only rely on receiving {Wx::EVT_SIZE} and not necessarily this event when the window is maximized.
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::MaximizeEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_maximize}(meth = nil, &block): Process a {Wx::EVT_MAXIMIZE} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling
   # @see  Wx::TopLevelWindow#maximize
@@ -1823,16 +1827,14 @@ module Wx
   end # MaximizeEvent
   
   # An event being sent when the user enters or exits full screen mode.
-  # Currently this event is only generated in the wxOSX/Cocoa port when {Wx::TopLevelWindow#enable_full_screen_view} is enabled and the user the user enters or exits full screen. Note that this event is not generated when {Wx::TopLevelWindow#show_full_screen}.
-  # === Events using this class
+  # Currently this event is only generated in the WXOSX/Cocoa port when {Wx::TopLevelWindow#enable_full_screen_view} is enabled and the user the user enters or exits full screen. Note that this event is not generated when {Wx::TopLevelWindow#show_full_screen}.
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::FullScreenEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_fullscreen}(meth = nil, &block): Process a {Wx::EVT_FULLSCREEN} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling
   # @see  Wx::TopLevelWindow#enable_full_screen_view
@@ -1855,7 +1857,7 @@ module Wx
   end # FullScreenEvent
   
   # This event class contains information about joystick events, particularly events received by windows.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::JoystickEvent} events.
   # Event handler methods:
@@ -1870,8 +1872,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_joystick_events}(meth = nil, &block): Processes all joystick events. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::Joystick 
   # 
@@ -1879,7 +1879,7 @@ module Wx
   class JoystickEvent < Event
   
     # Constructor.
-    # @param eventType [Wx::CommandLinkButton::EventType] 
+    # @param eventType [Wx::Slider::EventType] 
     # @param state [Integer] 
     # @param joystick [Integer] 
     # @param change [Integer] 
@@ -1962,16 +1962,18 @@ module Wx
   # This class is used for drop files events, that is, when files have been dropped onto the window.
   # The window must have previously been enabled for dropping by calling {Wx::Window#drag_accept_files}.
   # Important note: this is a separate implementation to the more general drag and drop implementation documented in the Drag and Drop Overview. It uses the older, Windows message-based approach of dropping files.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::DropFilesEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_drop_files}(meth = nil, &block): Process a {Wx::EVT_DROP_FILES} event. 
   # 
-  # Windows only until version 2.8.9, available on all platforms since 2.8.10.
-  # 
-  # === 
+  # <div class="wxrb-remark">
+  # <b>Remark:</b>
+  # <p>Windows only until version 2.8.9, available on all platforms since 2.8.10.
+  # </p>
+  # </div>>
   # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling
@@ -1981,7 +1983,7 @@ module Wx
   class DropFilesEvent < Event
   
     # Constructor.
-    # @param id [Wx::CommandLinkButton::EventType] 
+    # @param id [Wx::Slider::EventType] 
     # @param noFiles [Integer] 
     # @param files [String] 
     # @return [Wx::DropFilesEvent]
@@ -2018,7 +2020,7 @@ module Wx
   # 
   # Note that although events are sent in idle time, defining a {Wx::IdleEvent} handler for a window does not affect this because the events are sent from {Wx::Window#on_internal_idle} which is always called in idle time.
   # wxWidgets tries to optimize update events on some platforms. On Windows and GTK+, events for menubar items are only sent when the menu is about to be shown, and not in idle time.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::UpdateUIEvent} events.
   # Event handler methods:
@@ -2027,8 +2029,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_update_ui_range}(id1,  id2, meth = nil, &block): Process a {Wx::EVT_UPDATE_UI} event for any command with id included in the given range. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling 
   # 
@@ -2162,17 +2162,20 @@ module Wx
   
   # This class is used for system colour change events, which are generated when the user changes the colour settings or when the system theme changes (e.g. automatic dark mode switching on macOS).
   # Event handlers for this event can access the new system colour settings through {Wx::SystemSettings.get_colour}.
-  # The default event handler for this event propagates the event to child windows, since the system events are only sent to top-level windows. If intercepting this event for a top-level window, remember to either call {Wx::Event#skip} on the event, call the base class handler, or pass the event on to the window's children explicitly.
   # 
-  # === Events using this class
+  # <div class="wxrb-remark">
+  # <b>Remark:</b>
+  # <p>The default event handler for this event propagates the event to child windows, since the system events are only sent to top-level windows. If intercepting this event for a top-level window, remember to either call {Wx::Event#skip} on the event, call the base class handler, or pass the event on to the window's children explicitly.
+  # </p>
+  # </div>>
+  # 
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::SysColourChangedEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_sys_colour_changed}(meth = nil, &block): Process a {Wx::EVT_SYS_COLOUR_CHANGED} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling 
   # 
@@ -2187,16 +2190,14 @@ module Wx
   
   # A mouse capture changed event is sent to a window that loses its mouse capture.
   # This is called even if {Wx::Window#release_mouse} was called by the application code. Handling this event allows an application to cater for unexpected capture releases which might otherwise confuse mouse handling code.
-  # Availability:  only available for the wxMSW port.  {Wx::msw} 
-  # === Events using this class
+  # Availability:  only available for the WXMSW port.   
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::MouseCaptureChangedEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_mouse_capture_changed}(meth = nil, &block): Process a {Wx::EVT_MOUSE_CAPTURE_CHANGED} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::MouseCaptureLostEvent
   # @see  Events and Event Handling
@@ -2223,15 +2224,14 @@ module Wx
   # A mouse capture lost event is sent to a window that had obtained mouse capture, which was subsequently lost due to an "external" event (for example, when a dialog box is shown or if another application captures the mouse).
   # If this happens, this event is sent to all windows that are on the capture stack (i.e. called CaptureMouse, but didn't call ReleaseMouse yet). The event is not sent if the capture changes because of a call to CaptureMouse or ReleaseMouse.
   # This event is currently emitted under Windows only.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::MouseCaptureLostEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_mouse_capture_lost}(meth = nil, &block): Process a {Wx::EVT_MOUSE_CAPTURE_LOST} event. 
   # 
-  # Availability:  only available for the wxMSW port.  {Wx::msw} 
-  # === 
+  # Availability:  only available for the WXMSW port.   
   # 
   # Category:  {Wx::Events}
   # @see Wx::MouseCaptureChangedEvent
@@ -2252,15 +2252,14 @@ module Wx
   
   # A display changed event is sent to top-level windows when the display resolution has changed.
   # This event is currently emitted under Windows only.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::DisplayChangedEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_display_changed}(meth = nil, &block): Process a {Wx::EVT_DISPLAY_CHANGED} event. 
   # 
-  # Availability:  only available for the wxMSW port.  {Wx::msw} 
-  # === 
+  # Availability:  only available for the WXMSW port.   
   # 
   # Category:  {Wx::Events}
   # @see Wx::Display 
@@ -2276,16 +2275,14 @@ module Wx
   # Event sent when the display scale factor or pixel density (measured in dots-per-inch, or DPI) of the monitor a window is on changes.
   # The event is sent to each {Wx::TopLevelWindow} affected by the change, and all its children recursively (post-order traversal). For example, this event is sent to the window when it is moved, by the user, from a display using some DPI value to another display using a different DPI value. It also sent to all program windows on the given display if its DPI changes due to a change in the system settings.
   # If you define an event handler for this event, you should almost always call <code>event.Skip()</code> in it in order to allow the base class handler to execute, as many controls rely on processing this event in order to update their appearance when the DPI changes. However the default handler for the top level window itself only sets the new window size, by scaling the current size by the DPI ratio  e.g. doubling it if the DPI has changed from normal to "high", i.e. 200%, one  and also ensuring that the window is still bigger than its best size, as returned by {Wx::Window#get_best_size}. Note that in some cases this may cause the window size to grow unexpectedly and you may prefer to call {Wx::Window#set_size} in your handler of this event for the top level window and not call <code>event.Skip()</code> to prevent the default handler from resizing the window.
-  # Currently this event is generated by wxMSW port if only and only if the MSW application runs under Windows 10 Creators Update (v1703) or later and is marked as being "per-monitor DPI aware", i.e. contains a dpiAwareness tag with the value "PerMonitorV2" in its manifest (see Microsoft "Application Manifests" documentation for more details).
-  # === Events using this class
+  # Currently this event is generated by WXMSW port if only and only if the MSW application runs under Windows 10 Creators Update (v1703) or later and is marked as being "per-monitor DPI aware", i.e. contains a dpiAwareness tag with the value "PerMonitorV2" in its manifest (see Microsoft "Application Manifests" documentation for more details).
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::DPIChangedEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_dpi_changed}(meth = nil, &block): Process a {Wx::EVT_DPI_CHANGED} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling 
   # 
@@ -2365,15 +2362,13 @@ module Wx
   
   # This event class contains information about navigation events, generated by navigation keys such as tab and page down.
   # This event is mainly used by wxWidgets implementations. A {Wx::NavigationKeyEvent} handler is automatically provided by wxWidgets when you enable keyboard navigation inside a window by inheriting it from {Wx::NavigationEnabled}<>.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::NavigationKeyEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_navigation_key}(meth = nil, &block): Process a navigation key event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::Window#navigate
   # @see  Wx::Window#navigate_in 
@@ -2468,15 +2463,13 @@ module Wx
   
   # This event is sent just after the actual window associated with a {Wx::Window} object has been created.
   # Since it is derived from {Wx::CommandEvent}, the event propagates up the window hierarchy.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::WindowCreateEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_window_create}(meth = nil, &block): Process a {Wx::EVT_CREATE} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling
   # @see  Wx::WindowDestroyEvent 
@@ -2500,7 +2493,6 @@ module Wx
   # For the top level windows, as early as possible means that this is done by {Wx::Frame} or {Wx::Dialog} destructor, i.e. after the destructor of the derived class was executed and so any methods specific to the derived class can't be called any more from this event handler. If you need to do this, you must call {Wx::Window#send_destroy_event} from your derived class destructor.
   # For the child windows, this event is generated just before deleting the window from {Wx::Window#destroy} (which is also called when the parent window is deleted) or from the window destructor if operator delete was used directly (which is not recommended for this very reason).
   # It is usually pointless to handle this event in the window itself but it ca be very useful to receive notifications about the window destruction in the parent window or in any other object interested in this window.
-  # === 
   # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling
@@ -2526,7 +2518,7 @@ module Wx
   # A help event is sent to the window that the user clicked on, and is propagated up the window hierarchy until the event is processed or there are no more event handlers.
   # The application should call {Wx::Event#get_id} to check the identity of the clicked-on window, and then either show some suitable help or call {Wx::Event#skip} if the identifier is unrecognised.
   # Calling Skip is important because it allows wxWidgets to generate further events for ancestors of the clicked-on window. Otherwise it would be impossible to show help for container windows, since processing would stop after the first window found.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::HelpEvent} events.
   # Event handler methods:
@@ -2535,8 +2527,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_help_range}(id1,  id2, meth = nil, &block): Process a {Wx::EVT_HELP} event for a range of ids. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::ContextHelp
   # @see  Wx::Dialog
@@ -2566,7 +2556,7 @@ module Wx
     end # Origin
     
     # Constructor.
-    # @param type [Wx::CommandLinkButton::EventType] 
+    # @param type [Wx::Slider::EventType] 
     # @param winid [Integer] 
     # @param pt [Array(Integer, Integer), Wx::Point] 
     # @param origin [Wx::wxHelpEvent::Origin] 
@@ -2606,9 +2596,14 @@ module Wx
   # There are three types of corresponding events {Wx::EVT_TEXT_COPY}, {Wx::EVT_TEXT_CUT} and {Wx::EVT_TEXT_PASTE}.
   # If any of these events is processed (without being skipped) by an event handler, the corresponding operation doesn't take place which allows preventing the text from being copied from or pasted to a control. It is also possible to examine the clipboard contents in the PASTE event handler and transform it in some way before inserting in a control  for example, changing its case or removing invalid characters.
   # Finally notice that a CUT event is always preceded by the COPY event which makes it possible to only process the latter if it doesn't matter if the text was copied or cut.
-  # These events are currently only generated by {Wx::TextCtrl} in wxGTK and wxOSX but are also generated by {Wx::ComboBox} without {Wx::CB_READONLY} style in wxMSW.
   # 
-  # === Events using this class
+  # <div class="wxrb-note">
+  # <b>Note:</b>
+  # <p>These events are currently only generated by {Wx::TextCtrl} in WXGTK and WXOSX but are also generated by {Wx::ComboBox} without {Wx::CB_READONLY} style in WXMSW.
+  # </p>
+  # </div>
+  # 
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::ClipboardTextEvent} events.
   # Event handler methods:
@@ -2619,8 +2614,6 @@ module Wx
   # 
   # - {Wx::EvtHandler#evt_text_paste}(id, meth = nil, &block): Clipboard content was pasted into the control. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::Clipboard 
   # 
@@ -2628,7 +2621,7 @@ module Wx
   class ClipboardTextEvent < CommandEvent
   
     # Constructor.
-    # @param commandType [Wx::CommandLinkButton::EventType] 
+    # @param commandType [Wx::Slider::EventType] 
     # @param id [Integer] 
     # @return [Wx::ClipboardTextEvent]
     def initialize(commandType=Wx::EVT_NULL, id=0) end
@@ -2638,15 +2631,13 @@ module Wx
   # This class is used for context menu events, sent to give the application a chance to show a context (popup) menu for a {Wx::Window}.
   # Note that if {Wx::ContextMenuEvent#get_position} returns {Wx::DEFAULT_POSITION}, this means that the event originated from a keyboard context button event, and you should compute a suitable position yourself, for example by calling {get_mouse_position}.
   # Notice that the exact sequence of mouse events is different across the platforms. For example, under MSW the context menu event is generated after EVT_RIGHT_UP event and only if it was not handled but under GTK the context menu event is generated after EVT_RIGHT_DOWN event. This is correct in the sense that it ensures that the context menu is shown according to the current platform UI conventions and also means that you must not handle (or call {Wx::Event#skip} in your handler if you do have one) neither right mouse down nor right mouse up event if you plan on handling EVT_CONTEXT_MENU event.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::ContextMenuEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_context_menu}(meth = nil, &block): A right click (or other context menu command depending on platform) has been detected. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Wx::CommandEvent
   # @see  Events and Event Handling 
@@ -2655,7 +2646,7 @@ module Wx
   class ContextMenuEvent < CommandEvent
   
     # Constructor.
-    # @param type [Wx::CommandLinkButton::EventType] 
+    # @param type [Wx::Slider::EventType] 
     # @param id [Integer] 
     # @param pos [Array(Integer, Integer), Wx::Point] 
     # @return [Wx::ContextMenuEvent]
@@ -2679,15 +2670,13 @@ module Wx
   
   # A child focus event is sent to a (parent-)window when one of its child windows gains focus, so that the window could restore the focus back to its corresponding child if it loses it now and regains later.
   # Notice that child window is the direct child of the window receiving event. Use {Wx::Window.find_focus} to retrieve the window which is actually getting focus.
-  # === Events using this class
+  # ### Events using this class
   # 
   # The following event-handler methods redirect the events to member method or handler blocks for {Wx::ChildFocusEvent} events.
   # Event handler methods:
   # 
   # - {Wx::EvtHandler#evt_child_focus}(meth = nil, &block): Process a {Wx::EVT_CHILD_FOCUS} event. 
   # 
-  # === 
-  # 
   # Category:  {Wx::Events}
   # @see Events and Event Handling 
   #