wxruby users - Apr 2004 - Yesterday''s adventures (calendar sample; swig)

At each step, I think I am past most of the big hurdles. At each step, I 
find another one. I''m sharing these development stories on the list for
a few reasons:
1. Perhaps some of you will find the stories interesting
2. To preserve my lessons in the list archives so I, or someone else, 
can (re)learn from them later
3. As a record of tangible progress
4. To vent some frustration <grin>

Yesterday, I spent a few hours debugging a weird problem in the calendar 
sample. You can actually see a bug in the wxRuby 0.3 release: If you use 
the menu to toggle the month selector style, it doesn''t actually update
all the widgets correctly. You can resize the window, and see that the 
dropdowns start to overlap the rest of the calendar control.

The problem was that the sample was using set_window_style_flag to 
change the control style. But changing that style on an existing control 
really doesn''t work. So the sample needs to delete the old calendar 
control, and create a new one.

But when you do that, you need to explain to the sizer what you are 
trying to do. The end result (not checked in yet) is pretty clean and 
straightforward. But it''s about the 100th thing I tried! I also did a 
lot of refactoring and cleanup of the rest of the calendar sample.

The other big struggle was trying to expose all the stock objects (like 
the color wxRED). The fundamental problem is that swig performs its 
constant initialization at library load time, but those stock objects 
have not yet been created. wxRuby 0.3 delayed constant initialization 
until main_loop was called.

I tried several ways to get around this. At one point, I ended up in a 
weird situation where:

   include Wx
   RED

failed, but

   include Wx
   Wx::RED

worked. I would have guessed that would be impossible in Ruby.

Anyway, I hacked it to work (not yet checked in) by doing some swig 
post-processing to initialize the constants in on_init. Before I check 
it in, I''ll try to make it cleaner by creating a subclass of the App 
object, and override the on_init method there.

With my old wxpp approach, I could always insert arbitrary code anywhere 
I wanted. With swig, it''s much more rigid, so I have to work within the
rules. It can be quite frustrating at times, but swig is still proving 
to be a big win overall.

Kevin

Kevin Smith wrote:
>
> At each step, I think I am past most of the big hurdles. At each step, I
> find another one. I''m sharing these development stories on the
list for
> a few reasons:
> 1. Perhaps some of you will find the stories interesting
> 2. To preserve my lessons in the list archives so I, or someone else,
> can (re)learn from them later
> 3. As a record of tangible progress
> 4. To vent some frustration <grin>
As long as you are willing to do it, I think this is excellent -- keep up
the good work!

Curt