wxruby3 0.9.0.pre.rc.3-x64-mingw-ucrt → 0.9.0-x64-mingw-ucrt

data/lib/wx/doc/extra/01_packages.md

@@ -56,117 +56,118 @@ Currently the following modules have been implemented.
 
 ### Core
 
-The core wxRuby package providing the toplevel `Wx` module.
+The core wxRuby package providing the toplevel {Wx} module.
 This package includes basic classes like:
 
-- `Wx::Object`
-- `Wx::EvtHandler`
-- `Wx::Event`
-- `Wx::CommandEvent`
-- `Wx::App`
-- `Wx::Window`
-- `Wx::NonOwnedWindow`
-- `Wx::ToplevelWindow`
-- `Wx::Frame`
-- `Wx::Dialog`
+- {Wx::Object}
+- {Wx::EvtHandler}
+- {Wx::Event}
+- {Wx::CommandEvent}
+- {Wx::App}
+- {Wx::Window}
+- {Wx::NonOwnedWindow}
+- {Wx::TopLevelWindow}
+- {Wx::Frame}
+- {Wx::Dialog}
 
 as well as most common window classes, control/widget classes, event classes, constant and enum definitions
 and global functions not part of any of the other packages.
 
 ### AUI - Advanced User Interface controls and related classes
 
-The wxRuby AUI package providing the `Wx::AUI` module.
+The wxRuby AUI package providing the {Wx::AUI} module.
 This package includes all classes, constants and enum definitions that are considered part of the 
 wxWidgets AUI framework like:
 
-- `Wx::AUI::AuiManager`
-- `Wx::AUI::AuiMDIParentFrame`
-- `Wx::AUI::AuiMDIChildFrame`
-- `Wx::AUI::AuiMDIClientWindow`
+- {Wx::AUI::AuiManager}
+- {Wx::AUI::AuiMDIParentFrame}
+- {Wx::AUI::AuiMDIChildFrame}
+- {Wx::AUI::AuiMDIClientWindow}
 - etc
 
 ### GRID - Grid control and related classes
 
-The wxRuby GRID package providing the `Wx::GRID` module.
+The wxRuby GRID package providing the {Wx::GRID} module.
 This package includes all classes, constants and enum definitions that are associated with the
 wxWidgets wxGrid control like:
 
-- `Wx::GRID::Grid`
-- `Wx::GRID::GridTableBase`
-- `Wx::GRID::GridCellEditor`
-- `Wx::GRID::GridCellRenderer`
-- `Wx::GRID::GridEvent`
+- {Wx::GRID::Grid}
+- {Wx::GRID::GridTableBase}
+- {Wx::GRID::GridCellEditor}
+- {Wx::GRID::GridCellRenderer}
+- {Wx::GRID::GridEvent}
 - etc
 
 ### HTML - Html framework classes
 
-The wxRuby HTML package providing the `Wx::HTML` module.
+The wxRuby HTML package providing the {Wx::HTML} module.
 This package includes all classes, constants and enum definitions that are considered part of the
 wxWidgets Html framework like:
 
-- `Wx::HTML::HtmlWindow`
-- `Wx::HTML::HtmlHelpWindow`
-- `Wx::HTML::HtmlHelpFrame`
-- `Wx::HTML::HtmlHelpController`
+- {Wx::HTML::HtmlWindow}
+- {Wx::HTML::HtmlHelpWindow}
+- {Wx::HTML::HtmlPrintout}
+- {Wx::HTML::HtmlHelpController}
+- {Wx::HTML::HtmlListBox}
 - etc
 
 ### PG - PropertyGrid control and related classes
 
-The wxRuby PG package providing the `Wx::PG` module.
+The wxRuby PG package providing the {Wx::PG} module.
 This package includes all classes, constants and enum definitions that are associated with the
 wxWidgets wxPropertyGrid control like:
 
