wxruby users - Aug 2004 - Documents, Views and DocManagers

Hi,

Are there any effort in making wxDocument, wxView, etc types of classes 
avaiable under wxRuby? For supporting SDI/MDI architecture.

Cheers,
Phuah Yee Keat

Not yet. Right now the big focus is on getting the widgets imported. We 
don''t have a lot of the wxWidgets auxiliary classes yet.

Nick

Phuah Yee Keat wrote:
> Hi,
>
> Are there any effort in making wxDocument, wxView, etc types of 
> classes avaiable under wxRuby? For supporting SDI/MDI architecture.
>
> Cheers,
> Phuah Yee Keat
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
> .
>

Is there any code out there which has basic text editing functionality
(cut/paste,undo/redo,find/replace etc..) in wxRuby?

I am planning on writing a wxRuby version of DBTalk
(http://www.insula.cz/dbtalk/) and would like to avoid reinventing the
editor wheel :-)

TIA,
-- shanko

Shashank Date wrote:
> Is there any code out there which has basic text editing functionality
> (cut/paste,undo/redo,find/replace etc..) in wxRuby?
The basic Wx::TextCtrl implements cut/paste/undo out of the box. On my 
system (WXMSW) these are also bound to the standard shortcuts: CTRL-V, 
CTRL-X, CTRL-C, CTRL-Z

Not sure about Find and Replace. There''s a pre-built "Find"
Dialog class
available for getting the user''s search string.

cheers
alex

Do you mean a Text Control? I think wxTextCtrl should do that.

Nick

Shashank Date wrote:
>Is there any code out there which has basic text editing functionality
>(cut/paste,undo/redo,find/replace etc..) in wxRuby?
>
>I am planning on writing a wxRuby version of DBTalk
>(http://www.insula.cz/dbtalk/) and would like to avoid reinventing the
>editor wheel :-)
>
>TIA,
>-- shanko
>
>_______________________________________________
>wxruby-users mailing list
>wxruby-users@rubyforge.org
>http://rubyforge.org/mailman/listinfo/wxruby-users
>
>
>
>  
>

That should do it !
Thanks Nick and Alex ... I will look into it.
-- shanko
----- Original Message ----- 
From: "Nick" <devel@nicreations.com>
To: "General discussion of wxRuby" <wxruby-users@rubyforge.org>
Sent: Thursday, August 19, 2004 9:03 AM
Subject: Re: [Wxruby-users] Text Editor in wxRuby?

> 
> Do you mean a Text Control? I think wxTextCtrl should do that.
> 
> Nick
> 
> Shashank Date wrote:
> 
> >Is there any code out there which has basic text editing functionality
> >(cut/paste,undo/redo,find/replace etc..) in wxRuby?
> >
> >I am planning on writing a wxRuby version of DBTalk
> >(http://www.insula.cz/dbtalk/) and would like to avoid reinventing the
> >editor wheel :-)
> >
> >TIA,
> >-- shanko
> >
> >_______________________________________________
> >wxruby-users mailing list
> >wxruby-users@rubyforge.org
> >http://rubyforge.org/mailman/listinfo/wxruby-users
> >
> >
> >
> >  
> >
> 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>

Hi wxRuby Gurus,
> That should do it !
> Thanks Nick and Alex ... I will look into it.
I have attached a small app which showcases wxTextCtrl.
However, I haven''t been able to make the following 
functionality (as described in wxWindows Help) work:

wxTextCtrl::EmulateKeyPress
wxTextCtrl::HitTest
wxTextCtrl::OnDropFiles
wxTextCtrl::ShowPosition
EVT_TEXT_URL(id, func) 

My platform:
 * Win XP(Home) 
 * ruby 1.8.2 (2004-06-29) [i386-mswin32]
 * wxRuby 0.4.0

