wxruby 1.9.1-i386-mswin32 → 1.9.2-i386-mswin32

data/LICENSE

@@ -0,0 +1,53 @@
+wxRuby2
+Copyright (c) 2004-2007 wxRuby Development Team
+
+Permission is hereby granted, free of charge, to any person obtaining a copy 
+of this software and associated documentation files (the "Software"), to deal 
+in the Software without restriction, including without limitation the rights 
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 
+copies of the Software, and to permit persons to whom the Software is 
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in 
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 
+SOFTWARE.
+
+
+
+
+
+
+============================================================================
+THE FOLLOWING IS NOT PART OF THE LICENSE, NOR IS IT LEGAL ADVICE!
+
+wxRuby and wxWidgets
+--------------------
+Normally, wxRuby is distributed with a binary copy of wxWidgets. If you 
+distribute the wxRuby gem, you are bound to the requirements of the 
+copy of wxWidgets within. Fortunately, those requirements do not impose 
+any serious restrictions.
+
+
+wxWidgets License Summary (from the wxWidgets README)
+-----------------------------------------------------
+In summary, the licence is LGPL plus a clause allowing unrestricted 
+distribution of application binaries. To answer a FAQ, you don't have to 
+distribute any source if you wish to write commercial applications using 
+wxWidgets.
+
+
+Required Credits and Attribution
+--------------------------------
+
+Generally, neither wxWidgets nor wxRuby require attribution, beyond 
+retaining existing copyright notices. However, if you build your own 
+custom wxWidgets library, there may be portions that require specific 
+attributions or credits, such as TIFF or JPEG support. See the wxWidgets 
+README and license files for details.

data/README

