Forum: wxRuby Already Initialized Constant THE_APP

Hello everyone. First time here.

I'm posting a debug question because I've searched google all over and I
can't find any other instances of this occurring. And even though it may
be a common error due to a stupid mistake by me, who is just learning
ruby and wx, for some odd reason the internet seems devoid of a
solution. I've even searched this forum and the error message is not
here either.

What happens is, the script brings up the login/create window just fine
the first time, but if the user enters too short a password and the
script tries to bring the same window up a second time for another
chance at input, the program crashes with exception "Already Initialized
Constant THE_APP". I've tried rewriting it multiple ways, even the basic
App.run do   method. Still no luck.

It seems like I'm not doing something that is needed to completely
destroy the instance of App, as the second time I call it no matter what
it always crashes with the exception.

What's funny is, I had this login/create window already done using the
TK library and since I had an old version of the library, it had a bug
in PMW which basically caused the same kind of behavior as this bug is
causing. I could only bring up one instance of anything, if another was
ever created, even after all other instances had been destroyed, the
program would crash and tell me that a constant was already initialized.
Without a way to fix it, I moved on to shoes, which I quickly dismissed
because it was WAY too hard to try and get shoes to work from within my
ruby script instead of as a script-launcher. Then I spent a good 5 hours
researching a way to make "require 'wx'" work, turns out ubuntu 10.04
needs some special installation procedures. Finally got that working,
only to find out that, yep, I can only create one instance of a window
per program run......... again....   XD

I realize that I can just handle the string check in the button code to
avoid this one occurrence. However, that won't fix the problem if I need
to be able to reopen a window later in the program. The real problem is
that later on I will be developing a lot of GUI windows for this client
that will need to be opened, then closed, then reopened, then closed,
then reopened, over and over and over again, in order for players to
build. If I can't do it with the first window, it's not worth building
all the subsequent windows or even continuing on the project until I can
find a GUI that allows me to create a second instance of a particular
window sometime after the first instance had been destroyed.

Here's the contents of obtainlogin.rb. This file is required in the main
ruby script.

I'm using Ubuntu 10.04 Lucid and Ruby 1.8

Error: "Already Initialized Constant THE_APP" upon second run of App.



class LoginFrame < Frame
  def initialize()
    super(nil, -1, 'Login Or Create')
    # First create the controls
    @my_panel = Panel.new(self)
    @userid_label = StaticText.new(@my_panel, -1, 'User ID:',
DEFAULT_POSITION, DEFAULT_SIZE, ALIGN_CENTER)
    @userid_textbox = TextCtrl.new(@my_panel, -1, '')
    @password_label = StaticText.new(@my_panel, -1, 'Password:',
DEFAULT_POSITION, DEFAULT_SIZE, ALIGN_CENTER)
    @password_textbox = TextCtrl.new(@my_panel, -1, '', :style =>
TE_PASSWORD)
    @connect_but = Button.new(@my_panel, -1, 'Connect')
    # Bind controls to functions
    evt_button(@connect_but.get_id()) { |event|
connect_but_click(event)}
    # Now do the layout
    @my_panel_sizer = BoxSizer.new(VERTICAL)
    @my_panel.set_sizer(@my_panel_sizer)
    @my_panel_sizer.add(@userid_label, 0, GROW|ALL, 2)
    @my_panel_sizer.add(@userid_textbox, 0, GROW|ALL, 2)
    @my_panel_sizer.add(@password_label, 0, GROW|ALL, 2)
    @my_panel_sizer.add(@password_textbox, 0, GROW|ALL, 2)
    @my_panel_sizer.add(@connect_but, 0, GROW|ALL, 2)
    show()
  end

  def connect_but_click(event)
    $userid = @userid_textbox.get_value
    $password = @password_textbox.get_value
    close
  end

end

class LoginApp < App
  def on_init
  LoginFrame.new
  end
end