Any  suggestions ?
TIA,
-- shanko
> ----- Original Message ----- 
> From: "Nick" <devel@nicreations.com>
> To: "General discussion of wxRuby"
<wxruby-users@rubyforge.org>
> Sent: Thursday, August 19, 2004 9:03 AM
> Subject: Re: [Wxruby-users] Text Editor in wxRuby?
> 
> 
> > 
> > Do you mean a Text Control? I think wxTextCtrl should do that.
> > 
> > Nick
> > 
> > Shashank Date wrote:
> > 
> > >Is there any code out there which has basic text editing
functionality
> > >(cut/paste,undo/redo,find/replace etc..) in wxRuby?
> > >
> > >I am planning on writing a wxRuby version of DBTalk
> > >(http://www.insula.cz/dbtalk/) and would like to avoid reinventing
the
> > >editor wheel :-)
> > >
> > >TIA,
> > >-- shanko
> > >
> > >_______________________________________________
> > >wxruby-users mailing list
> > >wxruby-users@rubyforge.org
> > >http://rubyforge.org/mailman/listinfo/wxruby-users
> > >
> > >
> > >
> > >  
> > >
> > 
> > _______________________________________________
> > wxruby-users mailing list
> > wxruby-users@rubyforge.org
> > http://rubyforge.org/mailman/listinfo/wxruby-users
> > 
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wxTextCtrl.rbw
Type: application/octet-stream
Size: 5495 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20040819/8f7f622a/wxTextCtrl.obj

Shashank Date wrote:
> Hi wxRuby Gurus,
> 
> 
>>That should do it !
>>Thanks Nick and Alex ... I will look into it.
> 
> 
> I have attached a small app which showcases wxTextCtrl.
> However, I haven''t been able to make the following 
> functionality (as described in wxWindows Help) work:
...
> wxTextCtrl::OnDropFiles
Doesn''t work for me either. Given that the method''s
Windows-only, it may
not be implemented at all in WxRuby.

I then tried using the drag and drop classes:
http://wxwidgets.org/manuals/2.4.2/wx495.htm#wxdndoverview

.. which seem to work, but not on a text control:

class MyDropTarget < Wx::FileDropTarget
   def on_drop_files(x, y, files)
     p files.join("\n")
   end
end

# ...

# doesn''t seem to work - doesn''t allow dragging into text
@m_text.set_drop_target( MyDropTarget.new() )
# but this does
some_frame.set_drop_target( MyDropTarget.new() )



Not quite sure what''s going on here. The TextCtrl seems to want to 
handle the mouse events its own way, for example by scrolling the text 
up and down, rather than handling the drag.

> wxTextCtrl::ShowPosition
I''ve used this in an app, and it works fine for me - it takes a 
character index and scrolls to it, making the line with that character 
the first in the control. What''s the problem you''re having?
> EVT_TEXT_URL(id, func)
You need to add the constant Wx::TE_AUTO_URL to make the TextCtrl 
recognise URLS and fire events off them. This works for me. However, the 
event that is generated at the moment a Wx::Event, not a 
Wx::TextUrlEvent, and this class only has limited methods. Importantly 
for your purposes, it doesn''t have get_mouse_event(), so you may be 
stuck until this is implemented.

cheers
alex

alex fenton wrote:
> Shashank Date wrote:
> 
>> wxTextCtrl::OnDropFiles
> 
> Doesn''t work for me either. Given that the method''s
Windows-only, it may
> not be implemented at all in WxRuby.
Oops. There is an implementation, but not a helpful one. In wxruby 0.4, 
I have to write custom code for each OnXxx method. I forgot to do so for 
this one, so wxpp created a default implementation that allows you to 
call it, but a ruby-overridden version will not be called by the system.

This kind of thing is handled automatically by swig, and it is a major 
pain in the wxpp world. Perfect example of why I am so eager to switch.

Kevin

Hi Alex,

----- Original Message ----- 
From: "alex fenton" <alex@pressure.to>
<snip>
> > wxTextCtrl::OnDropFiles
> 
> Doesn''t work for me either. Given that the method''s
Windows-only, it may
> not be implemented at all in WxRuby.
Ok ... I will have to wait till it gets implemented.
> > wxTextCtrl::ShowPosition
> 
> I''ve used this in an app, and it works fine for me - it takes a 
> character index and scrolls to it, making the line with that character 
> the first in the control. What''s the problem you''re
having?
The problem was, I was not sure what to expect. So I was passing
0 as the index and there were only three lines in the control so it was
always visible ;-) 