-- `Wx::PG::PropertyGrid`
-- `Wx::PG::PropertyGridManager`
-- `Wx::PG::PGCell`
-- `Wx::PG::PGProperty`
-- `Wx::PG::PropertyGridEvent`
+- {Wx::PG::PropertyGrid}
+- {Wx::PG::PropertyGridManager}
+- {Wx::PG::PGCell}
+- {Wx::PG::PGProperty}
+- {Wx::PG::PropertyGridEvent}
 - etc
 
 ### PRT - Printing framework classes
 
-The wxRuby PRT package providing the `Wx::PRT` module.
+The wxRuby PRT package providing the {Wx::PRT} module.
 This package includes all classes, constants and enum definitions that are considered part of the
 wxWidgets Printing framework like:
 
-- `Wx::PRT::PreviewFrame`
-- `Wx::PRT::Printer`
-- `Wx::PRT::PrinterDC`
-- `Wx::PRT::PrintDialog`
+- {Wx::PRT::PreviewFrame}
+- {Wx::PRT::Printer}
+- {Wx::PRT::PrinterDC}
+- {Wx::PRT::PrintDialog}
 - etc
 
 ### RBN - Ribbon framework classes
 
-The wxRuby RBN package providing the `Wx::RBN` module.
+The wxRuby RBN package providing the {Wx::RBN} module.
 This package includes all classes, constants and enum definitions that are considered part of the
 wxWidgets Ribbon framework like:
 
-- `Wx::RBN::RibbonControl`
-- `Wx::RBN::RibbonGallery`
-- `Wx::RBN::RibbonPanel`
-- `Wx::RBN::RibbonPage`
-- `Wx::RBN::RibbonBar`
+- {Wx::RBN::RibbonControl}
+- {Wx::RBN::RibbonGallery}
+- {Wx::RBN::RibbonPanel}
+- {Wx::RBN::RibbonPage}
+- {Wx::RBN::RibbonBar}
 - etc
 
 ### RTC - RichText control and related classes
 
-The wxRuby RTC package providing the `Wx::RTC` module.
+The wxRuby RTC package providing the {Wx::RTC} module.
 This package includes all classes, constants and enum definitions that are associated with the
 wxWidgets wxRichTextCtrl control like:
 
-- `Wx::RTC::RichTextCtrl`
-- `Wx::RTC::RichTextEvent`
-- `Wx::RTC::RichTextBuffer`
+- {Wx::RTC::RichTextCtrl}
+- {Wx::RTC::RichTextEvent}
+- {Wx::RTC::RichTextBuffer}
 - etc
 
 ### STC - StyledText control and related classes
 
-The wxRuby STC package providing the `Wx::STC` module.
+The wxRuby STC package providing the {Wx::STC} module.
 This package includes all classes, constants and enum definitions that are associated with the
 wxWidgets wxStyledTextCtrl control (Scintilla integration) like:
 
-- `Wx::STC::StyledTextCtrl`
-- `Wx::STC::StyledTextEvent`
+- {Wx::STC::StyledTextCtrl}
+- {Wx::STC::StyledTextEvent}
 
 ## Feature dependencies
 

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

@@ -15,8 +15,9 @@ Instead wxRuby offers a dynamic solution that is just as easy to use and even of
 ## 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>
+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.
@@ -27,7 +28,7 @@ Like the event handler macros some of these methods require a single (window) id
 
 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`).
+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:
 
@@ -96,7 +97,7 @@ will take care of checking and handling method arity.
 
 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 
+New event classes can be registered with {Wx::EvtHandler#register_class} which returns the new event type for the event 
 class like this:
 
 ```ruby
