# Already Initialized Constant THE\_APP

**URL:** <https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092>\
**Category:** wxRuby\
**Created:** [October 22, 2010, 11:16am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092 "2010-10-22T11:16:58Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 22, 2010, 11:16am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/1 "2010-10-22T11:16:58Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 22, 2010, 4:10pm UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/2 "2010-10-22T16:10:35Z")

</div>

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\_setexitonframedelete](http://wxruby.rubyforge.org/doc/app.html#App_setexitonframedelete)).  
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

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 22, 2010, 9:36pm UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/3 "2010-10-22T21:36:45Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 24, 2010, 8:28am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/4 "2010-10-24T08:28:36Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 23, 2010, 9:49am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/5 "2010-10-23T09:49:50Z")

</div>

Hello Ron,

On Fri, Oct 22, 2010 at 3:36 PM, Ron S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
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](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

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 28, 2010, 7:27am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/6 "2010-10-28T07:27:25Z")

</div>

Mario S. 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! 🙂

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 26, 2010, 10:27pm UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/7 "2010-10-26T22:27:20Z")

</div>

Hello again Ron,

On Sun, Oct 24, 2010 at 2:28 AM, Ron S. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
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

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 28, 2010, 8:43am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/8 "2010-10-28T08:43:20Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 28, 2010, 7:36am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/9 "2010-10-28T07:36:15Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 28, 2010, 9:05am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/10 "2010-10-28T09:05:11Z")

</div>

Mario S. 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?

---

<div class="post-metadata">

**Author:** ![ronaks](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/cdc98d/32.png) [@ronaks](https://www.ruby-forum.com/u/ronaks)\
**Post date:** [October 28, 2010, 9:11am UTC](https://www.ruby-forum.com/t/already-initialized-constant-the-app/226092/11 "2010-10-28T09:11:39Z")

</div>

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:  
[Kiwi IRC](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. 😉