wxruby3 0.9.8 → 1.0.0

data/lib/wx/doc/extra/04_enums.md

@@ -1,143 +0,0 @@
-<!--
-# @markup markdown
-# @title 4. wxRuby Enum values
--->
-
-# 4. wxRuby Enum values
-
-The wxWidget library liberally mixes integer constants and enum values for things like IDs, style flags
-and option flags and such without much consistency.<br>
-In previous wxRuby versions these were all mapped to integer constants which had 2 distinct disadvantages.
-
-- **loss of scoping**<br>
-Integer constants for enum values would all be declared in the enclosing scope for the enum declaration loosing
-the naming scope which originally existed in C++ (excepting anonymous enums).
-
-- **loss of type-safety**<br>
-Constants for enum values with identical integer values are indistinguishable from each other.
-
-The wxRuby3 project attempts to provide a solution to that by introducing the `Wx::Enum` class which
-is used as a base class for mapping all (named) wxWidget enums to Ruby.
-The reference documentation for the `Wx::Enum` class can be found [here](https://mcorino.github.io/wxRuby3/Wx/Enum.html).
-
-Any named wxWidget enum is mapped to a similarly named (Rubified C++ name) derived Enum class with each enum value 
-defined as a constant of the enum class referencing an instance of the enum class with the corresponding
-integer value like for example the 'wxSystemFont' enum which is defined in wxRuby as:
-
-```ruby
-module Wx
-  class SystemFont < Wx::Enum
-  
-    # Original equipment manufacturer dependent fixed-pitch font.
-    # 
-    SYS_OEM_FIXED_FONT = Wx::SystemFont.new(10)
-    
-    # Windows fixed-pitch (monospaced) font.
-    # 
-    SYS_ANSI_FIXED_FONT = Wx::SystemFont.new(11)
-    
-    # Windows variable-pitch (proportional) font.
-    # 
-    SYS_ANSI_VAR_FONT = Wx::SystemFont.new(12)
-    
-    # System font.
-    # 
-    SYS_SYSTEM_FONT = Wx::SystemFont.new(13)
-    
-    # Device-dependent font.
-    # 
-    SYS_DEVICE_DEFAULT_FONT = Wx::SystemFont.new(14)
-    
-    # Default font for user interface objects such as menus and dialog boxes.
-    # 
-    SYS_DEFAULT_GUI_FONT = Wx::SystemFont.new(17)
-    
-  end # SystemFont
-end
-```
-
-or the 'wxBorder' enum which is defined in wxRuby as:
-
-```ruby
-module Wx
-  # Border flags for {Wx::Window}.
-  class Border < Wx::Enum
-
-    # This is different from {Wx::Border::BORDER_NONE} as by default the controls do have a border.
-    # 
-    BORDER_DEFAULT = Wx::Border.new(0)
-
-    # 
-    # 
-    BORDER_NONE = Wx::Border.new(2097152)
-
-    # 
-    # 
-    BORDER_STATIC = Wx::Border.new(16777216)
-
-    # 
-    # 
-    BORDER_SIMPLE = Wx::Border.new(33554432)
-
-    # 
-    # 
-    BORDER_RAISED = Wx::Border.new(67108864)
-
-    # 
-    # 
-    BORDER_SUNKEN = Wx::Border.new(134217728)
-
-    # 
-    # 
-    BORDER_DOUBLE = Wx::Border.new(268435456)
-
-    # 
-    # 
-    BORDER_THEME = Wx::Border.new(268435456)
-
-    # 
-    # 
-    BORDER_MASK = Wx::Border.new(522190848)
-
-  end # Border
-end
-```
-
-Enum instances are interchangeable with integer constants in wxRuby with respect to arithmetic or logical
-operations. This make it possible to use enum values to construct integer bitflag arguments like:
-
-```ruby
-Wx::TextCtrl.new(pane, Wx::ID_ANY, sample_desc.description, style: Wx::TE_MULTILINE|Wx::TE_READONLY|Wx::BORDER_NONE)
-```
-
-where `Wx::ID_ANY` is a `Wx::StandardID` enum instance passed to provide an integer argument value, `Wx::TE_MULTILINE` 
-and `Wx::TE_READONLY` are simple integer constants and `Wx::BORDER_NONE` is a `Wx::Border` enum instance.
-
-In other cases however enum values can provide just the right kind of type safety where explicit enum values are 
-expected like for example with:
-
-```ruby
-Wx::Font.new(36, Wx::FONTFAMILY_SWISS, Wx::FONTSTYLE_NORMAL, Wx::FONTWEIGHT_NORMAL)
-```
-
-where the `Wx::Font` constructor definition is:
-
-> initialize(pointSize, family, style, weight, underline = false, faceName = `Wx::EMPTY_STRING`, encoding = `Wx::FONTENCODING_DEFAULT`) ⇒ `Wx::Font`
-
-with the following parameter specification:
-
-> - pointSize (`Integer`)
-> - family (`Wx::FontFamily`)
-> - style (`Wx::FontStyle`)
-> - weight (`Wx::FontWeight`)
-> - underline (`true`, `false`) (defaults to: `false`)
-> - faceName (`String`) (defaults to: `Wx::EMPTY_STRING`)
-> - encoding (`Wx::FontEncoding`) (defaults to: `Wx::FONTENCODING_DEFAULT`)
-
-In this case the constructor explicitly expects specific enum value types for *family*, *style* and *weigth* and
-providing the integer literal value `74` instead of `Wx::FONTFAMILY_SWISS` (or any other constant representing the same 
-integer value) will not work (raises an exception) although the integer values for the two are equal.
-
-As you have probably noticed it is not required to use the full naming for an enum instance constant (like 
-`Wx::FontFamily::FONTFAMILY_SWISS`). All enum value constants are accessible from the naming scope where the enum class
-to which they belong has been declared.

data/lib/wx/doc/extra/05_event-handling.md

@@ -1,191 +0,0 @@
-<!--
-# @markup markdown
-# @title 5. wxRuby Event Handling
--->
-
-# 5. wxRuby Event Handling
-
-## Introduction
-
-Event handling is the core of runtime code execution in event based frameworks like wxWidgets which means it needs to
-be fully supported by wxRuby. Fortunately it is.<br>
-As Ruby is a fully dynamic language though the statically declared event tables typical for wxWidgets application are not.<br>
-Instead wxRuby offers a dynamic solution that is just as easy to use and even offers more flexibility in a typical Ruby-way.
-
-## Event handlers
-
-Instead of the `EVT_XXX` event handler declaration macros used in wxWidgets wxRuby provides similarly named event handler 
-definition methods for each of the known event declarations which are inherited by **all** classes derived from {Wx::
-EvtHandler}
-(which includes all window classes, the {Wx::App} class and {Wx::Timer} as well as various other classes).<br>
-
-Naming is (mostly) identical but rubified. So `EVT_MENU` becomes `evt_menu`, `EVT_IDLE` becomes `evt_idle`, `EVT_UPDATE_UI`
-becomes `evt_update_ui` etc.
-
-Like the event handler macros some of these methods require a single (window) id (like `evt_menu`) or a range of of ids
-(specified through a first and last id like for `evt_update_ui_range`) and some require only a handler definition (like
-`evt_idle`).
-
-Event handler setup is typically something done during the initialization of an event handler object (like a window) but
-this is not required. As all event handlers are assigned dynamically in wxRuby you can setup (some) event handlers at a 
-later moment. You could also disconnect earlier activated handlers at any time (see {Wx::EvtHandler#disconnect}).
-
-In case of some frame class `MyForm` including a menu a wxWidgets static event handling table like:
-
-```c++
-wxBEGIN_EVENT_TABLE(MyForm, wxFrame)
-    EVT_IDLE(MyForm::OnIdle)
-    EVT_MOVE(MyForm::OnMove)
-    EVT_SIZE(MyForm::OnResize)
-
-    EVT_MENU( wxID_ABOUT, MyForm::OnAbout )
-    EVT_MENU( wxID_EXIT, MyForm::OnCloseClick )
-wxEND_EVENT_TABLE()
-```
-
-could translate to event handler initializations in wxRuby like this:
-
-```ruby
-class MyForm < Wx::Frame
-  
-  def initialize(title)
-    super(nil, title: title)
-    
-    # initialize frame elements
-    # ...
-    
-    # setup event handlers
-    evt_idle do |evt|
-      # do something
-      evt.skip
-    end
-    evt_move :on_move
-    
-    evt_size method(:on_size)
-    
-    evt_menu(Wx::ID_ABOUT, Proc.new { on_about })
-    evt_menu(Wx::ID_EXIT) { close(false) }
-  end
-  
-  def on_idle(evt)
-    #...
-  end
-  
-  def on_move(evt)
-    #...
-  end
-
-  def on_resize(evt)
-    #...
-  end
-
-  def on_about
-    #...
-  end
-  
-end
-```
-
-As you can see there are multiple options for specifying the actual handler. Any event handler definition method will
-accept either a `Symbol` (or `String`) specifying a method of the receiver (the event handler instance), a `Proc` object
-(or lambda) or a `Method` object.
-
-Event handler methods are not required to declare the single event object argument. The event handler definition method 
-will take care of checking and handling method arity.
-
-## Custom Events
-
-Custom event definitions are fully supported in wxRuby including the definition of new event types.
-
-New event classes can be registered with {Wx::EvtHandler#register_class} which returns the new event type for the event 
-class like this:
-
-```ruby
-# A custom type of event associated with a target control. Note that for
-# user-defined controls, the associated event should inherit from
-# Wx::CommandEvent rather than Wx::Event.
-class ProgressUpdateEvent < Wx::CommandEvent
-  # Create a new unique constant identifier, associate this class
-  # with events of that identifier and create an event handler definition method 'evt_update_progress'
-  # for setting up this handler.
-  EVT_UPDATE_PROGRESS = Wx::EvtHandler.register_class(self, nil, 'evt_update_progress', 0)
-
-  def initialize(value, gauge)
-    # The constant id is the arg to super
-    super(EVT_UPDATE_PROGRESS)
-    # simply use instance variables to store custom event associated data
-    @value = value
-    @gauge = gauge
-  end
-
-  attr_reader :value, :gauge
-end
-```
-
-Check the reference documentation [here](https://mcorino.github.io/wxRuby3/Wx/EvtHandler.html) for more information.  
-
-## Event processing
-
-In wxRuby overruling the normal chain of event handling has been limited to being able to override the default
-{Wx::EvtHandler#try_before} and {Wx::EvtHandler#try_after} methods. These are the advised interception points for events
-when you really need to do this.<br>
-Overriding {Wx::EvtHandler#process_event} is not considered to be efficient (or desired)
-for wxRuby applications and has therefor been blocked.
-
-## Event insertion
-
-Use of {Wx::EvtHandler#process_event} or {Wx::EvtHandler#queue_event} and {Wx::EvtHandler#add_pending_event} in wxRuby to
-trigger event processing of user generated (possibly custom) events is fully supported.
-
-As with wxWidgets {Wx::EvtHandler#process_event} will trigger immediate processing of the given event, not returning before
-this has finished.<br>
-{Wx::EvtHandler#queue_event} and {Wx::EvtHandler#add_pending_event} on the other hand will post (append) the given event
-to the event queue and return immediately after that is done. The event will than be processed after any other events in
-the queue. Unlike in wxWidgets in wxRuby there is no practical difference between `queue_event` and `add_pending_event`.
-
-## Asynchronous execution
-
-In addition to {Wx::EvtHandler#queue_event} and {Wx::EvtHandler#add_pending_event} to trigger asynchronous processing 
-wxRuby also supports {Wx::EvtHandler#call_after}.
-
-This method provides the means to trigger asynchronous execution of arbitrary code and because it has been rubified is
-easy and powerful to use. Like with event handler definition this method accepts a `Symbol` or `String` (identifying a 
-method of the receiver), a `Proc` object (or lambda), a `Method` object or a block. Unlike an event handler method no 
-event object will be passed but rather any arguments passed to the `call_after` method in addition to the 'handler'.
-
-Given an event handler object `call_after` could be used like:
-
-```ruby
-# sync call to method of event handler (no args)
-evt_handler.call_after :async_method
-
-# async call of lambda (single arg)
-evt_handler.call_after(->(txt) { Wx.log_info(txt) }, "Hello")
-
-# async call of block
-evt_handler.call_after('Call nr. %d', 1) { |fmt, num| Wx.log_info(fmt, num) }
-```
-
-## Event life cycles!
-
-Like in C++ the wxRuby Event objects passed to the event handlers are (in general) references to **temporary** objects 
-which are only safe to access within the execution scope of the event handler that received the reference.
-If you *need* (really?) to store a reference to such an object do so to a cloned version (see {Wx::Event#clone}) and **not**
-to the original object otherwise you **will** run into 'Object already deleted' exceptions.
-
-Only user defined events instantiated in Ruby code (or cloned Event objects) will be subject to Ruby's normal life cycle 
-rules (GC).
-This means that when you instantiate a user defined event and pass it to {Wx::EvtHandler#process_event} it would be possible
-to directly store the reference to such an Event object passed to it's event handler. You have to **know** for sure though
-(see below). So, in case of doubt (or to be safe) use {Wx::Event#clone}.
-
-Another 'feature' to be aware of is the fact that when passing an (user instantiated) Event object to {Wx::
-EvtHandler#queue_event} 
-or {Wx::EvtHandler#add_pending_event} the Ruby event instance is unlinked from it's C++ counterpart (or in the case of user
-defined events a cloned instance is associated with it's C++ counterpart) before being queued and the C++ side now takes ownership 
-(and will delete the Event object when handled).  
-As a result this means that even in the case of a user defined Event object any event handler triggered by a asynchronously 
-processed event will be handling a temporary Event object.
-Additionally this also means that any Event object passed to {Wx::EvtHandler#queue_event} or {Wx::
-EvtHandler#add_pending_event}
-is essentially invalidated after these methods return and should not be referenced anymore.

data/lib/wx/doc/extra/06_geometry.md

@@ -1,62 +0,0 @@
-<!--
-# @markup markdown
-# @title 6. wxRuby geometry classes
--->
-
-# 6. wxRuby Geometry classes
-
-## Size (Wx::Size) and position (Wx::Point and Wx::RealPoint)
-
-The wxWidgets API has a lot methods that require either `wxSize`, `wxPoint` or both type of value as argument. Although 
-this can be specified in C++ still relatively concise like 
-```ruby
-new wxFrame(nullptr, -1, "title", wxPoint(0,0), wxSize(500,400))
-```
-in Ruby this expands to the more verbose 
-```ruby
-Wx::Frame.new(nil, -1, 'title', Wx::Point.new(0,0), Wx::Size.new(500,400))
-```
-which starts to feel awkward to specify what are in essence just pairs of integers.
-
-To provide a simpler, more compact and more Ruby-like, alternative the wxRuby API therefor supports specifying arrays
-of integer (or float in case of {Wx::RealPoint}) pairs in (almost) all cases where {Wx::Size} or {Wx::Point} 
-(or {Wx::RealPoint}) is expected. So the following code is equivalent to the previous code:
-```ruby
-Wx::Frame.new(nil, -1, 'title', [0,0], [500,400])
-```
-
-In addition {Wx::Size}, {Wx::Point} and {Wx::RealPoint} support parallel assignment semantics such that you can write code like
-```ruby
-  win.paint do | dc |
-    # ...    
-    x, y = win.get_position
-    dc.draw_circle(x, y, 4)
-    dc.draw_rectangle(x-4, y-4, 8, 8)
-  end
-```
-instead of
-```ruby
-  win.paint do | dc |
-    # ...    
-    pos = win.get_position
-    dc.draw_circle(pos.x, pos.y, 4)
-    dc.draw_rectangle(pos.x-4, pos.y-4, 8, 8)
-  end
-```
-
-Instances of these classes can also be converted (back) to arrays with their `#to_ary` methods.
-
-Lastly wxRuby also extends the standard Ruby Array class with conversion methods to explicitly convert
-arrays to {Wx::Size}, {Wx::Point} or {Wx::RealPoint}; respectively the `#to_size`, `#to_point` and `#to_real_point` 
-methods.
-
-## Areas (Wx::Rect)
-
-Like {Wx::Size} and {Wx::Point} wxRuby supports parallel assignment for {Wx::Rect} such that you can write code like
-```ruby
-x, y, width, height = win.get_client_rect
-```
-
-Providing arrays of integers as alternative for `Wx::Rect` arguments is not supported as specifying `[0, 0, 20, 40]` is
-ambiguous. This could either mean a rectangle with origin `x=0,y=0` and size `width=20,height=40` (`Wx::Rect.new(0,0,20,40)`)
-or a rectangle from origin top left `x=0,y=0` to point bottom right `x=20,y=40` (`Wx::Rect.new(Wx::Point.new(0,0), Wx::Point.new(20,40))`).

data/lib/wx/doc/extra/07_colour_and_font.md

@@ -1,52 +0,0 @@
-<!--
-# @markup markdown
-# @title 7. wxRuby Colour and Font
--->
-
-# 6. wxRuby Colour and Font
-
-## Introduction
-
-The wxWidgets API makes use of typical C++ features to support automatic conversion of certain types providing
-user friendly options for argument specifications. This way for example a developer does not need to explicitly
-declare a colour object construction where a colour instance value is expected but rather can specify a simple string
-constant like:
-
-```C++
-wxPen pen;
-pen.SetColour("CYAN"); // instead of pen.SetColour(wxColour("CYAN"));
-```
-
-For the wxRuby API similar support has been achieved for various much used argument types.  
-
-## Colour
-
-Wherever a {Wx::Colour} object is expected as an argument wxRuby supports the specification of `String` or `Symbol`
-values as a developer friendly alternative. This way the following code is equivalent:
-
-```ruby
-pen = Wx::Pen.new
-pen.set_colour(Wx::Colour.new("CYAN"))
-
-pen = Wx::Pen.new
-pen.set_colour("CYAN")
-
-pen = Wx::Pen.new
-pen.set_colour(:CYAN)
-```
-
-## Font
-
-Wherever a {Wx::Font} object is expected as an argument wxRuby supports the specification of a {Wx::FontInfo} object.
-This way the following code is equivalent:
-
-```ruby
-title = Wx::StaticText.new(self, -1, "Title")
-title.set_font(Wx::Font.new(18, Wx::FontFamily::FONTFAMILY_SWISS, Wx::FontStyle::FONTSTYLE_NORMAL, Wx::FontWeight::FONTWEIGHT_BOLD))
-
-title = Wx::StaticText.new(self, -1, "Title")
-title.set_font(Wx::FontInfo.new(18)
-                 .family(Wx::FontFamily::FONTFAMILY_SWISS)
-                 .style(Wx::FontStyle::FONTSTYLE_NORMAL)
-                 .bold())
-```

data/lib/wx/doc/extra/08_extensions.md

@@ -1,144 +0,0 @@
-<!--
-# @markup markdown
-# @title 8. wxRuby Extensions
--->
-
-# 8. wxRuby Extensions
-
-## Keyword Constructors
-
-The **Keyword Constructors** extension allows the use of Ruby hash-style
-keyword arguments in constructors of common WxWidgets Windows, Frame,
-Dialog and Control classes.
-
-### Introduction
-
-Building a GUI in WxWidgets involves lots of calls to +new+, but
-these methods often have long parameter lists. Often the default
-values for many of these parameters are correct. For example, if
-you're using a sizer-based layout, you usually don't want to specify a
-size for widgets, but you still have to type
-
-    Wx::TreeCtrl.new( parent, -1, Wx::DEFAULT_POSITION, Wx::DEFAULT_SIZE, Wx::NO_BUTTONS )
-
-just to create a standard TreeCtrl with the 'no buttons' style. If you
-want to specify the 'NO BUTTONS' style, you can't avoid all the typing
-of DEFAULT_POSITION etc.
-
-### Basic Keyword Constructors
-
-With keyword_constructors, you could write the above as
-
-    TreeCtrl.new(parent, :style => Wx::NO_BUTTONS)
-
-And it will assume you want the default id (-1), and the default size
-and position. If you want to specify an explicit size, you can do so:
-
-    TreeCtrl.new(parent, :size => Wx::Size.new(100, 300))
-
-For brevity, this module also allows you to specify positions and
-sizes using a a two-element array:
-
-    TreeCtrl.new(parent, :size => [100, 300])
-
-Similarly with position:
-
-    TreeCtrl.new(parent, :pos => Wx::Point.new(5, 25))
-    
-    TreeCtrl.new(parent, :pos => [5, 25])
-
-You can have multiple keyword arguments:
-
-    TreeCtrl.new(parent, :pos => [5, 25], :size => [100, 300] )
-
-### No ID required
-
-As with position and size, you usually don't want to deal with
-assigning unique ids to every widget and frame you create - it's a C++
-hangover that often seems clunky in Ruby. The **Event Connectors**
-extension allows you to set up event handling without having to use
-ids, and if no `:id` argument is supplied to a constructor, the default
-(-1) will be passed.
-
-There are occasions when a specific ID does need to be used - for
-example, to tell WxWidgets that a button is a 'stock' item, so that it
-can be displayed using platform-standard text and icon. To do this,
-simply pass an :id argument to the constructor - here, the system's
-standard 'preview' button
-
-    Wx::Button.new(parent, :id => Wx::ID_PREVIEW)
-
-### Class-specific arguments
-
-The arguments `:size`, `:pos` and `:style` are common to many WxWidgets
-window classes. The `new` methods of these classes also have
-parameters that are specific to those classes; for example, the text
-label on a button, or the initial value of a text control.
-
-    Wx::Button.new(parent, :label => 'press me')
-    Wx::TextCtrl.new(parent, :value => 'type some text here')
-
-The keyword names of these arguments can be found by looking at the
-WxRuby documentation, in the relevant class's +new+ method. You can
-also get a string description of the class's +new+ method parameters
-within Ruby by doing:
-
-    puts Wx::TextCtrl.describe_constructor()
-
-This will print a list of the argument names expected by the class's
-+new+ method, and the correct type for them.
-
-### Mixing positional and keyword arguments
-
-To support existing code, and to avoid forcing the use of more verbose
-keyword-style arguments where they're not desired, you can mix
-positional and keyword arguments, omitting or including `id`s as
-desired.
-
-    Wx::Button.new(parent, 'press me', :style => Wx::BU_RIGHT)
-
-### Handling complex defaults or version differences
-
-To support complex (context dependent) defaults and/or auto conversion
-of arguments for backwards compatibility the keyword constructors
-extension allows the definition of lambdas or procs to be associated
-with a parameter specification.
-
-## Ruby-style accessors
-
-The wxWidgets API, in typical C++ style, has lots of accessor methods like
-
-- `GetPosition()`
-- `SetSize(a_size)`
-- `IsChecked()`
-- `CanUndo()`
-- `HasStyle(a_style)`
-
-which in wxRuby are mapped to Ruby methods like `get_position`, `set_size` etc.
-
-In Ruby however these kind of methods that set, get or query attributes or state are normally simply called
-by the attribute name or, in other cases, by a predicate method like:
-
-```ruby
-pos = frame.position
-frame.size = a_size
-item.checked?
-control.can_undo?
-window.has_style?(a_style)
-```
-
-With wxRuby3 (most of) the API methods that begin with *get_*, *set_*, *is_*, *can_* and *has_* are identified 
-and the wxRuby API will have Ruby-style accessor aliases defined for those (appropriately decorated as needed).
-Note that if you are calling a *'setter'* method on `self`, you must explicitly send the message to `self` like:
-
-```ruby
-# set's self size to be 100px by 100px
-self.size = Wx::Size.new(100, 100)
-```
-
-since this will not work as you expect it to:
-
-```ruby
-# only sets the value of a local variable 'size'
-size = Wx::Size.new
-```

data/lib/wx/doc/extra/09_exceptions.md

@@ -1,54 +0,0 @@
-<!--
-# @markup markdown
-# @title 9. wxRuby Exception Handling
--->
-
-# 9. wxRuby Exception Handling
-
-The wxRuby library should (!) be completely exception safe, i.e. Ruby code raising an exception should not leak into
-the wrapped wxWidgets C++ code and cause unexpected exception handling or (worse) segmentation faults and should be 
-handled in ways expected of Ruby applications.
-
-As the wxWidgets library does not use exceptions for it's public API any raised exceptions should come either from the
-wxRuby wrapper code (signalling mostly typical Ruby-ish error situations like ArgumentError, TypeError and such) or from
-your own Ruby application code.
-
-Any exceptions raised from wxRuby wrapper code signal coding errors that need to be rectified.
-
-As far as handling application code exceptions is concerned the same advice applies as for wxWidgets itself; do **NOT**
-let exceptions escape your event handlers meaning that if you can reasonably expect application code to raise exceptions
-you should make sure to catch any such exceptions within the context of the event handler like:
-
-```ruby
-class MyForm < Wx::Frame
-  
-  def initialize(title)
-    super(nil, title: title)
-    
-    # initialize frame elements
-    # ...
-    
-    # setup event handlers
-    evt_menu MY_MENU_ID, :on_my_menu_item
-    
-    # ...
-  end
-  
-  def on_my_menu_item(evt)
-    begin
-      # execute some application code
-      # ...
-    rescue SomeException => ex 
-      # handle exception
-    end
-  end
-  
-  #...
-  
-end
-```
-
-In wxRuby event handler code is executed in an exception safe way which will capture any leaking exceptions. As wxRuby 
-however has no idea why this exception was raised and how to handle it, the result will be an exit of the main event loop
-of the running {Wx::App} instance and re-raising the exception to be handled by Ruby like any unhandled application 
-exception.