Xml.load_panel

Hello,
I cannot correctly load panel from xrc-file. My test programm is below.
Problem is that panel content is drawn not in place of ‘DYMMYPANEL’, but
in upper-left corner. Please, help me to find mistake.

#!/usr/bin/ruby -w
require ‘wx’
$ui_dir = File.dirname(FILE)
class MainFrame < Wx::Frame
def initialize(parent = nil)
super
xrc_file = File.join $ui_dir,‘test.xrc’
xml = Wx::XmlResource.get
xml.flags = Wx::XRC_NO_SUBCLASSING | Wx::XRC_NO_RELOADING
xml.init_all_handlers
xml.load xrc_file
xml.load_frame_subclass(self,parent,‘MAINFRAME’)
@finder = lambda do |x|
id = Wx::xrcid(x)
Wx::Window.find_window_by_id(id,self)
end
@splitter = @finder.call ‘SPLITTER’
@dummy_panel = @finder.call ‘DUMMYPANEL’
@new_panel = xml.load_panel self,‘PANEL’
@splitter.replace_window @dummy_panel, @new_panel
end
end
Wx::App.run do
MainFrame.new.show
end

Hi

Max S. wrote:

super
@splitter = @finder.call 'SPLITTER'
@dummy_panel = @finder.call 'DUMMYPANEL'
@new_panel = xml.load_panel self,'PANEL'

You’re loading the new panel as a child of ‘self’ - the Frame, when it
should be a child of @splitter I think?

@splitter.replace_window @dummy_panel, @new_panel

In my experience you probably want to follow this with

@dummy_panel.destroy

Otherwise you will be left with the old panel hanging around

hth
alex

Alex F. wrote:

Hi

You’re loading the new panel as a child of ‘self’ - the Frame, when it
should be a child of @splitter I think?

@splitter.replace_window @dummy_panel, @new_panel

In my experience you probably want to follow this with

@dummy_panel.destroy

Otherwise you will be left with the old panel hanging around

hth
alex

Hi,
Thanks for reply.
Sorry for wrong topic subject
In such case

@new_panel = xml.load_panel @splitter,‘PANEL’
@splitter.replace_window @dummy_panel, @new_panel
@dummy_panel.destroy

‘PANEL’ content(one static text) is rendered in upper-left corner of
splitter (left pane), while it supposed to be on the right

Max

Alex F. wrote:

Hard to say without seeing actual code. With any query like this, a
minimal and runnable sample that demonstrates the issue is best.

At a guess, you may need a Sizer within your Panel to ensure that the
child text is placed in the right place.

alex

Complete project (rb-script, wxFormBuilder project, generated xrc and
screenshot) are attached to post.

‘GC.disable’ is present to avoid random crashes described in
http://www.ruby-forum.com/topic/142975

OS Windows XP SP2
ruby 1.8.7 (2008-05-31 patchlevel 0) [i386-mswin32]
wxRuby 1.9.7 installed from gem

Max

Max S. wrote:

Complete project (rb-script, wxFormBuilder project, generated xrc and
screenshot) are attached to post.

I don’t think this is very hard to fix - you currently have an
intermediate panel as the right-hand-side child of your upper splitter
window. I made your DUMMYPANEL the direct second child of the splitter
window and then it all works fine. You were attaching your replacement
window in the wrong place.

Generally a garbled layout with an element in the top left means that
something is being attached to thr wrong parent, or added to the wrong
sizer, or missing a sizer.add call. I’ve made this mistake a lot of
times doing wxRuby programming (including earlier today…) and they’re
always fixed by looking closely at the window hierarchy.

‘GC.disable’ is present to avoid random crashes described in
http://www.ruby-forum.com/topic/142975

OK, this should be fixed with the upcoming 1.9.8 release. Sorry for the
inconvenience.

OS Windows XP SP2
ruby 1.8.7 (2008-05-31 patchlevel 0) [i386-mswin32]
wxRuby 1.9.7 installed from gem

a

Thank You very mush for help.

Max S. wrote:

Thanks for reply.
Sorry for wrong topic subject
In such case

@new_panel = xml.load_panel @splitter,‘PANEL’
@splitter.replace_window @dummy_panel, @new_panel
@dummy_panel.destroy

‘PANEL’ content(one static text) is rendered in upper-left corner of
splitter (left pane), while it supposed to be on the right
Hard to say without seeing actual code. With any query like this, a
minimal and runnable sample that demonstrates the issue is best.

At a guess, you may need a Sizer within your Panel to ensure that the
child text is placed in the right place.

alex

Alex F. wrote:

Max S. wrote:

If I load panel directly from xrc-file, everything is ok, but if I
create a class

class NewPanel < Wx::Panel
def initialize parent = nil
super

Here, you must call super() - with no arguments. Whenever you’re loading
an XRC layout into a Frame/Panel/Dialog subclass you must call the
default initialize with no arguments, then call load_xxx_subclass with
the usual arguments.

$xml.load_panel_subclass(self,parent,'PANEL')

end
end

cheers
aelx

Hm, ‘super()’ call raises error in NewPanel#initalize, while in
MainFrame#initialize it works perfectly.

c:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.7-i386-mswin32/lib/wx/keyword_ctors.rb:180:in
pre_wx_kwctor_init': wrong # of arguments(0 for 1) (ArgumentError) from c:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.7-i386-mswin32/lib/wx/keyword_ctors.rb:180:ininitialize’
from ./newpanel.rb:3:in initialize' from test.rb:21:innew’
from test.rb:21:in initialize' from test.rb:35:innew’
from test.rb:35:in on_init' from c:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.7-i386-mswin32/lib/wx/classes/app.rb:16:inmain_loop’
from
c:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.7-i386-mswin32/lib/wx/classes/app.rb:16:in
`run’
from test.rb:29

And one more question regarding events. What happens to events,
assosiated to destroyed objects?

my_button = Wx::Button.new self
evt_button my_button, :my_button_click
my_button.destroy

Is this code ok, or I have to disconnect event first?

my_button = Wx::Button.new self
evt_button my_button, :my_button_click
disconnect my_button, Wx::ID_ANY, :evt_button
my_button.destroy

Max

Hi, Time passes and new questions arise :slight_smile:

If I load panel directly from xrc-file, everything is ok, but if I
create a class

class NewPanel < Wx::Panel
def initialize parent = nil
super
$xml.load_panel_subclass(self,parent,‘PANEL’)
end
end

and load it using

@new_panel = NewPanel.new @splitter

panel content is not shown correctly, it appears only after resizing
panel. self.refresh doesn’t help. What can be done? Complete project is
attached to post.

Max

Hello Max,

On Wed, Aug 27, 2008 at 1:07 AM, Max S. [email protected] wrote:

evt_button my_button, :my_button_click
disconnect my_button, Wx::ID_ANY, :evt_button
my_button.destroy

This part, you don’t have to worry about disconnecting any events, as
wxRuby
automatically disconnects any associated events from the object, before
destruction. Your first example, would work just fine.

Max S. wrote:

Hm, ‘super()’ call raises error in NewPanel#initalize, while in
MainFrame#initialize it works perfectly.

c:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.7-i386-mswin32/lib/wx/keyword_ctors.rb:180:in
pre_wx_kwctor_init': wrong # of arguments(0 for 1) (ArgumentError) from c:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.7-i386-mswin32/lib/wx/keyword_ctors.rb:180:ininitialize’

Hmm, I get the same error with 1.9.7. I had originally tried with the
current SVN version, which works fine, although I’m not quite sure
what’s changed. Perhaps someone with the latest development version
could confirm that this is fixed there?

And one more question regarding events. What happens to events,
assosiated to destroyed objects?
As Mario says, wxRuby, and wxWidgets deal with this internally.

alex

Alex, Mario, thank You for explanations.

Max

Max S. wrote:

If I load panel directly from xrc-file, everything is ok, but if I
create a class

class NewPanel < Wx::Panel
def initialize parent = nil
super

Here, you must call super() - with no arguments. Whenever you’re loading
an XRC layout into a Frame/Panel/Dialog subclass you must call the
default initialize with no arguments, then call load_xxx_subclass with
the usual arguments.

$xml.load_panel_subclass(self,parent,'PANEL')

end
end

cheers
aelx

Max S. wrote:

Alex F. wrote:

Hmm, I get the same error with 1.9.7. I had originally tried with the
current SVN version, which works fine, although I’m not quite sure
what’s changed.
On going through the ChangeLog, I see this was in fact specifically
fixed for version 1.9.8

Have a look at the code of your XRCPanel. It takes a single-argument,
parent, but it calls Wx::Panel.new() with no arguments, which is the way
it’s done for loading from XRC. So you need to call new in XRCPanel with
a correct parent argument; it will deal with the rest.

puts don’t get executed and panel content is not updated at all

and is not visible

class NewPanel < XRCPanel
def initialize parent = nil
super()
puts ‘Hello, World!’
end
end

Here you’re telling the Panel it should be attached to +nil+ so it won’t
display properly, or might even crash.

#Works fine but ‘on_init’ is optional
class NewPanel < XRCPanel
def on_init
puts “Hello, World!”
end
end

This is deprecated and will be dropped from future versions of XRCise -
its use is discouraged.

alex

Alex F. wrote:

Max S. wrote:

Hm, ‘super()’ call raises error in NewPanel#initalize, while in
MainFrame#initialize it works perfectly.

c:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.7-i386-mswin32/lib/wx/keyword_ctors.rb:180:in
pre_wx_kwctor_init': wrong # of arguments(0 for 1) (ArgumentError) from c:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.7-i386-mswin32/lib/wx/keyword_ctors.rb:180:ininitialize’

Hmm, I get the same error with 1.9.7. I had originally tried with the
current SVN version, which works fine, although I’m not quite sure
what’s changed. Perhaps someone with the latest development version
could confirm that this is fixed there?

alex

Hello,

I don’t know my new problem is the same, but now I have the following
XRCPanel is generated from xrc-file by xrcise

#Works fine
class NewPanel < XRCPanel
def initialize parent = nil
super
end
end

puts don’t get executed and panel content is not updated at all

and is not visible

class NewPanel < XRCPanel
def initialize parent = nil
super()
puts ‘Hello, World!’
end
end

#Works fine but ‘on_init’ is optional
class NewPanel < XRCPanel
def on_init
puts “Hello, World!”
end
end

So, please, what is the correct method?

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs