Problem with Gauge on windows xp

I am new to wxRuby and just built a simple app with a frame containing a
static text control and two gauges … I used DialogBlocks to design the
ui, and wx_sugar to generate a base class via xrcise, etc… All of this
works peachy on my development box (Mac OSX ~ Leopard) with the latest
gems…

However, I tried running this little app on my Windows XP box and got
the following exception:

./stream_downloader_gui.rb:25:in find_window_by_id': Error wrapping object; cla sswxGauge95’ is not supported in wxRuby (NotImplementedError)
from ./stream_downloader_gui.rb:25:in initialize' from ./stream_downloader_gui.rb:34:incall’
from ./stream_downloader_gui.rb:34:in initialize' from E:/stream_downloader/stream_downloader.rb:25:ininitialize’
from E:/stream_downloader/stream_downloader.rb:58:in new' from E:/stream_downloader/stream_downloader.rb:58:ininitialize’
from E:/stream_downloader/stream_downloader.rb:191:in new' from E:/stream_downloader/stream_downloader.rb:191:inon_init’
from E:/stream_downloader/stream_downloader.rb:201:in
`main_loop’
from E:/stream_downloader/stream_downloader.rb:201

I figure this has something to do with the gem trying to instantiate a
Gauge95 instead of a GaugeMSW or a Gauge, but I see nothing in the docs
that suggests a solution… Any ideas?

Thanks much,
Tim

Hello Tim,

Yes, you are correct in your assumption, that wxRuby is trying to
initialize
wxGuage95, and not finding it. Dialog Blocks has a bad habbit of trying
to
create a unique Class for C++ Code Generation, in which it creates a
Sub-Class of the main class. What you would want to do, is edit your
xml
file, and change Guage95 into just Guage. This will allow wxRuby to
correctly interpret the class you are actually trying to create.

I have found, that Dialog Blocks is a bit of an encumberance when
dealing
with creating GUI’s for wxRuby myself. Others have had excellent
success,
so it’s all in your point of view. I would suggest checking out
wxFormBuilder as an alternative to Dialog Blocks. The website is:

I find I have a lot more success with this RAD Tool, then any other I
have
ran into. Let me know if you try it out, and what you think of it, same
with your problem to.

L8ers,

Mario S.

Mario S. wrote:

Hello Tim,

Hey Mario…

Yes, you are correct in your assumption, that wxRuby is trying to
initialize
wxGuage95, and not finding it. Dialog Blocks has a bad habbit of trying
to
create a unique Class for C++ Code Generation, in which it creates a
Sub-Class of the main class. What you would want to do, is edit your
xml
file, and change Guage95 into just Guage. This will allow wxRuby to
correctly interpret the class you are actually trying to create.

That thought did occur to me and I looked into it… Here is the
relevant snippet from the xrc:

current file progress wxGA_HORIZONTAL 0 100

and I saw no direct reference to Gauge95… At this point I wondering if
it is just a problem with the way the wxWidgets part of the binary gem
was compiled… I may try stepping back to the 1.9.3 gem and see how
things behave, or maybe just try building it myself…

Thanks for the tip about wxFormBuilder … I’ll look into that as well.
:slight_smile:

Cheers,
Tim

Tim F. wrote:

object; cla
ss `wxGauge95’ is not supported in wxRuby (NotImplementedError)

Could you post the XRC for this dialog please? It could be a problem
with the XRC that DialogBlocks is generating, or with the way that’s
interpreted by wxRuby or wxWidgets.

Thanks
alex

Well, figuring that this had something to do with loading from an xrc, I
redid my code to just create the dialog by hand… I get a dialog now,
without error, but something seems messed up with event handling… I
cannot move or close the dialog, the Cancel button does not paint… the
gauges work though :-p

Again, this all works fine for me on my Mac - I only see this weirdness
on Windows (XP) … I’m sure it is some detail I am overlooking or,
being so new to this, something I am misinterpreting…

Attached is my code in hopes that someone will spot something… (this
is just a small app to parse an m3u playlist and download the mp3s found
there)

---- here be code ------

#!/usr/bin/env ruby

stdlib

require ‘fileutils’
require ‘open-uri’
require ‘tmpdir’

gems

require ‘rubygems’
require ‘wx’

StreamDownloaderProgress class

progress dialog for the downloads…

class StreamDownloaderProgress < Wx::Frame
attr_accessor :status_label, :progress_item, :progress_all,
:cancel_button
attr_accessor :cancelled
def initialize
super(nil, -1, StreamDownloader::TITLE, Wx::DEFAULT_POSITION,
Wx::Size.new(350, 120),
Wx::MINIMIZE_BOX | Wx::SYSTEM_MENU | Wx::CAPTION |
Wx::CLOSE_BOX)
sizer = Wx::BoxSizer.new(Wx::VERTICAL)

# label
@status_label = Wx::StaticText.new(self, -1, "Preparing downloads... 

please wait.",
Wx::DEFAULT_POSITION,
Wx::DEFAULT_SIZE)
sizer.add(@status_label, 1, Wx::GROW | Wx::ALL | Wx::ALIGN_LEFT |
Wx::FIXED_MINSIZE, 2)

# item progress
@progress_item = Wx::Gauge.new(self, -1, 100,
                               Wx::DEFAULT_POSITION,
                               Wx::DEFAULT_SIZE,
                               Wx::GA_HORIZONTAL)
@progress_item.set_tool_tip("current item progress")
@progress_item.value = 0
sizer.add(@progress_item, 1, Wx::GROW | Wx::HORIZONTAL, 2)

# all progress
@progress_all = Wx::Gauge.new(self, -1, 100,
                               Wx::DEFAULT_POSITION,
                               Wx::DEFAULT_SIZE,
                               Wx::GA_HORIZONTAL)
@progress_all.set_tool_tip("overall progress")
@progress_all.value = 0
sizer.add(@progress_all, 1, Wx::GROW | Wx::HORIZONTAL, 2)

# cancel button
@cancel_button = Wx::Button.new(self, -1, 'Cancel', 

Wx::DEFAULT_POSITION, Wx::DEFAULT_SIZE)
@cancel_button.set_tool_tip(“cancel downloads”)
sizer.add(@cancel_button, 1, Wx::ALIGN_CENTER_HORIZONTAL, 2)

self.set_sizer(sizer)

# on close simply set var to show intention
evt_close { |e| @cancelled = true }
evt_button(@cancel_button) { |e| @cancelled = true }
# set up location/controls
self.center(Wx::BOTH)
self.layout

end
end

StreamDownloader class

main class where all the work is donw

class StreamDownloader
attr_accessor :destdir
attr_reader :urls
attr :m3ufile
attr :dialog

NAME = ‘Stream Downloader’
VERSION = ‘1.0.0’
TITLE = “#{NAME} #{VERSION}”

def initialize
# init our progress dialog
@dialog = StreamDownloaderProgress.new
Wx::get_app.yield
# set up our destdir based on platform
if RUBY_PLATFORM =~ /mswin32/
@destdir = File.join(“C:/Documents and Settings”, ENV[‘USERNAME’],
‘Desktop’)
elsif RUBY_PLATFORM =~ /darwin/
@destdir = File.join(ENV[‘HOME’], ‘Desktop’)
else
@destdir = File.expand_path(File.dirname(FILE))
end
end

def ask
fd = Wx::FileDialog.new(@dialog, ‘Select the playlist to
process…’,
@destdir, “”, “Playlist files
(.m3u)|.m3u”,
Wx::FD_OPEN | Wx::FD_FILE_MUST_EXIST,
Wx::DEFAULT_POSITION )
if fd.show_modal == Wx::ID_OK
return(fd.get_path)
else
exit
end
end

def file=(m3u)
# ok … assign and parse
@m3ufile = m3u
@urls = parse if @m3ufile
end

def file
return @m3ufile
end

def parse(file = @m3ufile)
found = []
if File.exist?(file)
File.open(file) { |f|
while line = f.gets
found.push(line.chomp) if line =~ /.mp3$/i
end
}
end
return found
end

def grab
progress = 0
if @urls.size > 0
@dialog.show
Wx::get_app.yield
@urls.each_index { |idx|
url = @urls[idx]
fname = File.basename(url)
@dialog.status_label.label = “Downloading #{idx + 1} of
#{@urls.size}: #{fname}”
@dialog.progress_all.value = (100 * (idx/@urls.size.to_f)).to_i
begin
size = 0
@dialog.progress_item.value = 0 # reset
File.open(File.join(Dir::tmpdir, fname), ‘wb’) { |ofile|
open(url,
:content_length_proc => lambda {|total| size = total },
:progress_proc => lambda { |current|
@dialog.progress_item.value = (100 *
(current/size.to_f)).to_i if size > 0
Wx::get_app.yield # update gui…
raise “operation cancelled by user” if
@dialog.cancelled
}
) { |urlreader|
urlreader.binmode
ofile.write(urlreader.read)
}
}
rename(File.join(Dir::tmpdir, fname))
rescue => err
@dialog.hide
unless @dialog.cancelled
md = Wx::MessageDialog.new(@dialog, “An error occurred while
downloading!\n#{url}”,
TITLE, Wx::OK | Wx::ICON_ERROR,
Wx::DEFAULT_POSITION)
md.show_modal
end
File.unlink(File.join(Dir::tmpdir, fname))
@dialog.destroy
exit(1)
end
}
@dialog.progress_all.value = 100
sleep(1)
@dialog.hide
md = Wx::MessageDialog.new(@dialog, ‘Download(s) complete!’,
TITLE, Wx::OK, Wx::DEFAULT_POSITION)
md.show_modal
else
unless @m3ufile.empty?
md = Wx::MessageDialog.new(@dialog, ‘No supported media files
found to download!’,
TITLE, Wx::OK | Wx::ICON_EXCLAMATION,
Wx::DEFAULT_POSITION)
md.show_modal
end
end
@dialog.destroy # and exit…
end

def rename(file)
newname = “#{@destdir}/#{File.basename(@m3ufile,
File.extname(@m3ufile))}/#{File.basename(file)}”
FileUtils.mkdir_p(File.dirname(newname))
FileUtils.mv(file, newname)
end

end # StreamDownloader class

StreamDownloaderApp class

entry point for the app

class StreamDownloaderApp < Wx::App
def on_init
@sd = StreamDownloader.new
begin
playlist = (ARGV.first || @sd.ask)
rescue => err
$stdout.puts(err)
end
if playlist
@sd.file = playlist
@sd.grab
end
end
end

StreamDownloaderApp.new.main_loop

Tim F. wrote:

Well, figuring that this had something to do with loading from an xrc, I
redid my code to just create the dialog by hand… I get a dialog now,
without error, but something seems messed up with event handling… I
cannot move or close the dialog, the Cancel button does not paint… the
gauges work though :-p

Again, this all works fine for me on my Mac - I only see this weirdness
on Windows (XP) … I’m sure it is some detail I am overlooking or,
being so new to this, something I am misinterpreting…

I will look to try this out on XP in the next few days, but in the
meantime:

Attached is my code in hopes that someone will spot something… (this
is just a small app to parse an m3u playlist and download the mp3s found
there)

def grab
progress = 0
if @urls.size > 0
@dialog.show
Wx::get_app.yield

I have never tried using Wx::App#yield so I’m not sure whether it will
work correctly within a ruby context on all platforms. You might try an
alternate strategy of using one or more Ruby threads within which to run
the downloads. Include something like

Wx::Timer.every(50) { Thread.pass }

in your App#on_init to ensure the download threads get some time.

Then, inside the worker downloader threads, update some shared variable
with the progress at each step; inside the main GUI thread, have the
progress bar read this variable.

I am not sure this will solve it, but it has certainly worked for me
doing long-running file-based tasks (eg tokenising and parsing) in the
background while updating to a GUI representation of that.

Take a look at the etc/threaded.rb sample for a simple example of this;
Mario’s excellent chat client sample shows the use of Threads with
network operations, but it is more complex.

hth
alex

Alex F. wrote:

Tim F. wrote:

object; cla
ss `wxGauge95’ is not supported in wxRuby (NotImplementedError)

Could you post the XRC for this dialog please? It could be a problem
with the XRC that DialogBlocks is generating, or with the way that’s
interpreted by wxRuby or wxWidgets.

Thanks
alex

Sure … here you go … and thanks!

— here be the xrc —

<?xml version="1.0" encoding="UTF-8"?> wxCLOSE_BOX|wxMINIMIZE_BOX|wxSUNKEN_BORDER|wxFULL_REPAINT_ON_RESIZE|wxCLIP_CHILDREN|wxTAB_TRAVERSAL Stream Downloader 1 wxVERTICAL wxALIGN_LEFT|wxALL|wxFIXED_MINSIZE 5 Preparing downloads ... please wait. wxGROW|wxALL 5 current file progress wxGA_HORIZONTAL 0 100 wxGROW|wxALL 5 overall progress wxGA_HORIZONTAL 0 100 wxALIGN_CENTER_HORIZONTAL|wxALL 5 cancel downloading Cancel

Tim F. wrote:

Sure … here you go … and thanks!

Seems there’s an inconsistency on the wxWidgets side where the C++ class
of a Gauge on windows is reported as wxGauge95, a class which wxRuby has
never heard about.

I found that adding something like this before the main app code fixed
the problem:
Wx::Gauge95 = Wx::Gauge

I’ll add something similar to the wxRuby core library for the next
release so this won’t be a problem in the future. Thanks for the report.

alex

Alex F. wrote:

I have never tried using Wx::App#yield so I’m not sure whether it will
work correctly within a ruby context on all platforms. You might try an
alternate strategy of using one or more Ruby threads within which to run
the downloads.

That does seem to be the issue… #yield doesn’t behave the same under
Windows as it does on OS X :-/ I’ll work on using a separate thread for
the downloads and see how that fares…

Thanks for the help with the xrc issue - I really didn’t want to have to
code my interfaces by hand :-p

Cheers,
Tim

Tim F. wrote:

Alex F. wrote:

I have never tried using Wx::App#yield so I’m not sure whether it will
work correctly within a ruby context on all platforms. You might try an
alternate strategy of using one or more Ruby threads within which to run
the downloads.

That does seem to be the issue… #yield doesn’t behave the same under
Windows as it does on OS X :-/ I’ll work on using a separate thread for
the downloads and see how that fares…

Thanks for the help with the xrc issue - I really didn’t want to have to
code my interfaces by hand :-p

Cheers,
Tim

Well, I am still seeing some strangeness under Windows … not sure if
I’ve done something wrong, though… As before this all works fine on my
Mac…

I wrapped the open-uri call with a thread and added the Wx::Timer.every
call to the main app on_init as you suggested like so:

– snippet —

t = Thread.new {
File.open(File.join(Dir::tmpdir, fname), ‘wb’) { |ofile|
open(url,
:content_length_proc => lambda {|total| size = total },
:progress_proc => lambda { |current|
Thread.exit if @dialog.cancelled
@dialog.progress_item.value =
(100 * (current/size.to_f)).to_i if size > 0
@dialog.update
}) { |urlreader|
urlreader.binmode
ofile.write(urlreader.read)
}
}
}
t.join
t.kill if t.alive? # kill thread
raise “user cancelled” if @dialog.cancelled

– end snippet —

@dialog is an instance of the subclass of the base class generated from
my xrc by xrcise… that #update method looks like so:

def update(center)
self.layout
self.fit
self.center(Wx::BOTH) if center
Wx::get_app.yield
Thread.pass
end

My problem can be shown in these grabs:

http://www.mcgeecorp.com/downloads/wxwin00.jpg
http://www.mcgeecorp.com/downloads/wxwin01.jpg
http://www.mcgeecorp.com/downloads/wxwin02.jpg

You can see from this that the text label and the cancel button are not
being drawn correctly … the gauges paint and update fine… After the
first file gets downloaded, successive runs through the loop seem clean
up the label text but the cancel button never paints right and the
dialog is unresponsive to user input - if I click the close box I get
the windows message that the app has stopped responding… clicking
where the close button should be does nothing…

Am I doing something wrong or could this be something else?

Thanks,
Tim

Mario S. wrote:

Hey Tim,

Hey Mario…

Actually, your code is perfectly fine, there’s nothing wrong with it. What
is the problem though, is that when your running through your code, and
utilizing open-uri, it’s utilizing blocking sockets, in which whenever a
read method is called on the socket, if there is no data available, it will
wait till there is data available.

I can see the concern there … I would think (perhaps incorrectly) that
adding Thread.pass as part of the progress_proc callback would alleviate
some of that, though…

In any case, I actually see the same problems with painting without
using open-uri. I created a stripped down sample here:

http://www.mcgeecorp.com/downloads/xrc_test.zip

It uses the same xrc and base class as my program with open-uri, etc…
but in this case I am just using sleep calls and an upto loop to
simulate work.

Any other ideas? What version of wxWidgets is bundled with the gem?
Could that be an issue here?

Thanks!

Cheers,
Tim

Hey Tim,

Actually, your code is perfectly fine, there’s nothing wrong with it.
What
is the problem though, is that when your running through your code, and
utilizing open-uri, it’s utilizing blocking sockets, in which whenever a
read method is called on the socket, if there is no data available, it
will
wait till there is data available. Since Ruby uses Green threads
instead of
Native OS Threads, this thends to block external C/C++ code from
executing,
as Ruby’s main System OS Thread has priority. This caues, as you have
seen,
repaint issues, and missed answering of Events generated by
wxRuby/wxWidgets.

The solution to this problem, is to write the actual Socket calls
yourself,
to do the calls Asynchronously. You can actually look here:
http://wxruby.rubyforge.org/wiki/wiki.pl?Sockets on how to create
Asynchronous Sockets with wxRuby, and utilize them to write to and read
from
sockets, without blocking. However, it is key to note, that since you
will
be writting the socket routines yourself, you will either have to modify
the
library your using, in this case open-uri, to use the new socket method
routines, instead of the standard one, or you will have to do all the
reading, writting, connecting, and disconnecting yourself.

If you have any further questions about how to go about implementing
this,
let me know, and I’ll be happy to help you out with it.

L8ers,

Mario S.

Alex F. wrote:

Tim F. wrote:

Well, I am still seeing some strangeness under Windows … not sure if
I’ve done something wrong, though… As before this all works fine on my
Mac…

t.join
t.kill if t.alive? # kill thread
Have you tried without Thread#join? It’s only really necessary in a
script to prevent the whole thing exiting, whereas in a GUI app things
will keep running anyway until the app exits (which will presumably
check pending downloads).

alex

The code snippet I provided did not give enough context … that snippet
is called in a loop and I use Thread#join to have the loop wait until
that thread finishes before proceeding to the next item to process… I
would need to do some kind of polling of thread status otherwise and
that just seemed cleaner…

I did notice another thing of interest with the xrc_test I did… Bear
in mind there is not any blocking IO going on - just a simple counter
loop with a short sleep to simulate work… I had the following code in
an update method in the subclass of the xrc-derived progress dialog:

def update
self.layout
self.fit
self.center(Wx::BOTH)
Wx::get_app.yield
end

and I noticed painting artifacts and the like even though there was
little going on. I took out this method call (which I had after I
updated the label text as part of the counter loop) and the painting
problems went away! Of course the dialog does not resize itself then so
that isn’t really a fix, but it did hint at the problem being one of the
calls made in that method. I commented them out in turn and discovered
that it is the Frame#fit method that is causing the painting weirdness.
Any ideas what could be causing that? Is my usage of it proper?

Thanks!
Tim

Tim F. wrote:

The code snippet I provided did not give enough context … that snippet
is called in a loop and I use Thread#join to have the loop wait until
that thread finishes before proceeding to the next item to process… I
would need to do some kind of polling of thread status otherwise and
that just seemed cleaner…

This is from the pickaxe documentation of Thread.join:

“The calling thread will suspend execution and run /thr/. Does not
return until /thr/ exits. Any threads not joined will be killed when the
main program exits.”

I don’t think this is what you want - i.e. to suspend execution of the
GUI thread while the download runs. If you want the GUI to keep
updating, polling is the way to go. It needn’t be complicated.

In your case it could be a simple as something like this, assuming the
download is in a thread saved as @download_thread

Wx::Timer.every(100) do
if not @download_thread.status # false = finished normally, nil =
finished with exception
@download_thread = start_next_job
end
end

Using Wx::Timer is probably preferable to sleep in your circumstance as
it will give more reliable timings.

I commented them out in turn and discovered
that it is the Frame#fit method that is causing the painting weirdness.
Any ideas what could be causing that? Is my usage of it proper?

Looks OK to me. I guess it’s just because calling fit causes a repaint,
which isn’t otherwise visible. Hopefully using the threads right will
resolve this

hth
alex

Tim F. wrote:

Well, I am still seeing some strangeness under Windows … not sure if
I’ve done something wrong, though… As before this all works fine on my
Mac…

t.join
t.kill if t.alive? # kill thread
Have you tried without Thread#join? It’s only really necessary in a
script to prevent the whole thing exiting, whereas in a GUI app things
will keep running anyway until the app exits (which will presumably
check pending downloads).

alex

Alex F. wrote:

Looks OK to me. I guess it’s just because calling fit causes a repaint,
which isn’t otherwise visible. Hopefully using the threads right will
resolve this

Hey Alex -

I tried your suggestion, removing Thread#join in favor of a polling
loop… and I still see the same odd painting errors on XP and the GUI
remains unresponsive to user interaction (no matter how hard I click
grin)…

Maybe I’m just not understanding this clearly… as I see it there are 3
threads involved here: the main program thread, the gui thread spawned
by Wx::App.main_loop, and the thread I am spawning to wrap the open-uri
call… I think I have a handle on having them all pass off to each
other and the app works fine on my mac and on Ubuntu - in both my test
app and the full program I only see the painting problems and
unresponsiveness under Windows…

Could this be the result of some bug in wxWidgets? What version is
bundled with the wxRuby gem? If it would help I’d be happy to try and
set up a debuggable environment here … I assume I’d need VC6 to
compile since that is what the One-Click installer uses but are there
any special steps I’d need to take with wxMSW and wxRuby? Is there,
perhaps, a guide to setting up all of this from source?

In any case, thanks much to you and Mario both for your help and
suggestions thus far :slight_smile:

Cheers,
Tim

Tim F. wrote:

Alex F. wrote:

I tried your suggestion, removing Thread#join in favor of a polling
loop… and I still see the same odd painting errors on XP and the GUI
remains unresponsive to user interaction (no matter how hard I click
grin)…

I’m sorry that didn’t help. Is this a problem only when downloading in
the background, or even with a fake work task like ‘sleep’?

Maybe I’m just not understanding this clearly… as I see it there are 3
threads involved here: the main program thread, the gui thread spawned
by Wx::App.main_loop, and the thread I am spawning to wrap the open-uri
call…

main_loop doesn’t spawn a thread itself - the main program thread is the
GUI thread. That’s why I was thinking that things that temporarily halt
execution of that thread - like join - could stall updates.

Could this be the result of some bug in wxWidgets? What version is
bundled with the wxRuby gem?
The version is that latest stable 2.8.7. It could be a wx bug, but much
more likely is a problem in the way Ruby threads interact with the event
and scheduling internals. All of the GUI toolkits face this problem -
that they are not designed with ruby’s threading model in mind.
If it would help I’d be happy to try and
set up a debuggable environment here … I assume I’d need VC6 to
compile since that is what the One-Click installer uses but are there
any special steps I’d need to take with wxMSW and wxRuby? Is there,
perhaps, a guide to setting up all of this from source?
Thanks for the offer. We use VC 7.1 as 6.0 isn’t available. The wiki has
several quite detailed pages on compiling wxWidgets and wxRuby.

I’m not sure how helpful this will be, though - I think it’s more a
question of designing the use of threads to avoid the problem. Are you
able to reduce it to a simple standalone sample - perhaps by altering
the samples/etc/threaded.rb example to demonstrate it?

thanks
alex

Alex F. wrote:

I’m sorry that didn’t help. Is this a problem only when downloading in
the background, or even with a fake work task like ‘sleep’?

This happens even with the test app I posted above that simulates the
download thread work with a short sleep call… and, again, only under
Windows :slight_smile:

Here is the link: http://www.mcgeecorp.com/downloads/xrc_test.zip

main_loop doesn’t spawn a thread itself - the main program thread is the
GUI thread. That’s why I was thinking that things that temporarily halt
execution of that thread - like join - could stall updates.

Ah… thanks for the clarification :slight_smile:

Although I am new to wxRuby (and, as such, still getting my bearings),
it looks to have a great blend of features and I’d like to get to a
point where I can contribute in some way or another.

Cheers,
Tim

Alex F. wrote:

Attached is a version of your main app code restructured along the lines
I was suggesting. The jobs run in threads, and a Wx::Timer repeating
task (monitor) checks the state of the queue and whether cancelled.

This works well for me on OS X and Windows. I think the problem may be
using ruby’s sleep in the main thread - I guess on Windows this stops wx
updating to screen.

I don’t think you need to call update at all.

It ran fine for me on XP (thanks!) but for some reason when running it
on my Mac it just freezes up as soon as it starts… I’m on Leopard
(10.5.2) using MacPorts for ruby with the latest wxruby gem… Any ideas
what might be happening??

Sorry to be such a bother…

Cheers,
Tim

Tim F. wrote:

This happens even with the test app I posted above that simulates the
download thread work with a short sleep call… and, again, only under
Windows :slight_smile:

Here is the link: http://www.mcgeecorp.com/downloads/xrc_test.zip

Attached is a version of your main app code restructured along the lines
I was suggesting. The jobs run in threads, and a Wx::Timer repeating
task (monitor) checks the state of the queue and whether cancelled.

This works well for me on OS X and Windows. I think the problem may be
using ruby’s sleep in the main thread - I guess on Windows this stops wx
updating to screen.

I don’t think you need to call update at all.

Although I am new to wxRuby (and, as such, still getting my bearings),
it looks to have a great blend of features and I’d like to get to a
point where I can contribute in some way or another.
Thanks. Just being patient with problems and working through them on the
list is much appreciated. Even if no-one remembers the solution, it’s
archived and searchable.

cheers
alex