def areThereIllegalCharactersInLoginInfo
  tBool = false
  for i in (0...$userid.length)
    if $userid[i] < 32 or $userid[i] > 126
      tBool = true
    end
  end
  for i in (0...$password.length)
    if $password[i] < 32 or $password[i] > 126
      tBool = true
    end
  end
  return tBool
end

def obtainLoginInfo
  passBool = false
  while passBool == false
    #LoginApp.new.main_loop() # This was the original line, I changed it
to try and fix the problem.
                tApp = LoginApp.new
    tApp.main_loop()
    tApp = nil # I added this line to try and fix the problem, it does
not help at all.

    passBool = true
    if $userid.length < 4 or $userid.length > 20 or $password.length < 4
or $password.length > 20
      passBool = false
      puts "Please provide a User ID and Password which are at least 4
characters long and at most 20 characters long."
    end
    if areThereIllegalCharactersInLoginInfo == true
      passBool = false
      puts "Please provide a User ID and Password which contain only
standard characters. Special characters are not permitted."
    end
  end
end

Hello Ron,

First off, welcome to wxRuby.  Your lucky I'm up this early, as I should
have been in bed an hour ago, but you know how it goes. lol

The answer to your solution, is to intercept a evt_close on your window
class, to prevent the window from being destroyed.  What is happening, 
is
when you run your script, the App instance is initialized with 
Wx::App.run
method.  And the thing is, there can only ever be one instance of 
Wx::App at
any run time of your script.  So if you exit out of the Main Loop for
Wx::App, then it's going to fail, when you try to re-initialize / 
re-create
your App / Window.  Mainly cause your trying to re-create your Window, 
after
wxWidgets has already released the App Instance.

The solution to your problem, is two fold.  First off, move your logical
handling code into your Window class.  This will ensure that your code 
is
executed, and allow wxWidgets to continue operating for you.  You should
never exit the Wx::App main loop, unless your actually exiting the 
program
itself.