It is  (now) working ... rather my expectations are set correctly.
Thanks for the explanation.
> > EVT_TEXT_URL(id, func)
> 
> You need to add the constant Wx::TE_AUTO_URL to make the TextCtrl 
> recognise URLS and fire events off them. This works for me. However, the 
> event that is generated at the moment a Wx::Event, not a 
> Wx::TextUrlEvent, and this class only has limited methods. 
Actually, after adding the constant, I got the TextUrlEvent. But ...
> Importantly  for your purposes, it doesn''t have get_mouse_event(),
> so you may be  stuck until this is implemented.
... that is correct, I was not able to get (and ignore) the mouse events.
Again, I will wait. 
 
> cheers
> alex
Thanks a lot, Alex.
-- shanko

I am learning how to use splitters by reading the Splitter sample which came
with the wxRuby install.
The sample works fine.

I have attached my modified version which replaces MyCanvas in the sample
with MyLeftFrame and MyRightFrame. But my modifications do not work :-(

If I click on the menu option Splitter > Split Horizontally, the left and
right frames pop out of the main window and any attempt to do anything
after, crashes the program.  Also, when I try to move the splitter bar by
dragging it, it does not erase the old one so I get mulitple splitter bars.

What am I doing wrong ? (Something really silly, I imagine).

My platform:
 * Win XP(Home)
 * ruby 1.8.2 (2004-06-29) [i386-mswin32]
 * wxRuby 0.4.0

TIA,
-- shanko
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wxSplitter.rbw
Type: application/octet-stream
Size: 8245 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20040820/93573585/wxSplitter.obj

Shashank Date wrote:
>  Also, when I try to move the splitter bar by
>dragging it, it does not erase the old one so I get mulitple splitter bars.
>  
>
Hi Shashank,

You need to tell your SplitterWindow to repaint itself. In your 
MySplitterWindow class I did this:

    def onPositionChanged(event)
        log_status(@m_frame, "Position has changed, now = %d (or %d)",
                event.get_sash_position(), get_sash_position())
        refresh( true ) #<---tell the current instance of MySplitter to 
repaint itself
        event.skip()
    end


refresh is a method derived from the wx::Window class, and it takes a 
boolean argument as the initial argument. When calling it on 
MySplitterWindow after an event has occurred causes it to repaint itself.

I''m looking into your other issues as well, so hopefully more to come!

Zach

Also I forgot to note. You may want to move the "refresh" call in the 
code I posted to another event handler and play with performance since 
you want the window to repaint itself as few as times as possible.

Zach

Zach Dennis wrote:
> Shashank Date wrote:
>
>>  Also, when I try to move the splitter bar by
>> dragging it, it does not erase the old one so I get mulitple splitter 
>> bars.
>>  
>>
> Hi Shashank,
>
> You need to tell your SplitterWindow to repaint itself. In your 
> MySplitterWindow class I did this:
>
>    def onPositionChanged(event)
>        log_status(@m_frame, "Position has changed, now = %d (or
%d)",
>                event.get_sash_position(), get_sash_position())
>        refresh( true ) #<---tell the current instance of MySplitter to 
> repaint itself
>        event.skip()
>    end
>
>
> refresh is a method derived from the wx::Window class, and it takes a 
> boolean argument as the initial argument. When calling it on 
> MySplitterWindow after an event has occurred causes it to repaint itself.
>
> I''m looking into your other issues as well, so hopefully more to
come!
>
> Zach
> _______________________________________________
> wxruby-users mailing list
> wxruby-users@rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>
>