@@ -0,0 +1,299 @@
+README for wxruby2
+
+Version 1.9.x
+
+This is wxruby2, the second generation of wxRuby, a library 
+that allows Ruby programs to use the wxWidgets GUI toolkit. 
+It is released under a permissive MIT-style license
+(see the LICENSE file for details).
+
+This version is a beta release, in preparation for a stable release of
+wxruby version 2.0.
+
+------------------------FAQ---------------------------
+
+- What platforms and operating systems are supported in wxRuby2?
+
+  Currently the following are fully supported:
+
+  Windows NT/2000/XP/Vista (i686)
+  OS X 10.3+ (i686 and PowerPc)
+  Linux (i686 + AMD-64)
+
+  It is unlikely that support for old Windows OS's (3.1, 95, 98, ME)
+  will be added to wxRuby2 in the near future, as these operating
+  systems have very limited support for Unicode.
+
+- Why would I choose wxruby over FXRuby, Ruby/GTK, or one of the other 
+   GUI toolkits? Isn't wxruby arriving "too late"?
+   
+   There are several great GUI toolkits available for Ruby, but we 
+   like wxruby better because it has a combination of features that no 
+   other toolkit has:
+   
+     - Cross-platform (MSWindows, Mac OS X, Linux)
+     - Native widgets when possible
+     - Provides a wide selection of widgets
+     - Simple license that is compatible with proprietary and Free Software 
+     - Mature foundation (wxWidgets has been around for over 10 years)
+
+   The really big feature is native widgets. The only other cross-platform 
+   toolkits that use native widgets are either limited (Tk) or expensive if 
+   you want to develop proprietary software (Qt). We are not saying that 
+   those toolkits are bad! Just that wxruby offers a unique set of 
+   features.
+   
+- Why are native widgets important or helpful?
+
+   For one thing, it means that end-users do not have to adjust to a 
+   "foreign" interface. It also ensures maximum compatibility with 
+   "assistive technology" such as screen readers for blind users. 
+   It also allows apps to respect any themes the user may have chosen 
+   through their operating system. No matter how hard a toolkit may try 
+   to emulate a particular UI, there will always be differences in the 
+   look or behavior.
+   
+- How does wxruby2 relate to wxruby (and the wxruby 0.6.0 release)?
+
+   wxruby2 is the "next generation" of wxruby. It is being developed 
+   by the same wxruby team, and is intended to replace the older 
+   code base. wxruby2 is built using SWIG, a powerful tool that makes 
+   it much easier to create and maintain wrappers around C/C++ libraries.
+   
+- Why should I use wxruby2 instead of wxruby?
+
+   First, because development on the original wxruby codebase has stopped. 
+   Everyone is working on wxruby2, so it will continue to improve. Beyond 
+   that, wxruby2 has these advantages over wxruby 0.6.0:
+   
+     - Available as binary gems for MSWindows, OS X, and Linux (GTK)
+	 - Support for more classes, and more methods within classes
+	 - Unicode support
+	 - Vastly improved support for OS X
+	 - Looks much better under Linux because it uses GTK+2
+	 - Simpler and more permissive license 
+	 - Wraps wxWidgets 2.8.3 instead of the older 2.4 series
+	 
+- Is wxruby2 ready for "production" use?
+
+  Yes, pretty much. This is a beta release, and there may be some bugs
+  in some methods, or memory leaks. This release includes all the
+  classes and features that are proposed for inclusion in wxruby 2.0.
+
+  It is considerably more stable and fully-featured than the old 0.6.0
+  release, which was never really stable enough for heavy-duty
+  production use.
+   
+- Does wxruby2 support the Xxx class?
+
+   See the "Documentation" section of the README file, or check the 
+   wxruby web site: http://wxruby.org
+   
+- How are the wxruby 0.6.0 and wxruby2 licenses different?
+
+  wxruby 0.6.0 was released under the wxWindows license, which is a 
+  modified LGPL. It is a good, fair license, allowing use in both Free 
+  Software and proprietary applications. However, it is long and complex, 
+  and is more appropriate for compiled code. wxruby2 is available under a 
+  *very* simple MIT-style license, which allows just about any use with 
+  very few restrictions.
+   
+- I am getting an error trying to compile wxruby2
+
+  Please double-check the requirements. You may be using the wrong
+  version of SWIG, wxWidgets, or some other tool. Double-check the
+  instructions on the wxRuby wiki (http://wxruby.rubyforge.org/)
+  
+  If you need help, please ask your question on the wxruby mailing list 
+  (see the link at http://wxruby.org). 
+
+- I am getting an error trying to run any wxruby2 application, such as 
+  the samples that are included in the gem.
+  
+  If you are using Linux, be sure you have configured your system to 
+  have RUBYOPT=-rubygems. This can be done in .bashrc or /etc/environment, 
+  depending on your distribution and preferences. [More details to follow].
+  
+- Why aren't the wx network, file, date, database and other non-GUI
+  classes supported?
+
+  Because Ruby has its own versions of each of them, providing
+  cross-platform abstractions of these functions with familiar syntax
+  and methods. We assume you are writing your application in Ruby, so it
+  makes sense to keep as much code as possible in Ruby. We have only
+  wrapped the wx classes that are necessary to write GUI code.
+
+  There may be some advantages to porting the Wx network classes into
+  ruby, if they work better with multi-(native)-threaded code. This is
+  currently under evaluation.
+  
+- Why has it taken so long for wxruby2 to be released?
+
+  Nobody is getting paid to develop wxruby, so each of the wxruby developers 
+  are limited in the amount of time they can dedicate to the project. We are 
+  always looking for more volunteers to help code, test, document, manage 
+  the bug list, handle publicity, or do other necessary chores.
+  
+  Wrapping wx is a big project that requires a wide variety of skills. As of 
+  August 2006, the wxRuby project has about 30,000 lines of code, including 
+  ruby, C++, and SWIG scripts. If we weren't using SWIG it would be far bigger.
+
+
+For more details, see the project home page:
+  http://wxruby.org/
+
+
+------------------------USING WXRUBY---------------------------
+INSTALLING:
+
+wxRuby is available as binary gems for MS Windows, Mac OS X, and Linux
+with GTK+ 2. Unless you wish to work on wxRuby itself, we strongly
+recommend installing the gem rather than building from source.
+
+REQUIREMENTS TO CREATE AND RUN WXRUBY APPS:
+
+- Ruby 1.8
+- MS Windows NT/2000/XP/Vista, Mac OS X 10.3+, or Linux with GTK+ 2, 
+
+SAMPLES:
+
+There is a samples/ directory containing many small sample wxRuby apps 
+that demonstrate how to use various classes. A few samples do not work 
+across all platforms at this time.
+	
+The bigdemo sample is fairly comprehensive, but not all of the 
+sections work on all platforms. 
+
+
+WRITING YOUR OWN WXRUBY APP:
+
+To use wxruby-swig in your app, use:
+  require 'wx'
+  
+samples/minimal.rb can be used as a template for creating your 
+own wxruby application.
+
+
+DOCUMENTATION:
+
+- wxRuby-specific API documentation can be found here:
+
+    http://wxruby.org/doc/
+	
+   (Note: This documentation is auto-generated from the C++ wxWidgets API
+   docs. There are some broken links, some sample code in C++, and some
+   sections which do not apply to ruby. The documentation is continually
+   being improved.)
+
+- The latest version of the documentation can be downloaded from the
+  wxRuby 'Files' section on Rubyforge.
+
+  http://www.rubyforge.org/frs/?group_id=35
+
+- Tables summarizing which wx classes are and are not supported can 
+  be found here:
+  
+    http://wxruby.org/wiki/wiki.pl?ClassesSupportedByCategory
+	
+- Most wxWidgets and wxPython tutorials and references can also be used, if 
+  you remember that wxRuby uses ruby_style_naming for methods and variables 
+  instead of MixedCase as used by wxWidgets.
+  
+
+
+API DIFFERENCES FROM WXWIDGETS:
+- In many cases, wxRuby follows the lead of wxPython (or in some cases, 
+  wxPerl), adjusting certain method calls when the C++ style doesn't fit 
+  dynamic languages.
+- Since initialize is reserved in ruby, use SplitterWindow#init instead.
+- Many wx classes have not been wrapped because native ruby classes work 
+  as well or better. These include wxDateTime, wxString, networking 
+  classes, database classes.
+- log_message and log_status take a single string parameter, 
+  rather than a format string followed by additional values 
+  to be inserted. Use Ruby's sprintf if required.
+- ScreenDC extends DC on all platforms, unlike in C++ wx. 
+  This means that you cannot override any virtual methods that were 
+  defined in PaintDC or WindowDC in a ruby subclass of ScreenDC.
+  [Need to verify if this is still true]
+- BusyCursor can be used in a Ruby block to ensure the original cursor 
+  is always restored.
+
+----------------------COMPILING WXRUBY--------------------------
+REQUIREMENTS TO COMPILE/BUILD WXRUBY ITSELF
+
+- rake 
+- SWIG, version 1.3.31. SWIG 1.3.29 or later may work; earlier version 
+  definitely won't
+- wxWidgets 2.8.x SDK. See further information on the wxruby website for
+  recommended compile-time options for wxWidgets.
+
+
+OBTAINING THE SOURCE:
+
+Source code is hosted in Subversion at rubyforge.org. See the links on
+the wxruby web site (http://wxruby.org). Check out the wxruby2
+Subversion module (not the old wxruby module).
+  
+
+BUILDING:
+
+From the top-level directory (typically wxruby2/), 
+just start the rake build with the command:
+
+  rake
+  
+There is no ./configure step, nor do you need to run ruby extconf.rb.
+
+
+INSTALLING THE LIBRARY:
+
+You can install the library using:
+  rake install
+  
+Note that on some systems you may need to be "root" to do this.
+To manually install, copy all the files in the lib/ subdirectory 
+to somewhere on your ruby library path, such as a ruby extensions 
+directory.
+
+
+PORTING TO OTHER PLATFORMS
+
+Platform-dependent rakefiles are used to set up compiler-specific
+settings. The following platforms are currently fully supported:
+
+  Mac OSX (gcc):        rakemacosx.rb
+  MS Windows (VC++):    rakemswin.rb
+  Linux (GTK2 + gcc):   rakelinux.rb
+  
+For other platforms, you may need to edit the appropriate
+platform-dependent rake file if your system is not yet supported, or if
+it is unusual. These files are found in the rake subdirectory:
+
+  MS Windows BC++:      rakebccwin.rb
+  MS Windows MingGW:    rakemingw.rb
+  MS Windows Cygwin:    rakecygwin.rb
+  NetBSD:               rakenetbsd.rb
+
+When editing a platform-dependent rakefile, you might 
+merely need to set one or more of the following variables:
+
+    $extra_cppflags
+    $extra_ldflags
+    $extra_objs
+    $extra_libs
+
+
+CREDITS
+
+Kevin Smith set up the wxruby2 project using SWIG and did much of the
+work that still forms the core of the library in its present form. Over
+the years dozens of volunteers have contributed invaluable patches and
+new functionality. The list is too long to give here, but their
+contributions are recorded in the wxruby mailing list archives.
+
+-----------------------------------------------------------
+
+LEAD MAINTAINER:
+  Alex Fenton
+  alex at pressure dot to

data/lib/wx/classes/app.rb

@@ -1,13 +1,27 @@
 # Copyright 2004-2006 by Kevin Smith
 # released under the MIT-style wxruby2 license
 
+# Controller class which creates and manages all windows.
 class Wx::App
+  # Convenience class method to create simple apps. Starts an
+  # application main_loop, setting up initial windows etc as specified
+  # in the passed block.
+  # block 
+  def self.run(&block)
+    app_klass = Class.new(self)
+    app_klass.class_eval do
+      define_method(:on_init, &block)
+    end
+    the_app = app_klass.new
+    the_app.main_loop
+  end
+
   # This method handles failed assertions from within the WxWidgets C++
   # code. These messages are only generated by a DEBUG build of
   # WxRuby. Such messages usually indicate that the API is being used
   # incorrectly; the file/line reference points to the place in the
   # WxWidgets source code where the assertion was made.
-  def on_assert_failure(file, line, condition, message)
+  define_method(:on_assert_failure) do | file, line, condition, message |
     warn "Wx WARNING: #{message} (#{file}:#{line})"
   end
 

data/lib/wx/classes/bitmap.rb

@@ -15,9 +15,9 @@ class Wx::Bitmap
   # Accepts a block, which will be passed a device context which can be
   # used to draw upon the Bitmap
   def draw
-    dc = MemoryDC.new
+    dc = Wx::MemoryDC.new
     dc.select_object(self)
     yield dc
-    dc.select_object( NULL_BITMAP )
+    dc.select_object( Wx::NULL_BITMAP )
   end
 end

data/lib/wx/classes/checklistbox.rb

@@ -0,0 +1,30 @@
+# Display a listbox with a checkbox for each item
+class Wx::CheckListBox < Wx::ListBox
+
+  # According to the wxWidgets documentation: "wxCheckListBox uses
+  # client data in its implementation, and therefore this is not
+  # available to the application."   
+  #
+  # So, rather than crashing, raise an Exception if this is attempted
+  def append(*args)
+    if args.length == 2 
+      Kernel.raise "Cannot use item data with Wx::CheckListBox"
+    else 
+      super
+    end
+  end
+
+  # As above
+  def insert(*args)
+    if args.length == 3
+      Kernel.raise "Cannot use item data with Wx::CheckListBox"
+    else 
+      super
+    end
+  end
+
+  # As above
+  def set_item_data(index, data)
+    Kernel.raise "Cannot use item data with Wx::CheckListBox"
+  end
+end

data/lib/wx/classes/clientdc.rb

@@ -5,7 +5,7 @@ class Wx::ClientDC
   # always be used via Window#paint, which takes a block receiving the
   # DC. This ensures that the DC is cleaned up at the correct time,
   # avoiding errors and segfaults on exit.
-  def initialize(*args)
+  define_method(:initialize) do | *args |
     Kernel.raise RuntimeError,
                  "Do not instantiate ClientDC directly; use Window#paint",
                  caller[1..-1]

data/lib/wx/classes/commandevent.rb

@@ -0,0 +1,7 @@
+# Class representing interactions with controls such as ListBox
+class Wx::CommandEvent
+  # get_int and get_selection are already synonyms, but neither name
+  # accurately describes what the method does as the event may be a
+  # (de)selection or a check in a CheckListBox
+  alias :get_index :get_int
+end

data/lib/wx/classes/controlwithitems.rb

@@ -0,0 +1,10 @@
+# Superclass of a variety of controls that display lists of items (eg
+# Choice, ListBox, CheckListBox)
+class Wx::ControlWithItems
+  # Make these ruby enumerables so find, find_all, map etc are available 
+  include Enumerable
+  # Passes each valid item index into the passed block
+  def each
+    0.upto(count - 1) { | i | yield i }
+  end
+end

data/lib/wx/classes/evthandler.rb

@@ -42,6 +42,7 @@ class Wx::EvtHandler
 
   # Given the Integer constant Wx::EVT_XXX, returns the convenience
   # handler method name associated with that type of event.
+
   def self.event_name_for_type(name)
     EVENT_NAME_TYPE_MAP.index(name)
   end
@@ -63,33 +64,85 @@ class Wx::EvtHandler
   end
 
   # Registers the event type +ev_type+, which should be an instance of
-  # the Struct class +Wx::EvtHandler::EventType+. 
+  # the Struct class +Wx::EvtHandler::EventType+. This sets up the
+  # mapping of events of that type (identified by integer id) to the
+  # appropriate ruby event class, and defines a convenience evt_xxx
+  # instance method in the class EvtHandler.
   def self.register_event_type(ev_type)
+    # set up the event type mapping
     EVENT_TYPE_CLASS_MAP[ev_type.const] = ev_type.evt_class
     EVENT_NAME_TYPE_MAP[ev_type.name.intern] = ev_type.const
 
     unless ev_type.arity and ev_type.name
       return 
     end
+
+    # set up the evt_xxx method
     case ev_type.arity
     when 0 # events without an id
       class_eval %Q| 
-        def #{ev_type.name}(&block)
-          connect(Wx::ID_ANY, Wx::ID_ANY, #{ev_type.const}, &block)
+        def #{ev_type.name}(meth = nil, &block)
+          handler = acquire_handler(meth, block)
+          connect(Wx::ID_ANY, Wx::ID_ANY, #{ev_type.const}, &handler)
         end |
     when 1 # events with an id
       class_eval %Q|
-        def #{ev_type.name}(id, &block)
-          connect(id, Wx::ID_ANY, #{ev_type.const}, &block)
+        def #{ev_type.name}(id, meth = nil, &block)
+          handler = acquire_handler(meth, block)
+          id  = acquire_id(id)
+          connect(id, Wx::ID_ANY, #{ev_type.const}, &handler)
         end |
     when 2 # events with id range
       class_eval %Q|
-        def #{ev_type.name}(first_id, last_id, &block)
-          connect(first_id, last_id, #{ev_type.const}, &block)
+        def #{ev_type.name}(first_id, last_id, meth = nil, &block)
+          handler  = acquire_handler(meth, block)
+          first_id = acquire_id(first_id)
+          last_id  = acquire_id(last_id)
+          connect( first_id, last_id, #{ev_type.const}, &handler)
         end |
     end
   end
 
+  # Not for external use; determines whether to use a block or call a
+  # method in self to handle an event, passed to connect. Makes evt_xxx
+  # liberal about what it accepts - aside from a block, it can be a
+  # method name (as Symbol or String), a (bound) method object, or a
+  # Proc object
+  def acquire_handler(meth, block)
+    if block and not meth
+      return block
+    elsif meth and not block
+      h_meth = case meth
+        when Symbol, String : self.method(meth)
+        when Proc : meth
+        when Method : meth.to_proc
+      end
+      if h_meth.arity == 1
+        return lambda { | evt | h_meth.call(evt) }
+      else
+        return lambda { h_meth.call }
+      end
+    else
+      Kernel.raise ArgumentError,
+                  "Specify event handler with a method, name, proc OR block"
+                  caller
+    end
+  end
+
+  # Not for external use; acquires an id either from an explicit Fixnum
+  # parameter or by calling the wx_id method of a passed Window.
+  def acquire_id(window_or_id)
+    case window_or_id
+    when Fixnum : window_or_id
+    when Wx::Window, Wx::MenuItem : window_or_id.wx_id
+    else Kernel.raise ArgumentError, 
+                     "Must specify Wx::Window event source or its Wx id, " +
+                     "not '#{window_or_id.inspect}'",
+                      caller
+    end
+  end
+  private :acquire_id, :acquire_handler
+
   # Definitions for all event types that are part by core wxRuby. Events
   # that are mapped to class Wx::Event are TODO as they are not
   # currently wrapped by the correct class. All StyledTextCtrl
@@ -195,6 +248,9 @@ class Wx::EvtHandler
     EventType['evt_close', 0,
               Wx::EVT_CLOSE_WINDOW, 
               Wx::CloseEvent],
+    EventType['evt_collapsiblepane_changed', 1,
+              Wx::EVT_COMMAND_COLLPANE_CHANGED, 
+              Wx::CollapsiblePaneEvent],
     EventType['evt_combobox', 1,
               Wx::EVT_COMMAND_COMBOBOX_SELECTED, 
               Wx::CommandEvent],

data/lib/wx/classes/listctrl.rb

@@ -0,0 +1,9 @@
+# Multi-item control with numerous possible view styles
+class Wx::ListCtrl
+  # Make these ruby enumerables so find, find_all, map are available 
+  include Enumerable
+  # Passes each valid item index into the passed block
+  def each
+    0.upto(item_count - 1) { | i | yield i }
+  end
+end

data/lib/wx/classes/menu.rb

@@ -0,0 +1,62 @@
+# A single labelled list within a drop-down menu, or a popup menu
+class Wx::Menu
+
+  # In the standard WxWidgets API, the methods append, prepend, insert
+  # (and their variants) require a constant integer id as the identifier
+  # of the menu item. This is then used in event handling. 
+  #
+  # In WxRuby the use of explicit ids can be avoided in most cases,
+  # being a most unruby-ish practice. So, by analogy with the general
+  # use of Wx::Window classes and event handlers, where the id is
+  # implicit in the constructor, and the window can be passed direct to
+  # the event handler setup method, the below sets up a similar facility
+  # for adding items to Wx::Menu.
+  #
+  # For all these methods, the only required argument is the string name
+  # of the menu item; a system-default id will be supplied if no
+  # explicit one is given. The return value of these methods in all
+  # cases is a Wx::MenuItem object, which can be passed directly as the
+  # first argument to an evt_menu handler.
+  def self.methods_with_optional_ids(*meth_names)
+    class_eval do 
+      meth_names.each do | meth |
+        old_meth = instance_method(meth)
+        define_method(meth) do | *args |
+          case args.first
+            when Fixnum : old_meth.bind(self).call(*args)
+            when String : old_meth.bind(self).call(Wx::ID_ANY, *args)
+            when Wx::MenuItem : old_meth.bind(self).call(args.first)
+          end
+        end
+      end
+    end
+  end
+
+  # Create the optional-id methods
+  methods_with_optional_ids :append, :prepend,
+                            :append_check_item, :prepend_check_item, 
+                            :append_radio_item, :prepend_radio_item
+
+  # This is much the same as above, except for insert and variants,
+  # which take an additional first argument, the position at which to
+  # insert the new item.
+  def self.methods_with_optional_ids_and_pos(*meth_names)
+    class_eval do 
+      meth_names.each do | meth |
+        old_meth = instance_method(meth)
+        define_method(meth) do | pos, *args |
+          case args.first
+            when Fixnum : old_meth.bind(self).call(pos, *args)
+            when String : old_meth.bind(self).call(pos, Wx::ID_ANY, *args)
+            when Wx::MenuItem : old_meth.bind(self).call(pos, args.first)
+          end
+        end
+      end
+    end
+  end
+
+  # Create the optional-id methods
+  methods_with_optional_ids_and_pos :insert,
+                                    :insert_check_item,
+                                    :insert_radio_item
+end

data/lib/wx/classes/menuitem.rb

@@ -0,0 +1,7 @@
+# An individual item within a frame or popup menu
+class Wx::MenuItem
+  # Get the Wx id, not Ruby's deprecated Object#id
+  alias :id :get_id
+  # In case a more explicit option is preferred.
+  alias :wx_id :get_id
+end

data/lib/wx/classes/paintdc.rb

@@ -4,7 +4,7 @@ class Wx::PaintDC
   # always be used via Window#paint, which takes a block receiving the
   # DC. This ensures that the DC is cleaned up at the correct time,
   # preventing serious errors on some platforms.
-  def initialize(*args)
+  define_method(:initialize) do | *args |
     Kernel.raise RuntimeError,
                  "Do not instantiate PaintDC directly; use Window#paint",
                  caller[1..-1]

data/lib/wx/classes/timer.rb

@@ -34,7 +34,7 @@ class Wx::Timer
     @@__unowned_timers__ ||= []
 
     # remove from list of previous owner
-    if @__owner__
+    if defined?(@__owner__) and @__owner__
       @__owner__.instance_eval { @__owned_timers__.delete(this_timer) }
     end
 
@@ -51,7 +51,7 @@ class Wx::Timer
 
     # Then add to list of new owner, setting destructor hook if required    
     new_owner.instance_eval do
-      if not @__owned_timers__
+      if not defined?(@__owned_timers__)
         @__owned_timers__ = []
         unless self.kind_of?(Wx::App) # Don't set up hook on App
           evt_window_destroy do | evt |