XP and Windows 7 -- def() inside App#run block problem

Desktop wxRuby
1

(slightly edited) When I run the following code, I expect a blank frame
to open (which is
what happens when the def block is left out of the code). Instead, the
program exits immediately.

ruby 1.9.2p290 (2011-07-09) [i386-mingw32]
wxruby 2.0.1
OS: Microsoft Windows XP Professional 5.1.2600

#!/usr/bin/ruby -w

require “wx”

Wx::App.run do
Wx::Frame.new(nil).show

def cause_of_problem
puts “This prevents the window from staying open, even though it is
never run”
end

end

A perhaps related issue involves errors such as uninitialized variable
accesses inside of event handlers in Windows 7 – I get no error
message; instead, the application just stops responding, which makes
debugging impractical.

Has anyone else seen similar problems, and is wxruby debugging more
robust under Linux?

Thanks,
Eric

2

hi

On 12/10/11 17:42, Eric B. wrote:

require “wx”

Wx::App.run do
Wx::Frame.new(nil).show

def cause_of_problem
puts “This prevents the window from staying open, even though it is
never run”
end

end

You need to return a true value from App.run block to signal that the
app set up successfully and the GUI loop should begin.

The return value of the ‘def’ is ‘nil’, which evaluates to false. Adding
any true value after the def block will fix this.

A perhaps related issue involves errors such as uninitialized variable
accesses inside of event loops in Windows 7 – I get no error message
(even with $stdout.sync = true); instead, the application just stops
responding, which makes debugging impractical.

Has anyone else seen similar problems, and is wxruby debugging more
robust under Linux?

I’m afraid I haven’t used wxRuby on Windows 7, but on all the platforms
I’ve used (Windows XP, Linux, OS X) I’d expect this kind of normal Ruby
error to throw an exception and abort.

alex

3

It’s true that crashes in native code under Linux are much more helpful

you get a backtrace into the native code. Under Windows in the past I’ve
recompiled wxWidgets and wxRuby with debugging information, then have
run
ruby through the Visual Studio debugger to get this information, which
is a
pain. Maybe it would be possible to use Structured Exception Handling
under
Windows to catch exceptions such as null pointer accesses in wxruby code
and
provide more helpful information.

David