Shashank Date wrote:
>I have attached my modified version which replaces MyCanvas in the sample
>with MyLeftFrame and MyRightFrame. But my modifications do not work :-(
>
>If I click on the menu option Splitter > Split Horizontally, the left and
>right frames pop out of the main window and any attempt to do anything
>after, crashes the program.  
>
Hi again Shashank,

The problem you are seeing here is because you are trying to place a 
subclass (MyLeftFrame , MyRightFrame) of wx::Frame inside of another 
wx::Frame (MyFrame). (see lines 140-142 in the file you originally attached)

Think of a wx::Frame can be considered a Top Level window, in that it 
has to be the parent, it cannot be the child... at least when visually 
displayed.

        @m_left = MyLeftFrame.new(@m_splitter)

The code here is correct, and you can traverse the *parent* tree to find 
your instance of @m_splitter as the actual parent of @m_left. But when 
these are displayed on the screen a wx::Frame will be created as a 
separate window, because it is a toplevel object.

You can make the following code adjustments and your code will run how 
you want:

MyLeftFrame < Frame     to    MyLeftFrame < Panel  
MyRightFrame < Frame   to      MyRightFrame < Panel 


Zach

I am developing a new Sizer / LayoutManager. I am first writing all of 
this in ruby (I know c, but not c++) and then once I get it the way I 
want it I am going to take the time to get up to speed and convert it to 
c++.

This is how I instantiate and add widgets to my application.

@frame = Frame.new
@sizer = AppSizer.new( @frame )

@sizer.add( { ''label''=>''Field1:'' ,
''type''=>''TextCtrl'' } )
@sizer.add( { ''label''=>''Field2:'' ,
''type''=>''ComboBox'' ,
''values'' =>
["val1","val2","val3","val4"] } )
@sizer.add( { ''type'' => ''TextCtrl'' ,
''default_text'' => ''Enter text here''
, ''row'' => ''same'' } )

Here is my design question, if I explain this poorly please just tell 
me...then I will try to explain better.

When the ''label'' key/value pair is passed in it tells the
AppSizer that
the widget will need a label and what the text of that label should be. 
Currently when I layout my widgets I do it in the following manner:

1 - Apply default key/value pairs
2 - Loop through array of widget hash''s
3 - Create widget (label)
4 - Create widget
5 - end loop

I am thinking of revamping these steps  to:

1 - Apply default key/value pairs
2 - Extract ''label'' key/value pairs from the array of widget
hashs, and
and readd them as their own widget hash
3 - Loop through array of widget hashs
4 - Create widget
5 - end loop

In the current solution the passed in widget hash (ie: { 
''label''=>''Field1:'' ,
''type''=>''TextCtrl'' } ) is never modified.
The
AppSizer looks for the ''label'' key and then executes a block
of code
that creates the label, otherwise it skips that block of code and goes 
to the code that creates the actual widgets.

In the new solution AppSizer would preprocess all of the widget hash''s 
and extract the ''label'' key/value pair, then reinsert a new
widget hash
into its array of widget hashs. When AppSizer got to the "guts" of the
code it wouldn''t have to check for the ''label'' key,
because there would
be no special block of code to execute. This would basically be the same 
as the user doing the following:
@sizer.add( { ''type''=>''StaticText'' ,
''default_text'' => ''Field1:'' } );
@sizer.add( { ''type''=>''TextCtrl'' ,
''row''=>''same" } );
, but by preprocessing the ''label'' tag it makes it less for
the user to
have to write.

The more I think about this the more I pick the new solution because it 
adds flexibility and better design to the code, while the current 
solution is already implemented. Any feedback on my two solutions, or if 
you have another idea.....that would be great. Thanks,

Zach

I am looking for more input on my AppSizer that I am creating. Let me 
start with a little on how the AppSizer works. (See the attached JPEG 
file for output of the current AppSizer implementation. The code used 
for the JPEG is given at the bottom of this email.)

The AppSizer takes as Hash for each widget it is to create. Example:
    @app_sizer.add( {
''type''=>''StaticText'' ,
''font'' => Wx::Font.new( 15
, Wx::DEFAULT , Wx::NORMAL , Wx::BOLD )  } )

I currently provide the following hash keys for functionality, with a 
global scale:
    - label, which is an optional key, tells the AppSizer to generate a 
label for the widget
    - type, which is the wx widget that is to be created
    - font, which is the font setting ot be used on the widget
    - x, which is the x position of the widget. this is optional because 
AppSizer will try to automatically place every widget by default
    - y, which is the y position of the widget. this is optional because 
AppSizer will try to automatically place every widget by default
    - *events*, all events are automatically mapped to the widget using 
a key of the event function. ie: ''evt_button'' or
''evt_key_down'',
where the value for that key is a proc object
    - horizontal spacing between widgets (columns)
    - vertical spacing between widgets (rows)
    - same row...which tells the Sizer if the widget should move to the 
next row or if it should try to place it on the current row

Features I would like to add before I release are:

- Row alignment / justification, so the user can specify if they want a 
widget left, center or right justified
    ie: @app_sizer.ad(
{''type''=>''StaticText'' ,
''default_text''=>''Right
Justified'' , ''align''=>Wx::ALIGN_RIGHT }

Is there anything else anyone can think of that would be nice? I have 
attached a jpeg file which...is created using the following code:

    @app_sizer.add( { ''type'' =>
''StaticText'' , ''default_text'' =>
''This
is a header'' ,
      ''font'' =>  Wx::Font.new( 15 , Wx::DEFAULT ,
Wx::NORMAL , Wx::BOLD
) } )
    @app_sizer.add( { ''label''=>''TextCtrl
:'' , ''type''=>''TextCtrl'' } )
    @app_sizer.add( {
''label''=>''ComboBox:'' ,
''type''=>''ComboBox'' ,
''values'' => 
["val1","val2","val3","val4"] } )
    @app_sizer.add( { ''type'' =>
''TextCtrl'' , ''default_text'' =>
''Enter
text here'' , ''samerow'' => true } )
    @app_sizer.add( { ''type'' =>
''TextCtrl'' , ''default_text'' =>
''Enter
text here2'' , ''samerow'' => true } )
    @app_sizer.add( { ''type'' =>
''TextCtrl'' , ''default_text'' =>
''Enter
text here3'' , ''samerow'' => true } )
    @app_sizer.add( {
''label''=>''StaticText:'' ,
''type''=>''StaticText'' ,
''default_text'' => "Hello World" } )
    @app_sizer.add( { ''type''=>''Button'' ,
''default_text'' => ''&Click Me'',
      ''evt_button''=>proc{ puts "I''m being
clicked" } } )

I am trying to make this Sizer extremely easy to use for the developer. 
I hope that if I can accomplish this it will provide another reason for 
more Ruby people to join the wxRuby community. I am totally open for 
suggestion.

Also to Kevin, Curt and Nick....I apologize if i''m not hitting up the 
more important area''s of wxRuby (like getting more widgets moved over 
from wxWindows) and I plan to do that once I make the jump from c to 
c++. I feel that by doing something in Ruby (like AppSizer), then I can 
have something to move to c++, where I know how it should work and how 
it should function. I think that will drastically reduce my c++ learning 
curve.

Thanks,

Zach





-------------- next part --------------
A non-text attachment was scrubbed...
Name: appsizer.jpg
Type: image/jpeg
Size: 12856 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/wxruby-users/attachments/20040822/f59131d2/appsizer-0001.jpg

Zach Dennis wrote:
> I am developing a new Sizer / LayoutManager. I am first writing all of 
> this in ruby (I know c, but not c++) and then once I get it the way I 
> want it I am going to take the time to get up to speed and convert it to 
> c++.
For something like this, I have a hard time imagining that speed would 
be an issue.
> This is how I instantiate and add widgets to my application.
> 
> @frame = Frame.new
> @sizer = AppSizer.new( @frame )
> 
> @sizer.add( { ''label''=>''Field1:'' ,
''type''=>''TextCtrl'' } )
> @sizer.add( { ''label''=>''Field2:'' ,
''type''=>''ComboBox'' ,
''values'' =>
> ["val1","val2","val3","val4"] } )
> @sizer.add( { ''type'' => ''TextCtrl'' ,
''default_text'' => ''Enter text here''
> , ''row'' => ''same'' } )
Personally, I really dislike named parameters. I know many people like them.
> Here is my design question, if I explain this poorly please just tell 
> me...then I will try to explain better.
I think you explained it well. Paraphrasing: Should you handle the 
"label" case during the "parsing" phase (by inserting a new
user-level
widget into the list), or during the "execution" phase (by creating a 
wxruby label just before creating the main wxruby widget)?

In my opinion, either way you have a special case. One way has to modify 
the original array of specs. The other way has to do a last-minute if. 
Really, I don''t see either one as being dramatically better than the 
other. They both seem fine.

The second choice may have an advantage someday of allowing users to 
choose custom label attributes (e.g. fonts) that would be easier to 
apply both to label widgets that they explicitly add, and to those that 
are inserted implicitly by ''label''=>''xxx''
parameters. But that''s in the
future, so I wouldn''t worry about it now.

I can''t see any immediate benefits that would cause me to want to
change
the working code to the new design. However, if you feel the new design 
would be easier for a coder to understand or maintain, that might be a 
good enough reason. Or perhaps you have some other specific feature in 
mind that would be easier if you made the change?

Cheers,

Kevin

Zach Dennis wrote:
> Is there anything else anyone can think of that would be nice? 
Yes: I would want an option to use a flex grid, with two columns. The 
first column would contain the label for that row (if any), and the 
second column would contain the rest of the widgets. This is great for 
creating a dialog box where the labels are to the left, and all the 
field data entry boxes are nicely aligned.

I got this idea from a ParagraphLayout manager for Java, which is 
described near the bottom of  this page:
   http://www.huxtable.com/java/layout/
> Also to Kevin, Curt and Nick....I apologize if i''m not hitting up
the
> more important area''s of wxRuby (like getting more widgets moved
over
> from wxWindows) and I plan to do that once I make the jump from c to 
> c++. I feel that by doing something in Ruby (like AppSizer), then I can 
> have something to move to c++, where I know how it should work and how 
> it should function. I think that will drastically reduce my c++ learning 
> curve.
No problem. We''re all doing what we can, and none of us expect anyone
to
contribute more than they are currently able (and willing) to do. 
Posting answers to questions, and sharing your projects like this are 
valuable contributions to the growth of the community. Thank you.

Adding widgets to wxruby-swig usually does not require any c++ knowlege, 
so if you could play around with it, and get your sample apps working 
with it, that would be a big help.

I think having a solid understanding of ruby will definitely help you 
learn c++.

Kevin

Hello Zach,

Thanks a lot for your tips ...

----- Original Message ----- 
<snip>
>     def onPositionChanged(event)
>         log_status(@m_frame, "Position has changed, now = %d (or
%d)",
>                 event.get_sash_position(), get_sash_position())
>         refresh( true ) #<---tell the current instance of MySplitter to 
Yes, refresh did the job.
>         event.skip()
>     end
> 
> 
> refresh is a method derived from the wx::Window class, and it takes a 
> boolean argument as the initial argument. When calling it on 
> MySplitterWindow after an event has occurred causes it to repaint itself.
> 
> I''m looking into your other issues as well, so hopefully more to
come!
Thanks again, for your attention ..
> Zach
-- shanko

Hi Zach,

----- Original Message ----- 
From: "Zach Dennis" <zdennis@mktec.com>
<snip>
> 
> You can make the following code adjustments and your code will run how 
> you want:
> 
> MyLeftFrame < Frame     to    MyLeftFrame < Panel  
> MyRightFrame < Frame   to      MyRightFrame < Panel 
But of course !  This worked like a charm :-)
Too bad, we cannot have splitters nested inside splitters.
Thanks,
> Zach
-- shanko

Shashank Date wrote:
> Too bad, we cannot have splitters nested inside splitters.
We can. I have used them myself. SplitterWindow inherits from Window, 
not from Frame. So they can be nested.

Kevin

Hi,

----- Original Message ----- 
From: "Kevin Smith" <wxruby@qualitycode.com>
To: "General discussion of wxRuby" <wxruby-users@rubyforge.org>
Sent: Tuesday, August 24, 2004 6:54 AM
Subject: Re: [Wxruby-users] Using Splitter ...

> Shashank Date wrote:
> > Too bad, we cannot have splitters nested inside splitters.
> 
> We can. I have used them myself. SplitterWindow inherits from Window, 
> not from Frame. So they can be nested.
> 
> Kevin
Is there is a better way to achieve this?
TIA,
-- shanko

#------------------------------------------
require ''wxruby''

class MyFrame < Wx::Frame

  def initialize(parent,id,title)
    super

    split1 = Wx::SplitterWindow.new(self,-1)
    split2 = Wx::SplitterWindow.new(split1,-1)
    left   = Wx::TextCtrl.new(split1, -1)
    split1.split_vertically(left,split2)

    top    = Wx::TextCtrl.new(split2, -1)
    bottom = Wx::Grid.new(split2, -1)
    bottom.create_grid( 21, 12 )

    split2.split_horizontally(top,bottom)
  end  

end

class MyApp < Wx::App

  def on_init 
    frame = MyFrame.new(nil, -1, "wxSplitterWindow Example")
    frame.show()
  end
  
end 

a = MyApp.new
a.main_loop()

__END__

Shashank Date wrote:
> Is there is a better way to achieve this?
>
It may depend on what you want to do with your GUI. It''s (your code is)
short, concise and clean. Depending on your expectations of the GUI and 
how it interacts with the user may allow you to determine a *better* way 
to achieve it. I know this is a vague response, but for what it looks 
like you are doing it looks like you already the best solution.

Zach

Shashank Date wrote:
> 
> Is there is a better way to achieve this?
> class MyFrame < Wx::Frame
> 
>   def initialize(parent,id,title)
>     super
> 
>     split1 = Wx::SplitterWindow.new(self,-1)
>     split2 = Wx::SplitterWindow.new(split1,-1)
>     left   = Wx::TextCtrl.new(split1, -1)
>     split1.split_vertically(left,split2)
> 
>     top    = Wx::TextCtrl.new(split2, -1)
>     bottom = Wx::Grid.new(split2, -1)
>     bottom.create_grid( 21, 12 )
> 
>     split2.split_horizontally(top,bottom)
>   end  
Looks good to me. Personally, I might do things in a slightly different 
order, and I might extract some of it out to a helper method, but 
basically it''s about how I would do things.

I don''t like that the constructors require the parent, but then later 
you have to tell the parent which panes to split. But that seems to be a 
basic constraint of wx.

Kevin

Does wxRuby support transparency on it''s Panels, Frames, Widgets,
images
, etc....

Just curious, I have no real need for it atm,

Zach

Zach Dennis wrote:
> Does wxRuby support transparency on it''s Panels, Frames, Widgets, 
> images , etc....
I don''t believe so. I know wxWidgets 2.5 has some alpha-channel bitmap 
support, but only in the Bitmap and Image classes.

Nick

I started a project on RubyForge for layout managers for use with 
wxRuby. I have released 0.0.2 Alpha as a source zip file, and as a RubyGem.

http://rubyforge.org/frs/?group_id=355

The documentation is poor and the capabilities are small, so I am 
looking for Alpha testers. The three available layouts are:

1 - BaseLayout  - The base layout manager which all other layout 
managers are derived. This lays out widgets in rows and each row can be 
left, center or right aligned each.

2 - ParagraphLayout - This is like the java based ParagraphLayout. It is 
intended for use with Dialogs. The first column in every row is a label. 
Each label and be Left or Right aligned.

3 - FlowLayout - This is like the java based FlowLayout. It supports 
HORIZONTAL and VERTICAL orientation where the space is evenly 
distributed between all widgets.

I am also looking for people willing to donate to helping me with 
documentation and/or the wiki. This is one area where I struggle so any 
help would be great! If you are interested or have questions or comments 
please feel free to contact me any time.

Thanks,

Zach

I have been quiet on this list recently, but for good reason. I see I 
have 23 downloads of my wxrubylayouts manager! That is a plus, however 
the downside is that my implementation at Alpha stage 0.0.2 is very very 
bad and the documentation is horrible. The gem also didn''t work (my 
fault entirely).

I am working on nice, html documentation and I have spent my time on 
that the past few days. I have also enhanced ParagraphLayout, and I have 
added a "correct" FlowLayout. (The old FlowLayout was actually A 
BoxLayout). So in the next release 0.0.3 there will be the following 
layout managers:

- BaseLayout
- BoxLayout
- FlowLayout
- ParagraphLayout

plus there will be html documentation and the ruby gem will work on both 
Windows and Linux machines. (I now have a Win2K, WinXP and Debian at 
home to test it on)

My quest for feedback is this....should I quit posting [ANN] or news on 
RubyForge about small releases (like 0.0.1 and 0.0.2)? Should I instead 
wait until I have a decent sized library and good documentation (perhaps 
a 0.1.0 or 1.0.0 release?) or should I keep releasing because some sad 
soul out there is using my code?

Any feedback on this would be great! Thanks,

Zach

Zach Dennis wrote:
> My quest for feedback is this....should I quit posting [ANN] or news on 
> RubyForge about small releases (like 0.0.1 and 0.0.2)? Should I instead 
> wait until I have a decent sized library and good documentation (perhaps 
> a 0.1.0 or 1.0.0 release?) or should I keep releasing because some sad 
> soul out there is using my code?
I don''t mind these occasional messages on the wxruby list, since your 
project is so closely tied to wxruby itself. And I''m always a favor of 
frequent releases when possible.

Cheers,

Kevin