Alex Fenton wrote:
> Tim Ferrell 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
--
Posted via http://www.ruby-forum.com
/.
_______________________________________________
wxruby-users mailing list
wxruby-users rubyforge.org
ht
tp://rubyforge.org/mailman/listinfo/wxruby-users
|