@@ -125,27 +126,27 @@ Check the reference documentation [here](https://mcorino.github.io/wxRuby3/Wx/Ev
 
 ## 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
+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)
+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
+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
+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
+{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`.
+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 
@@ -164,3 +165,27 @@ 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

@@ -19,13 +19,13 @@ 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:
+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
+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 |
     # ...    
@@ -47,12 +47,12 @@ instead of
 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` 
+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
+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
 ```

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

@@ -21,7 +21,7 @@ For the wxRuby API similar support has been achieved for various much used argum
 
 ## Colour
 
-Wherever a `Wx::Colour` object is expected as an argument wxRuby supports the specification of `String` or `Symbol`
+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
@@ -37,7 +37,7 @@ pen.set_colour(:CYAN)
 
 ## Font
 
-Wherever a `Wx::Font` object is expected as an argument wxRuby supports the specification of a `Wx::FontInfo` object.
+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

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

@@ -50,5 +50,5 @@ 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 
+of the running {Wx::App} instance and re-raising the exception to be handled by Ruby like any unhandled application 
 exception.

data/lib/wx/doc/extra/10_art.md

@@ -18,8 +18,8 @@ Art that is part of the application's design will preferably be stored with the
 is not standard for this nor is there any standard support for locating those files from the application
 code like there is for `require`-s of other code modules.
 
-The wxRuby framework provides a convenience module `Wx::ArtLocator` to assist in that respect.
-Wx::ArtLocator aims on the one side to standardize folder structures for storing art files and on the
+The wxRuby framework provides a convenience module {Wx::ArtLocator} to assist in that respect.
+{Wx::ArtLocator} aims on the one side to standardize folder structures for storing art files and on the
 other side to provide runtime support for locating those files from code.
 
 The main locator method provided is:
@@ -63,41 +63,47 @@ The first location can be skipped by specifying `nil` for 'art_type'.
 
 ## Bitmap types
 
-Based on platform and specified '<art_type>' (and optionally a specific Wx::BitmapType) art files with a specific
+Based on platform and specified '<art_type>' (and optionally a specific {Wx::BitmapType}) art files with a specific
 range of extensions will be tested in a specific order.
 For example for locating an `:icon` (<art_type>) on platform 'WXGTK' the locator will test the preferred extension
 '.xpm' followed by any of supported extensions of all other supported bitmap types.
 For platform 'WXMSW' however the same search would test only the extensions '.ico' and '.xpm' (in that
 order).
-Specifying a specific Wx::BitmapType for a search will restrict the search to testing only the extensions supported
-for the specified Wx::BitmapType.
+Specifying a specific {Wx::BitmapType} for a search will restrict the search to testing only the extensions supported
+for the specified {Wx::BitmapType}.
 
 ## Search paths
 
-To prevent having to specify base search path for every location request Wx::Locator provides 2 options.
+To prevent having to specify base search path for every location request {Wx::Locator} provides 2 options.
 
 When an explicit specification of a base search path ('art_path) is omitted from a location request the locator
 will determine one by using `Kernel#caller_locations` to extract the absolute path for the source file containing
 the caller's code. The result of `File.dirname(src_path)` is than used as base search path.
 If 'art_section' is also omitted the result of `File.basename(src_path, '.*')` will be used instead.
 
-This means that calling `Wx::ArtLocator.find_art` from some code in file `/some/lib/path/to/ruby/code.rb` without 
+This means that calling {Wx::ArtLocator.find_art} from some code in file `/some/lib/path/to/ruby/code.rb` without 
 specifying both 'art_path' and 'art_section' would result in looking for an art file with the base search path
 being `/some/lib/path/to/ruby/` and using `code` as 'art_section'.
 
-It is also possible to add 'application global' search paths with the method `Wx::ArtLocator.add_search_path`.
+It is also possible to add 'application global' search paths with the method {Wx::ArtLocator.add_search_path}.
 Search paths added in this way will be tested after failing to find any matching art file at the initial 'art_path'
 location. The same location steps apply to these search paths as with the initial 'art_path' (see above).
 
 ## Convenience methods
 
-Based on the Wx::ArtLocator implementation wxRuby additionally provides a number of convenience methods to
-easily create Icons, Bitmaps, Cursors and Images from simple ids (symbols).
+Based on the {Wx::ArtLocator} implementation wxRuby additionally provides a number of convenience methods to
+easily create Icons, Bitmaps, Cursors and Images from simple ids (symbols):
+
+- {Wx.Bitmap} 
+- {Wx.Cursor} 
+- {Wx.Icon} 
+- {Wx.Image}
+
 These methods mimic the ease of use of the `wxICON` and `wxBITMAP` macros used with C++ wxWidgets such that
-creating an Wx::Icon instance could be as easy as:
+creating an {Wx::Icon} instance could be as easy as:
 
 ```ruby
-    frame.icon = Wx::Icon(:sample)
+    frame.icon = Wx.Icon(:sample)
 ```
 
 As these methods apply the same search path 'automagic' as `Wx::ArtLocator.find_art` (see [Search paths](#Search-paths))

data/lib/wx/doc/extra/11_drawing_and_dc.md

@@ -19,8 +19,8 @@ life cycles. Any DC object created would have to be dynamically created and due
 life cycles could well be kept alive beyond the scope of it's creation. This will not always cause problems but could
 and does not really have an upside.
 
-To prevent confusion and potential problems wxRuby defines all `Wx::DC` derived classes to be abstract classes that
-cannot be instantiated using `new`. Rather all `Wx::DC` derived classes provide `::draw_on` factory methods to create 
+To prevent confusion and potential problems wxRuby defines all {Wx::DC} derived classes to be abstract classes that
+cannot be instantiated using `new`. Rather all {Wx::DC} derived classes provide `::draw_on` factory methods to create 
 temporary dc objects that will be passed on to blocks given and will only exist for the duration of the execution of
 the block. This will guarantee proper DC cleanup when leaving it's usage scope.
 
@@ -44,10 +44,10 @@ A typical usage of a `::draw_on` method would be:
 
 ## Windows, Wx::PaintDC and Wx::AutoBufferedPaintDC
 
-The `Wx::PaintDC` and `Wx::AutoBufferedPaintDC` classes provide `::draw_on` methods just like all other DC classes but
+The {Wx::PaintDC} and {Wx::AutoBufferedPaintDC} classes provide `::draw_on` methods just like all other DC classes but
 this is mostly to be consistent.
 
-In this case it is recommended to instead use the `Wx::Window#paint` or `Wx::Window#paint_buffered` methods as these
+In this case it is recommended to instead use the {Wx::Window#paint} or {Wx::Window#paint_buffered} methods as these
 provide some optimizations with regard to automatically detecting if the methods are called inside `Wx::EVT_PAINT` 
 handlers (which should normally be the case) or not.
 

data/lib/wx/doc/font.rb

@@ -1,3 +1,9 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
 
 module Wx
   class Font

data/lib/wx/doc/font_data.rb

@@ -0,0 +1,16 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
+
+module Wx
+
+  FONTRESTRICT_NONE = 0
+
+  FONTRESTRICT_SCALABLE = 1 << 0
+
+  FONTRESTRICT_FIXEDPITCH = 1 << 1
+
+end

data/lib/wx/doc/functions.rb

@@ -1,6 +1,14 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+
+
 # Wx global methods
 #
 # Documentation stubs for global Wx methods
+# :startdoc:
+
 
 
 module Wx
@@ -104,7 +112,7 @@ module Wx
   # string - useful for debugging
   # @param obj [Object] wrapped object
   # @return [String] string with address in hex format
-  def self.cpp_ptr_addr(obj) end
+  def self.ptr_addr(obj) end
 
   # Converts a string XRC id into a Wx id
   # @param str [String] XRC id string

data/lib/wx/doc/gc_dc.rb

@@ -1,3 +1,9 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+# :startdoc:
+
 
 module Wx
 

data/lib/wx/doc/gdi_common.rb

@@ -1,7 +1,14 @@
+# :stopdoc:
+# Copyright (c) 2023 M.J.N. Corino, The Netherlands
+#
+# This software is released under the MIT license.
+
+
 ###
 # wxRuby3 geometry classes
-# Copyright (c) M.J.N. Corino, The Netherlands
 ###
+# :startdoc:
+
 
 
 module Wx

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

@@ -107,7 +107,7 @@ module Wx
     # Returns true if a description string has been specified.
     # 
     # @see Wx::AboutDialogInfo#get_description 
-    # @return [true,false]
+    # @return [Boolean]
     def has_description; end
     alias_method :has_description?, :has_description
     
@@ -120,7 +120,7 @@ module Wx
     # Returns true if a copyright string has been specified.
     # 
     # @see Wx::AboutDialogInfo#get_copyright 
-    # @return [true,false]
+    # @return [Boolean]
     def has_copyright; end
     alias_method :has_copyright?, :has_copyright
     
@@ -168,7 +168,7 @@ module Wx
     alias_method :doc_writers=, :set_doc_writers
     
     # Returns true if an icon has been set for the about dialog.
-    # @return [true,false]
+    # @return [Boolean]
     def has_icon; end
     alias_method :has_icon?, :has_icon
     
@@ -185,7 +185,7 @@ module Wx
     alias_method :icon=, :set_icon
     
     # Returns true if the licence string has been set.
-    # @return [true,false]
+    # @return [Boolean]
     def has_licence; end
     alias_method :has_licence?, :has_licence
     
@@ -247,7 +247,7 @@ module Wx
     alias_method :long_version, :get_long_version
     
     # Returns true if the website info has been set.
-    # @return [true,false]
+    # @return [Boolean]
     def has_web_site; end
     alias_method :has_web_site?, :has_web_site
     
@@ -270,7 +270,7 @@ module Wx
     alias_method :web_site=, :set_web_site
     
     # Returns true if developers have been set in the dialog info.
-    # @return [true,false]
+    # @return [Boolean]
     def has_developers; end
     alias_method :has_developers?, :has_developers
     
@@ -280,7 +280,7 @@ module Wx
     alias_method :developers, :get_developers
     
     # Returns true if writers have been set in the dialog info.
-    # @return [true,false]
+    # @return [Boolean]
     def has_doc_writers; end
     alias_method :has_doc_writers?, :has_doc_writers
     
@@ -290,7 +290,7 @@ module Wx
     alias_method :doc_writers, :get_doc_writers
     
     # Returns true if artists have been set in the dialog info.
-    # @return [true,false]
+    # @return [Boolean]
     def has_artists; end
     alias_method :has_artists?, :has_artists
     
@@ -300,7 +300,7 @@ module Wx
     alias_method :artists, :get_artists
     
     # Returns true if translators have been set in the dialog info.
-    # @return [true,false]
+    # @return [Boolean]
     def has_translators; end
     alias_method :has_translators?, :has_translators
     

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

@@ -94,7 +94,7 @@ module Wx
     def set(flags, keyCode, cmd, item=nil) end
     
     # Returns true if this object is correctly initialized.
-    # @return [true,false]
+    # @return [Boolean]
     def is_ok; end
     alias_method :ok?, :is_ok
     
@@ -112,11 +112,11 @@ module Wx
     # Parses the given string and sets the accelerator accordingly.
     # true if the given string correctly initialized this object (i.e. if {Wx::AcceleratorEntry#is_ok} returns true after this call)
     # @param str [String]  This string may be either in the same format as returned by {Wx::AcceleratorEntry#to_string}, i.e. contain the accelerator itself only, or have the format of a full menu item text with i.e. <code>Label TAB Accelerator</code>. In the latter case, the part of the string before the TAB is ignored. Notice that the latter format is only supported for the compatibility with the previous wxWidgets versions and the new code should pass only the accelerator string itself to this function.
-    # @return [true,false]
+    # @return [Boolean]
     def from_string(str) end
     
     # @param entry [Wx::AcceleratorEntry] 
-    # @return [true,false]
+    # @return [Boolean]
     def ==(entry) end
     
   end # AcceleratorEntry
@@ -153,15 +153,10 @@ module Wx
     #   Initializes the accelerator table from an array of {Wx::AcceleratorEntry}.
     #   @param entries [Array<Wx::AcceleratorEntry>]  The array of entries.
     #   @return [Wx::AcceleratorTable]
-    # @overload initialize(resource)
-    #   Loads the accelerator table from a Windows resource (Windows only).
-    #   Availability:  only available for the wxMSW port.  {Wx::msw}
-    #   @param resource [String]  Name of a Windows accelerator.
-    #   @return [Wx::AcceleratorTable]
     def initialize(*args) end
     
     # Returns true if the accelerator table is valid.
-    # @return [true,false]
+    # @return [Boolean]
     def is_ok; end
     alias_method :ok?, :is_ok