Second, if you want your window to dis-appear, but the app to remain
running, you need to do two things.  One, ensure that Wx::App, doesn't 
exit
when the Main Window Instance (The first / Only instance of a Wx::Frame) 
is
destroyed.  This can be done with Wx::App#set_exit_on_frame_destroy() 
method
(Referenced 
here<http://wxruby.rubyforge.org/doc/app.html#App_setex...).
 This will ensure that if there are no other Window instances available,
that wxWidgets will not close out the app, and de-reference the main
instance of the App.

The second part, is that there are two ways to handle getting rid of a
Window.  The first, obviously being the close method, which will close 
the
window, and Destroy the reference to the Window.  Which will require you 
to
re-create a new instance of the Window.  The second method, is to simply
hide the window.  This is different from minimize, you just use the hide
method on the Frame itself, and it will make the window dis-appear, 
looking
as though it had been closed, but the Window instance will not be 
destroyed,
and you will have it available, to re-display to the end user, should 
you
need to use the window again.

I hope that this helps you understand what is going on.

L8ers,

Mario

Hey Mario, thanks for your quick reply. Incredibly informative too, now 
I have a lot of options to deal with the login screen.

I am a little confused though. I still don't see a way to have more than 
one window in the entire ruby script.

"And the thing is, there can only ever be one instance of Wx::App at any 
run time of your script."
"You should never exit the Wx::App main loop, unless your actually 
exiting the program itself."
From what you say here it almost sounds as if every ruby script can have 
only one window and no other. What if I needed to use app to show a 
login screen first, then after that a main game window, etc? I could 
still have the main script running while the main_loop is running if I 
gave the window its own thread, but that would still be the only 
allowable instance of the app in the entire program? If there can only 
ever be one occurence of app in the code, and to create two different 
windows from two different classes one would need two occurences of app 
in the code...  XD      doesn't that mean each rubyscript can only ever 
have one window?

I see how the hide method can be useful for the login screen, and I can 
certainly place the string verification code into the frame class. 
Definitely a solution for the exception on the login screen. But I still 
need to have the same ruby script create a main game window after the 
login screen is finished/hidden.

Is there perhaps a way to create a second window and show that one 
within the execution of the same main_loop? I could automate control of 
the main_loop in its own thread through global variables.

Is there any way at all to have two different windows in the same ruby 
program?

I'm thinking that if instead of requiring obtainlogin.rb I could perhaps 
execute it as a separate process from the main script, and then I could 
launch another process later for the main game window, but then global 
variables wouldn't be shared with the main script. Would have to mess 
with pipes to do that?

Also, if it's impossible to have more than one window with wxRuby, is 
there another rubygem GUI library that anyone knows about which would 
allow two different windows to be opened in the same ruby script? 
Somehow it seems like I must be missing something because I wouldn't 
expect such a large robust library to be limited to 
one-window-per-program.

Hello Ron,

On Fri, Oct 22, 2010 at 3:36 PM, Ron Shadow <lists@ruby-forum.com> 
wrote:

> Hey Mario, thanks for your quick reply. Incredibly informative too, now
> I have a lot of options to deal with the login screen.
>

Your Welcome.


> I am a little confused though. I still don't see a way to have more than
> one window in the entire ruby script.


Okay, I understand where your confusion is below, I'll just skip down 
below
all this, and explain it in better detail.


> ever be one occurence of app in the code, and to create two different
> Is there perhaps a way to create a second window and show that one
> with pipes to do that?
>
> Also, if it's impossible to have more than one window with wxRuby, is
> there another rubygem GUI library that anyone knows about which would
> allow two different windows to be opened in the same ruby script?
> Somehow it seems like I must be missing something because I wouldn't
> expect such a large robust library to be limited to
> one-window-per-program.


Alright, with all that out of the way, the first thing you will need to
realize, is that Wx::App, isn't a Window Class, and is not sub-classed 
of a
Wx::Window or Wx::Frame.  If you goto the API reference documentation,
http://wxruby.rubyforge.org/doc/app.html, and look for the Sub-Section 
of
Derived From, you'll see that Wx::App descends from Wx::EvtHandler and
Object.

I don't know what kind of programming background you have, but to look 
at
wxRuby in the fashion of a MVC (Model - View - Controller) setup, 
Wx::App
would be the Controller setup. It's your Main Entry Point into running 
your
program, and deciding where to go.  Wx::App.run, or Wx::App#on_init is 
your
Main Entry point, into your entire program, all your windows will either 
be
created from here, or be setup to be ready to be created from the rest 
of
your program.  All your initialization of library functions, and data 
stores
you need, would be done from this method.

The View Part, actually falls under the class of Wx::Frame.  There's a
common mis-conception when first dealing with wxWidgets in general, the
difference between Window, and Frame.  Mainly cause of Microsoft 
Windows,
and how their API is setup, Window means Window.  An actual window 
displayed
to the user, that has a minimize, maximize, and close button on it.

Where as with wxWidgets, what is considered a window, is actually 
considered
a Frame, with a minimize, a maximize, and a close button on it.  A 
Window in
wxWidgets is actually considered any control that can be displayed on 
the
screen.  You'll find if you go through the API Documentation, and look 
at
the sub-section Derived From, a good 90 percent of them, have the Window
class in it.  The exception to the rule, is of course Sizers, Menus,
AuiManager, etc, etc, where these are basically internal data 
structures,
that wxWidgets utilizes, to create the necessary UI Elements on Linux,
Windows, and Mac OS X.

Each Platform, and basically each GUI Toolkit has different methods in 
which
to handle the above cases of items, or may not have them at all (As with
Sizers aren't native to Windows, but is available on Linux with GTK and 
on
OS X with NSView, and with Menus, Windows and Linux with GTK have Menu
Items, where as OS X has Data Entries to Represent Menu Items.)  So, 
let's
say with your Example, your wanting to do a Development of a Game, where 
you
have a Login, and a Main Display Window, where the Login is a User 
Prompt to
ask for Login information to get into the game, and the Main Display 
Window,
is where all actual game play occurs.  I'll give you a very basic design 
to
show you how it works, and explain it further with comments.

I'm writing the code as I go, so it may not be 100 percent correct, but 
you
should be able to run the code, without any problems.

-- CODE BEGINS HERE --
#!/usr/bin/env ruby

# Here we are loading wxRuby by any possible means, either by a system
# install, or by a Ruby Gems install.  If we can't find a system 
install,
then we
# will try to load through RubyGems, if available, and if that fails, 
we'll
just
# return the original error, saying that we can't load wxRuby, as it's
probably not
# installed.
begin
  require 'wx'
rescue e => LoadError
  begin
    require 'rubygems'
    require 'wx'
  rescue LoadError
    raise e
  end
end

# This is the window that will be the Main Display Window
class GameWindow < Wx::Frame
  def initialize
    # The parent of this window is desktop, so nil is used
    # We don't need a specific ID for this window, so -1 is used
    # Our Title for our new Window is "Game Window"
    super(nil,-1,"Game Window")
    # Here we create all of our stuff needed to play the game,
    # such as UI Elements, and stuff that needs to be displayed in
    # The game Window.  No other window controls are created here.
    @te =
Wx::TextCtrl.new(self,-1,:pos=>[0,0],:size=>[200,20],:style=>Wx::TE_RICH2|Wx::TE_AUTO_URL|Wx::TE_PROCESS_ENTER)
    # After we create our controls, we setup our event handlers, for
gathering events.
    evt_text_enter @te, :input_handle_enter
  end

  # This is where we define our Logical methods, to handle game
  def input_handle_enter
    Wx::MessageDialog.new(self,"You entered: #{@te.get_value}","User 
Input",
        Wx::OK)
  end
end

# Now we setup our Login Window, which will be displayed first, then 
will
pass off to
# the Main Display Window to continue running.
class LoginWindow < Wx::Frame
  def initialize
    super(nil,-1,"Login")
    table = Wx::GridSizer.new(3,2,0,0)
    table.add(Wx::StaticText.new(self,-1,"Username:"),0,Wx::ALIGN_LEFT)
    table.add(@user = Wx::TextCtrl.new(self,-1,""),1,Wx::EXPAND|Wx::ALL)
    table.add(Wx::StaticText.new(self,-1,"Password:"),0,Wx::ALIGN_LEFT)
    table.add(@pass =
Wx::TextCtrl.new(self,-1,"",:style=>Wx::TE_PASSWORD),1,WX::EXPAND|Wx::ALL)
    table.add_spacer
    table.add(@login = Wx::Button.new(self,-1,"Login
>"),1,Wx::EXPAND|Wx::ALL)
    self.set_sizer(table)

    evt_button @login, :on_login_push
  end

  def on_login_push
    uname = @user.get_value
    upass = @pass.get_value
    unless uname.empty? AND upass.empty?
      # Attempt to login here, and process success or failure.
      if success
        gw = GameWindow.new
        gw.show
        self.hide
      end
  end
end

class MyGameApp < Wx::App
  def on_init
    lw = LoginWindow.new
    lw.show
  end
end

MyGameApp.new.main_loop
-- CODE ENDS HERE --

As you can see, I create the Login Window, which handles the login 
process,
and if it's successful, then will create the game window, and hide 
itself.
 The App is still running, and never exits, and your windows will 
continue
to display, and run, and you won't get any Pesky THE_APP already 
initialized
segfaults.  Now, keep in mind, if you want to call methods on your App
class, you can simply use the method Wx::get_app(), or you can use
Wx::THE_APP to get the instance of your main App, and execute the method 
on
it.  Though, it's strongly suggested that you don't put game loops and 
such
that require access to your Game Window, in your App, as your crossing
between objects, and the self reference changes between Objects, when 
you
get to that point.

EG: Calling a Method on your App class, means self refers to the 
instance of
the App class itself, where as calling a method on your Window class, 
means
self refers to the instance of the Window class.  And by that, instance
variables will be different between the two, or non-existent between the
two.

I hope this makes things clearer.

Mario

Yes, that is much clearer. Thanks for taking the time to write the code 
and show me.

I realize I probably seem like a Ruby noob. I've been learning Ruby for 
almost two weeks and so far I love it. I've coded games in VB6 and 
PHP/MySQL and Flash Actionscript, and I've coded other kinds of programs 
in C++. Ruby is definitely different but I can see a lot of good 
qualities from different languages packed together into Ruby.

I found Rubygame library and it looks great for the graphical combat 
screen, but has absolutely no utilities like buttons/textboxes/etc, so 
it's great that Wx can still be used.

I also see what you mean by having to put all the code of the client 
into the Wx classes. I'd prefer if possible to leave things like the 
connection protocol, socket communication, macro key functions, sound 
effect calls, etc, outside of the frame classes and the main_loop.

If I wanted to keep handling connection events from the main script 
while the main_loop was executing, I could use a separate thread for the 
main_loop, but would there be a way to hide/show a frame from a thread 
outside the main_loop? Like 'def methodX; self.hide; end' in one of the 
frame classes, and '$loginFrame.methodX' from outside the main_loop 
thread? Or $loginFrame.hide?

I know I can call methods defined by the main-thread from spawned-thread 
blocks so it ought to work the same way in reverse if I use global 
variables for all the frame instances?

Hello again Ron,

On Sun, Oct 24, 2010 at 2:28 AM, Ron Shadow <lists@ruby-forum.com> 
wrote:

> Yes, that is much clearer. Thanks for taking the time to write the code
> and show me.
>

Not a problem, and I'm glad that you can finally understand where this 
is.


> I realize I probably seem like a Ruby noob. I've been learning Ruby for
> almost two weeks and so far I love it. I've coded games in VB6 and
> PHP/MySQL and Flash Actionscript, and I've coded other kinds of programs
> in C++. Ruby is definitely different but I can see a lot of good
> qualities from different languages packed together into Ruby.
>

Ruby is Unique in the fact that it's pure Object Oriented, and 
therefore,
fits many encapsulations of elements within a program.


> I found Rubygame library and it looks great for the graphical combat
> screen, but has absolutely no utilities like buttons/textboxes/etc, so
> it's great that Wx can still be used.
>

...


> I also see what you mean by having to put all the code of the client
> into the Wx classes. I'd prefer if possible to leave things like the
> connection protocol, socket communication, macro key functions, sound
> effect calls, etc, outside of the frame classes and the main_loop.
>

I understand, I'll get a bit more indepth here in a moment....


> If I wanted to keep handling connection events from the main script
> while the main_loop was executing, I could use a separate thread for the
> main_loop, but would there be a way to hide/show a frame from a thread
> outside the main_loop? Like 'def methodX; self.hide; end' in one of the
> frame classes, and '$loginFrame.methodX' from outside the main_loop
> thread? Or $loginFrame.hide?
>
> I know I can call methods defined by the main-thread from spawned-thread
> blocks so it ought to work the same way in reverse if I use global
> variables for all the frame instances?


Threads are a tricky business, especially when you get into Multiple
Threads, and that you also need to realize something else.  Depending 
upon
what version of the Ruby Interpreter your using, you have to deal with
another layer of trouble.  In Ruby 1.8, it is designed at the core, to 
use
Green Threads.  Which basically means, that a Thread is created 
internally
in the Interpreter that is basically an Emulated Thread, but not a true
native thread.  This basically means that Ruby is handling all the
scheduling and such for each of the threads, instead of the OS itself. 
Ruby
1.9 on the other hand, actually implements Native threads, where the OS 
is
handling the Threads itself, and not Ruby.

What this means to you, is that if you were to use Ruby 1.8 Threads, and 
you
have something like wxWidget's main_loop running, 99.9999 percent of the
time will be spent on main_loop, giving ruby extremely little chance to 
run
any other threads.  If at all.  Where as Ruby 1.9, it handles Threads
natively, which allows main_loop to run in it's own native thread, and
allows you to create other threads, in which to actually
run simultaneously as the Main Thread.

Which brings me to Thread Safety.  The main thing you want to be careful
about with dealing with Threads, is using them safely.  Thread Safety
basically entails using a Mutex, or Semaphore to get a global lock 
within
your program, and allow a certain thread to have exclusive access to the
variable data, including updating it with new information, while 
preventing
other threads from having access for the time that your updating the 
data.
If all your doing is Reading Variables, and not assigning to them from
another thread, then you should be fine.  But if your assigning data 
from
other threads, then you need to create a Mutex, lock it for the period 
that
your updating the data, then unlock it when your finished.  If you 
don't,
then you could get those nice little fatal errors, about access 
violation of
memory addresses.  I'm sure with your C++ background, you probably have 
a
good idea what I mean by this.

Lastly, another thing you will need to be careful of, is the whole usage 
of
two different libraries, that utilize a tight end Main Loop.  RubyGame
utilizies a tight end Main Loop to allow processing of drawing, events, 
and
so on, while wxWidgets also has it's own tight end Main Loop, to handle 
the
same things.  Attempting to use these two in conjunction, requires a bit 
of
advanced programming to get to work properly.  Not to say that it can't 
be
done, it can, but it will be hard to do, as you will need to write a 
sort of
merged main loop, that will handle wxRuby events, and handle RubyGame 
events
at the same exact time, to keep both libraries running smoothly, as if 
they
were separate.

Thankfully, wxRuby allows you to write your own main_loop function, if 
you
were to sub-class Wx::App.  and using Wx::App#pending to see if there 
are
any wxWidgets events pending, and if there are, using Wx::App#dispatch 
to
dispatch events to be executed.  Using this in concert with RubyGame, or 
any
other library's own way of processing their own events, may help you 
utilize
what you want to keep things running smoothly.


I do hope that this helps you out, and progresses you further in 
developing
your application / game.

L8ers,

Mario

Mario Steele wrote in post #957323:

I bit the bullet and just went with the flow, coded the app to 
load/show/hide from within the main_loop. I have a login screen, main 
screen, and a player creation screen. Although I can't help but 
load/show the player creation and main screens from the socket thread 
that is outside the main_loop. Even though it's calling a method from a 
frame class it's still calling from outside main_loop, etc. It works 10% 
of the time, but 90% of the time I get a segmentation fault when trying 
to show the player creation screen (the .show() method). Isolated it 
down to that line by using puts before and after it.

I've searched these forums and found some tips, tried some of them but 
they haven't helped yet. I don't need to boost GC speed because I am 
getting the fault in the same place all the time, it's just that 10% of 
the time it does not occur and the creation screen shows and behaves 
normally. I tried GC.disable in my script but that didn't solve the 
problem, so I don't think it's caused by garbage collection.

> Green Threads.  Which basically means, that a Thread is created
> internally
> in the Interpreter that is basically an Emulated Thread, but not a true
> native thread.  This basically means that Ruby is handling all the
> scheduling and such for each of the threads, instead of the OS itself.
> Ruby
> 1.9 on the other hand, actually implements Native threads, where the OS
> is
> handling the Threads itself, and not Ruby.

> What this means to you, is that if you were to use Ruby 1.8 Threads, and
> you
> have something like wxWidget's main_loop running, 99.9999 percent of the
> time will be spent on main_loop, giving ruby extremely little chance to
> run
> any other threads.  If at all.

This answers a big question of mine. The client stops communicating with 
the server when the GUI is shown, until I start moving the mouse. The 
client only continues to process the socket thread if I continue to move 
the mouse. So if I run it on ruby1.9.1 that'll take care of that 
problem?

Turns out I can't uninstall ruby1.8 without removing ruby completely. 
Ruby doesn't run if I have only 1.9.1 installed, oddly enough. So should 
I just leave ruby1.8 installed and install ruby1.9.1? Will that mean any 
script I run will automatically use ruby1.9.1? RVM seems to be way too 
complicated, not sure if I want to use RVM.   XD

> If all your doing is Reading Variables, and not assigning to them from
> another thread, then you should be fine.  But if your assigning data
> from
> other threads, then you need to create a Mutex, lock it for the period
> that
> your updating the data, then unlock it when your finished.  If you
> don't,
> then you could get those nice little fatal errors, about access
> violation of
> memory addresses.  I'm sure with your C++ background, you probably have
> a
> good idea what I mean by this.

I will definitely need to be modifying the properties of the class 
instances that are initiated within the main_loop, from outside the 
main_loop in the socket thread. So it sounds like I'll have to be using 
locks. Thanks for telling me about that, probably would have taken me a 
while to find that.

Also - this is probably what is causing the segmentation faults? The 
fact that I don't have synchronized blocks / mutex locks?

> Thankfully, wxRuby allows you to write your own main_loop function, if
> you
> were to sub-class Wx::App.  and using Wx::App#pending to see if there
> are
> any wxWidgets events pending, and if there are, using Wx::App#dispatch
> to
> dispatch events to be executed.  Using this in concert with RubyGame, or
> any
> other library's own way of processing their own events, may help you
> utilize
> what you want to keep things running smoothly.

What if I don't need to execute any code in the wx main_loop while the 
Rubygame main_loop is running? I can handle the combat mode using only 
Rubygame.

Does that mean that, instead of rewriting the main_loop, I could just 
execute the Rubygame main_loop from inside of the wx main_loop? I could 
tell the wx main_loop to sleep while the Rubygame main_loop is 
executing, just to make sure it waits for combat to end.

> I do hope that this helps you out, and progresses you further in
> developing
> your application / game.
>
> L8ers,
>
> Mario

Yeah, you've been incredibly helpful. I don't think I would have got 
WxWidgets to show multiple windows without your explanation on the 
main_loop etc. Thanks! :)

require 'thread'
$mutex = Mutex.new

...

# this method is in class MainScreenFrame < Wx::Frame
def showPlayerCreationScreen
# this method ends up getting called from the socket thread.
$mutex.synchronize {
$theCreationScreen = PlayerCreationFrame.new()
$theCreationScreen.show # segmentation fault occurs on this line
# 10% of the time there will be no segmentation fault and the screen 
will show/behave fine.
}
end


I've placed puts at the end of the def initialize method in the 
PlayerCreationFrame class, and the puts always gets shown before the 
segmentation fault occurs, so it's not occurring with initialization of 
PlayerCreationFrame (unless it occurs as the initialization method 
ends?).

GC.disable has no effect.

I am currently in the wxRuby chat room, if you wish to talk with me in
person, and I can answer some of these questions for you.

Mario Steele wrote in post #957691:
> I am currently in the wxRuby chat room, if you wish to talk with me in
> person, and I can answer some of these questions for you.

Awesome, will drop on by. That's an IRC chatroom on freenode, right? 
#wxruby? Or do you mean another kind of chat room?

For those of you who don't have an IRC Client, and would like to use a 
Web
Page chat system, you can use the following:
http://webchat.freenode.net/?channels=wxruby  FreeNode no longer allows
Mibbit to work, so this will allow you to get into the wxRuby channel
without needing to install an IRC Client, or figuring out which room to 
go
to. ;-)